Вот тем, что она всякую дрянь использует она мне и не нраится... тот же басик древних времен, ток терь это уже не дллами зовется, а ассемблами, но смысл от этого не сильно изменился.
Я люблю, когда прога автономная т.е. работает без всяких внешних файлов (по минимуму ессесно), вообще, надо писать на Асме под винды, вот

Цитата

ток терь это уже не дллами зовется, а ассемблами, но смысл от этого не сильно изменился

Изменился, изменился. Сорри, что пока без аргументов, я их пока сформулировать точно не могу.

Цитата

Я люблю, когда прога автономная т.е. работает без всяких внешних файлов

Ну это почти абстракция.    Проги без dll-лек (файлы конфигурации и данных упоминать не будем) я уже давно не видел. А насчет автономности можешь не беспокоиться. Как только новые версии виндов будут стоять на всех компах, то считай что  .NET уже везде есть. Помниться меня раньше, в то переломное время, когда почти у всех стоял ДОС но начинал распространяться Win95, тоже раздражало, что пишут под вин и мне теперь для некоторых вещей его придется ставить. Держался некоторое время - не ставил. Теперь такой проблемы уже нет. Но теперь есть .NET! Так что лучше не сопротивлятся, а хорошенько изучить - все равно он будет.

И все же я противник этой NETизации :\ кто хочет простой жизни, те пишут на басике.
Когда еще будет такое, что у всех будет это чудо стоять, а до этого будет примерно такая картина: Вась, этта, у меня твоя хрень не пашет, подкинь мне  ассемблов.
Но вот в том, что изучать как следует придется я согласен :\ так или иначе, надо шагать в ногу с прогрессом, даже если нововведения не нравятся.

з.ы. вдруг случится чудо: на всех сотрудников майкрософт кирпич упадет (разом на всех и притом один и большой) и решат они (а может уже некому будет решать) убрать энту фиговину из виндов, а потом весело побегут играть в песочницу.

Цитата(Fantasist @ 23.11.2002, 10:53)

Проги без dll-лек (файлы конфигурации и данных упоминать не будем) я уже давно не видел.

А нет их. Даже самая простая прога под винду использует API, которые в DLL и зашиты.

Господа, спор беспредметный - суть в том что .net будет частю операционки, следовательно его использование - это лишь использование ресурсов операционной системы. Тот FarmeWork который сейчас - это некий аналог Win32S - была такая штука, которая давала боступ к Win32 API в среде Win3х. Думаю сейчас споры о том пользовать .net или нет похожи на рассуждения писать под ДОС или под Win95 году так в 95 - тогда многие (и я в том числе) считали что "правильнее", "более оптимально" и "по-настоящему" надо писать под ДОС, а винда - это так забава для любителя тыкать мышаком куда ни поподя. Прошло 2-3 года и практически все программы разрабатываются под винды, а в настоящее время круг програм под ДОС крайне узок - специальные программы для работы с железом, всякие там Backup/Restore/Repair и практически всё (ну есть конечно какой-то набор утилит писанных разными энтузиастами, да поддержка старых продуктов)... До поры до времени (в Win95/98) можно было работать практически со всеми функциями ДОС, но в современных версиях (2000/XP) ДОС существует только в режиме "крутой" эмуляции, для поддержки старых продуктов. Очень похоже на то что .net будет развиваться по тому же пути - вначале только FrameWоrk, затем она встроена в операционку, затем поддержка старых функций будет лишь в каких-то ограниченных пределах(например для драйверов и нижних уровней аппаратной абстракции и эмуляция для поддержки старых продуктов). Конечно это ни один и ни 2 года - а скорее всего на десяток лет, но такой вариант развития событий кажеться мне очень вероятным.

