Здравствуйте, Slicer [Mirkwood], Вы писали:

MT>>Что касается необходимости и уместности. Я считаю что средства разработки для native subsystem на основе паскального синтаксиса до этого момента не существовали, не смотря на то, что популярность деривативов паскаля в данный момент не меньше, а в некоторых отраслях рынка и больше чем деривативов C. Поэтому данной статьей я просто закрыл некоторую досадную прореху в ассортименте средств разработки.

SM>Рискну вызвать волну флейма, но деривативы Паскаля — понятие более чем абстрактное. Нет смысла говорить об абстрактной популярности языка, а лишь о его популярности ДЛЯ. Для решения определенного круга задач. Как уже неоднократно отмечалось, человек, программирующий задачу на данном языке, несмотря на то, что он (язык) для нее не подходит, делает ошибку либо подчиняется обстоятельствам. Это не к тому, что Delphi не подходит для написания драйверов, это лишь довод в пользу классификации по сферам применения.
SM>Так вот, конкретно Delphi совершенно справедливо позиционируется как RAD-среда, причем с выраженным акцентом на "прикладной" смысл слова Application. В основном это выражается в быстром проектировании пользовательского интерейса, хотя и не только.

Ничего абстрактного Delphi, FPC, GNU Pascal и прочие. То есть те, чьё синтаксическое сходство с виртовским паскалем больше, чем у остальных языков.

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

Я же считаю, что качество выполнения работы зависит от программиста, и абсолютно не зависит от средства разработки. Я допускаю, что кто-то может владеть, скажем, Visual Basic'ом в такой мере, что позволит ему решить подобную задачу на более впечатляющих показателях. И я буду уважать такого профессионала при всё моём презрении к Visual Basic.

SM>Из-за обилия неконтролируемых или, что не лучше, принципиально контролируемых, но недокументированных действий, Делфи не очень хорошо подходит для задач, в которых нужно, чтобы программа делала ровно то-то и то-то.

"Вы просто не умеете их готовить" (c). У меня программы неконтролируемой самодеятельностью не занимаются.

SM> Применять Делфи для создания драйверов — это по продуктивности то же самое, что применять Делфи без VCL и визуального проектирования.

Чем я успешно последние годы занимаюсь и получаю за это деньги.

SM> То есть — я рискну и попытаюсь навязать свое мнение читающим — в этом случае вместо Делфи вполне можно юзать любой компилер, хоть тот же FPC. Причем этот другой компилер может даже расширять язык более выгодно для программиста, чем Delphi.

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

SM>Ну и потом, о вкусах не спорят, так что тут я ни на чем не настаиваю, но лично мне гораздо больше нравится C++, и я бы писал исключительно на нем, если бы для него существовала нормальная RAD-среда хотя бы для проектирования GUI (Билдер — не нормальная). И возможности языка не в пример шире, это факт.

Это не факт, это личное и частное мнение. Я не буду спорить, потому что этот спор ни к чему не приводит вот уже десятиления. Я считаю, что недостатки и достоинства у паскальных и сишных деривативов распределены приблизительно одинаково и взаимно компенсируют друг-друга.

SM>Короче говоря, незачем делать припарки мертвому — Делфи подходит для написания драйверов по крайней мере немного меньше, чем C++. Тогда зачем упираться и делать это на Делфи?

Лишь потому, что одна маленькая и мягкая фирма сделала С\С++ своим корпоративным стандартом. А без этого все языки равны в этой отрасли.

SM>Но! Все выше сказанное вовсе не означает бессмысленность исследования. Важен сам поиск решения, методика, — ведь она может оказаться полезной при решении других проблематичных ситуаций. Ну и, безусловно, вопрос принципа тоже не последний: теперь Делфи применим еще в одной нише, что делает его более универсальным, чем обычно считается.

О чём и речь