Здравствуйте, MouseTail, Вы писали:

MT>По поводу подчинения обстоятельствам и прочей мифологии. Позволю себе не согласиться. Не далее как недавно , пришлось мне писать SMTP шлюз, работающий сервисом под нагрузкой около 150-200 одновременных коннектов. Шлюз должен был уметь провести сеанс в соответствии с RFC2821, сделать небольшую антиспамерскую проверку и положить бандл в очередь. Так вот, писал я его на Delphi. Исходник сего чуда занял всего около 7 тысяч строк, из которых всего около тысячи собственно шлюз, а остальное — моя собственная RTL и библиотека классов тоже собственной разработки. Скомпиленый екзешник занимает 72 кбайт, под пиковой нагрузкой ест около 6 мбайт working set, обходится 5 потоками и занимает не более 15% проца вобщем не самого крутого. Это, конечно, оценки очень приблизительные, по таск-менеджеру. Но я это к чему, собственно. Если взять обычного программера, владеющего в достаточной мере, допустим, Delphi, BCB, MSVC и т.п. и поставить перед ним такое ТЗ, то он для реализации выберет Delphi в последнюю очередь.
И будет неправ? А почему? Потому, что "качество выполнения работы зависит от программиста, и абсолютно не зависит от средства разработки"? Так это абсурд. Вы потратите месяц, пока напишете на Delphi каркас, поддерживающий логическое программирование, и лишь затем приступите к написанию собственно экспертной системы в виде набора фактов и правил вывода. На Прологе я вообще не потрачу времени на каркас.
Аналогично, на VC++ замучаешься писать сложный интерфейс со множеством вкладок, докирующимися элементами и т.п., хотя бы потому, что нельзя все это двигать мышкой и представлять себе, что в чем находится (ну, кое-что можно, местами). На Delphi то же самое делается намного быстрее.

MT>"Вы просто не умеете их готовить" (c). У меня программы неконтролируемой самодеятельностью не занимаются.
Спешу засвидетельствовать свое почтение профессионалу. Мне за 8 лет программирования на Delphi этого добиться так и не удалось. Впрочем, я не ставил эту цель первичной: кому-то ведь надо и сами приложения писать А так — если подменить RTL и сделать еще пару финтов ушами, можно, пожалуй, и избежать неоднозначностей. Вот только с Delphi результат будет иметь мало общего

MT>Чем я успешно последние годы занимаюсь и получаю за это деньги.
Что это доказывает? Только то, что это возможно. Но никак не то, что это оптимально.

SM>> То есть — я рискну и попытаюсь навязать свое мнение читающим — в этом случае вместо Делфи вполне можно юзать любой компилер, хоть тот же FPC. Причем этот другой компилер может даже расширять язык более выгодно для программиста, чем Delphi.
MT>Нет, тут Вы принципиально не правы. Заниматься программированием невизуальных (не гуишных) вещей на FPC тяжелее чем на Delphi, это я по собственному опыту говорю. Ну и если возникает вопрос о навешивании какого-нибудь гуишного фронтэнда, то использовать уже два компилятора просто неудобно.
Не знаю, я по опыту использования FPC этого бы не сказал. Но спорить не буду, в основном я на нем писал под DOS extender. Да и не только FPC я имел в виду, а то, что какой-нибудь компилятор, кроме Delphi, может расширять язык лучше (вот в FPC, например, есть перегрузка операторов, если она кому-нибудь нужна). И если не юзать визуальность, он может лучше подойти для разработки. Я не говорил, что какой-то конкретный компилятор подходит лучше.

SM>>И возможности языка не в пример шире, это факт.
MT>Это не факт, это личное и частное мнение.
Это таки факт. Многие паскалевские конструкции имеют в C++ прямые аналоги, для других можно придумать аналоги, используя шаблоны. Еще что-то можно сделать возможным, введя базовый класс и потребовав у всех от него наследоваться. Object Pascal же нечего противопоставить шаблонам, по кр. мере, с сохранением всей полноты возможностей наследования и прилично выглядящего синтаксиса. Разве что Delphi .Net... но на нем вы как раз WDM-драйвер и не напишете, тем более — VxD

SM>>Короче говоря, незачем делать припарки мертвому — Делфи подходит для написания драйверов по крайней мере немного меньше, чем C++. Тогда зачем упираться и делать это на Делфи?
MT>Лишь потому, что одна маленькая и мягкая фирма сделала С\С++ своим корпоративным стандартом. А без этого все языки равны в этой отрасли.
Согласен. Но не ради же принципа писать драйвера на Delphi, если сейчас это удобнее делать на C++!

MT>О чём и речь
Тут без комментариев

Slicer