А по поводу использования DLL, библиотек и т.п., конечно господа Chingachguk и Baa здесь будут доказывать что лучше писать программы без их использования, только вот нет принципиальных различий между вызовом COM интерфейса, функции из DLL, виндовой API и int21 - в любом случае вместо обращения напрямую к ресурсам компьютера производится вызов подпрограммы, причём написанной не нами, а чужими и злыми дядями из MS, впрочем вызов прерываний BIOS - это тоже вызов чужих подпрограм, так что все кто ратует за то чтобы не пользоваться чужим кодом - могут его не использовать - надо открыть файл - вот посекторно читайте винт, разбирайтесь со всеми таблицами распределения, и собирайте все секторы воедино и т.д.... С таким подходом мы далеко не уедем, может какой-нибудь рассчёт уравнения Шредингера так будет быстро работать, но чтобы обычный NotePad написать уйдёт ни один месяц работы и сотни тысяч строк кода...

Да, смотрю я на вас большими и круглыми глазами      
Люди, что такое FrameWork, что представляет из себя .NET, чем они отличаются от сегодняшних ... аналогов , просветите плз так, в общих чертах.

Цитата(Vex @ 24.11.2002, 05:30)

Да, смотрю я на вас большими и круглыми глазами       Люди, что такое FrameWork, что представляет из себя .NET, чем они отличаются от сегодняшних ... аналогов , просветите плз так, в общих чертах.

http://www.rsdn.ru/?article/default.asp?dotnet/clr.xml

Цитата

А нет их. Даже самая простая прога под винду использует API, которые в DLL и зашиты.

Не, ну это естесственно, я имел ввиду именно свои длл-ки. То есть те, которые не системные, и не компиляторные.

Цитата

Думаю сейчас споры о том пользовать .net или нет похожи на рассуждения писать под ДОС или под Win95 году так в 95 - тогда многие (и я в том числе) считали что "правильнее", "более оптимально" и "по-настоящему" надо писать под ДОС

Так и я о том же говорил! Я, как уже упоминал, тоже считал, что виндос - это не для нас - ДОС круче и все такое. Маленький я тогда еще был.    Теперь совершенно очевидно, что вопрос не в том "Переходить ли на .NET" а в том, "Когда переходить на .NET"

Цитата

А по поводу использования DLL, библиотек и т.п., конечно господа Chingachguk...

Не, Chingachguk будет доказывать что вообще писать надо почти на асме, а все объектно/компонентно-ориентированное программирование - это все ерунда, потому как главное хороший алгоритм.   Шучу.
Хотя не так уж он будет на прав - известный человек Александр Степанов, изобретатель шаблонов включенных в С++ и создатель STL - стандартной библиотеки С++, тоже не сторонник объектно-ориентированного программирования. Он сторонник обобщенного программирования, и считает, что главное искать алгоритмы и искать обобщающие их моменты. Он считает для себя неправильным подход объектно-ориентированных программистов, поскольку они начинают с объекта, а надо начинать с алгоритма.

Цитата(Vex @ 24.11.2002, 14:30)

Да, смотрю я на вас большими и круглыми глазами       Люди, что такое FrameWork, что представляет из себя .NET, чем они отличаются от сегодняшних ... аналогов , просветите плз так, в общих чертах.

http://www.gotdotnet.ru/

Цитата(Fantasist @ 24.11.2002, 14:37)

Он считает для себя неправильным подход объектно-ориентированных программистов, поскольку они начинают с объекта, а надо начинать с алгоритма.

Для меня нет такого понятия как "объектно-ориентированный программист" - программист, на то он и программист, что в состоянии не только использовать различные методы программирования, но уметь выбирать оптимальный. Я тоже считаю что алгоритм - это очень важное звено в программировании, но при чём здесь объекты? Если я пользуюсь объектами, то это вовсе не означает что для решения квадратного уровнения я создам десяток классов - это крайность, и если кто-то так делает, это его проблемы - этот человек просто не обнаружил оптимальное решение задачи. Другая крайность - это полностью отвергнуть ООП - и что в замен получит такой вот программист? - вместо того чтобы пользуясь готовыми компонентами и классами быстро покончить с интерфейсом программы и сосредоточится на алгоритме, он будет долго и нудно в тысячах строк кода рожать интерфейс, и к моменту работы над алгоритмом ему просто не хватит времени чтобы его сделать хорошо. Моё мнение, что в данном примере куда логичнее было-бы вначале потратить мизерное время на разработку интерфейса при помощи объектов, а сэкономленное время потратить на продумывания алгоритма. Оптимум всегда где-то по средине, а ни одна технология не может дать лучшее решениее в 100% случаев. Другой аспект оптимальности решения в том, что само понятие оптимальности решения не эквивалентно оптимальности кода, оптимальность решения включает в себя:
1) Оптимальность кода (размер, скорость, ресурсоёмкость)
2) Быстрота разработки
3) Читабельность кода другими программистами
4) Лёгкость распределения задачи внутри коллектива разработчиков
5) Лёгкость нахождения и исправления ошибок
6) Квалификация программиста требуемая для написания программы (от этого напрямую зависят затраты денег на проект)
7) Лёгкость переносимости на другие системы и выпуск новых версий

Итак что мы имеем - если писать на ассемблере не используя чужих библиотек и классов то мы в выигрыше только по первому пункту - по всем остальным пунктам мы в проигрыше. Стоит так писать? - конечно, если оптимальность критична - например ядро операционки или драйвер, или сложный математический рассчёт, и совершенно не стотит, если оптимальность кода не является критичной. Теперь почему же всё-таки многие программисты считают, что надо всё писать самому? Самое интересное, что их большинство - это программисты из хСССР. Дело в том что в хСССР традиционно рабочее время квалифицированного специалиста - самая мелкая разменная монета - стоит дёшево, заставить работать можно и сверх урочно, разница между оплатой хорошего специалиста и не очень - не велика.

Пример? Пожалуйста - надо написать программу для отсылки FAX - можно писать "в ручную", вплодь до программирования модема - на это уйдёт примерно месяц. На западе программист такого уровня для написания такой программы стоит около 7000 в месяц. А можно найти программиста на 2000 в месяц и нанять его на 3 дня, чтобы он присобачил отсылку факсов через Symantec WinFAX (стоимостью в 100 долларов) COM interface . Итак в первом случае затраты 7000 долларов, во втором около 200 - разница на больше чем на порядок! Оптимальность кода? - а на фиг она там нужна? скорость отсылки факса лимитирована скоростью его передачи, даже самые медленные алгоритмы будут работать на много порядков быстрее передачи страницы факса. Экономия ресурсов? Дык давайте затратим ещё 500 долларов на Upgrade железа и эти ресурсы никого не будут уже волновать, а себестоимость осталась всё ещё на порядок ниже! Другие критерии:

Читабельность кода - что легче - читать 20 строк на VB или 20000 строк на ассемблере?

Лёгкость нахождения и исправления ошибок - в 20 или 20000 строках кода?

выпуск новых версий - а на фиг нам заботится об этом, как Symantec новую версию выпустил, так вот он вам и автоматический Upgrade, за каких-то там 10 долларов (10 долларов это моя зарплата за 20 минут работы - ну много я успею за 20 минут улучшить?)

Что ты мне то доказываешь, это не мое мнение а его.  
Я то преверженец ООП. Именно таких он называл "объектно-ориентированными программистами".    То есть если есть проектная задача, я буду подходить к ней в плане дизайна с ООП - то есть именно начну с придумывания объектов. Конечно, если не очевидно, что задача не подходит для такого метода решение(типа поиск строки в файле).

Ну, не принимай на свой адрес, я собственно не с тобой спорю, я в общем-то именно с твоим мнением и согласен, просто цитаты у тебя колоритные вот и беру их из твоего топика , по настоящему если на этом форуме на эту тему я и полемизировал бы так только с Chingachguk и Baa

Если отвечать на поставленный в начале темы вопрос, то сейчас это сделать очень трудно.

Итак, по порядку
1. C# - JAVA-подобный язык, который поддерживает только Microsoft, что в принципе пока ничего не говорит. Хотя то, что MS выпустила J# - фактический аналог JAVA (как они там с лицензиями разобрались ) - говорит о том, что на сегодня JAVA в корпоративной разработке имеет тоже большие удобства. И MS пытается переманить на свою сторону какую-то долю девелоперов. Но мне кажеться, что это вряд ли. Разве что MS не будет денежным мешком навязывать эту систему.
2. .NET - хорошая среда, которая может быть востребована. Но она очень новая,  требует переделки многого количества кода (особенно для VB), что мало интересно.
3. XML - на сегодня наиболее удобный (но, увы, не быстрый) способ передачи данных ЛЮБОГО вида. Структурированность обалденная - можно слепить все что угодно.

Теперь мое ощущение:
MS будет давить на рынок серверов приложений. На персоналках она в принципе уже не досягаема. Сейчас место серверов хорошо "охраняется" JAVA. Во всяком случае на ней удобно писать, есть немало удобных IDE - JBuilder, Oracle JDeveloper, Together, SunONE. Есть мощная поддержка в виде JAKARTA.APACHE.ORG. Вообщем MS нужно будет приложить очень много усилий к завоеванию этого рынка. Если учесть, что уже немало сторонников среди госструктур у ОС с открытыми исходниками типа Linux, то для MS это становится еще более проблематично. Надо не только разрабатывать, но и использовать в качестве серверов Windows, что становится сложнее и явно дороже. Для JAVA такой проблемы не существует - она работает практически на всех системах без особых проблем с портированием. Кроме этого JAVA уже имеет достаточно большую историю и под нее написано достаточно много - уже просто так не вырвешь.
Необходимо также отметить, что явно наступает время распределенных систем, где на первый план выходят технологии межпроцессорного взаимодействия на разных системах. Ведь проблема быстродействия большой системы сейчас решается тупым увеличением мощности. И если система легко масштабируема, то она в явном выигрыше. MS со своей системой COM+ пока находится по удобству ниже CORBA, хотя если использовать ТОЛЬКО Винды, то можно работать. Но на все машины Винды поставить - это на самом деле крайне дорого.

Отсюда вывод:
MS будет работать практически на 100% персоналок и на "определенном проценте" серверных машин. Так же вполне возможна ситуация, что MS хапнет какую-то часть рынка мобильных устройств. Но ситуация, которая сложилась на рынке персоналок (более 90% рынка) мало вероятна. Все противники MS объединяют усилия и стараются недопустить Билли ко всем и вся.
Возможна ситуация, что в корпоративном секторе многие предпочтут устанавливать opensource & freeware, что немного потеснит MS на этом рынке. Особенно, если большие корпорации объединятся в этом вопросе и будут предлагать решения на основе JAVA и Unix (Linux) (что, кстати, и происходит последнее время - Oracle, SUN, IBM, HP, Borland).

Думаю, что борьба за рынок сейчас будет вестись еще более напряженно.
Ф-у-у-у-у

Захожу на Yahoo, загружаю поиск рабочих мест в районе Чикаго, к сожалению могу искать только по ключевым словам, вот как поисковик откликается на ключевые слова (количество найденных мест по запросу):

Java 118
Delphi 6
C/C++ 220
VB 34
.net 151
C Builder 16
Cobol 23
Ada 9
XML 61
Soap 8
ASP 221
JSP 29
PHP 13
Perl 31
Asm 20
VBScript 10
JavaScript 23

Ну вообщем-то вполне разумная ситуация.

1. C/C++ - он везде и всюду
2. .net - под Винду клиентов на VB и VC больше всего пока.
3. ASP - вот тут не совсем влезает. Может просто из-за большого парка Виндов с IIS и большой простоты его настройки (IIS) + скриптовые языки
4. JAVA + JSP - вот они корпоративные сервера и пошли.
6. XML - ну это вообще куда угодно можно пристроить
7. Скриптовые вещи - JavaScript, VBScript, Perl, PHP - может как раз пересекаться с ASP
8. Все остальное - это остаточки от рынка и особенностей бизнеса фирм-работодателей.

Что же с Delphi так плохо :-(