Комментарии 94
Книжка конца 1980х в главе посвященной языкам программирования утверждает что Pascal один из самых распространенных языков программирования. Delphi в версии 4-5 (дальше я его уже не видел) выглядит логичным развитием наследия Pascal.
Delphi и его диалект в FPC - прекрасные языки, причем достаточно современные. Все эти годы он не топтался на месте: добавили языковые фишки вроде неймспейсинга, дженериков, анонимных функций, допилили компилятор и сделали бэкэнд на LLVM для кроссплатформенности, сделали поддержку самых разных платформ. Даже пробовали интегрировать с .NET!
Но современным новичкам изо всех щелей пихают убогий петухон и жабоскрипт (он норм) и из за огромного числа либ для выполнения почти любых задач, люди иногда перестают думать сами и собирают программы из всего готового
Delphi и его диалект в FPC - прекрасные языки, причем достаточно современные. Все эти годы он не топтался на месте: добавили языковые фишки вроде неймспейсинга, дженериков, анонимных функций, допилили компилятор и сделали бэкэнд на LLVM для кроссплатформенности, сделали поддержку самых разных платформ. Даже пробовали интегрировать с .NET!
С этим никто не спорит, но лично я считаю правильным ходом было бы отдать компилятор Delphi в Open Source и тогда очень быстро и IDE для всех осей появятся и много чего еще. Но что-то мне подсказывает что такое не произойдет.
Но современным новичкам изо всех щелей пихают убогий петухон и жабоскрипт (он норм) и из за огромного числа либ для выполнения почти любых задач, люди иногда перестают думать сами и собирают программы из всего готового
Ну про Delphi в свое время говорили также, что в нем не надо сильно знать программирование а просто подключать контролы и писать биндинги. Стандартный курс обучения включал только основы языка а все остальное время обучающиеся учились как пользоваться IDE.
Открытие исходников компилятора Delphi ничего не даст, Lazarus как я понимаю ушел далеко вперед, но это его не спасает. Дело не в наличии компилятора и IDE.
Да, "сила сообщества", имхо, переоценена. К примеру, кто-то выложил исходники осиротевшей FIBPlus, а толку ноль: не развивается, вообще, хотя тоже много коиков было.В итоге, к FireBird 4.0 (и новее), ничем нельзя коннектиться, кроме того, что идет в поставке с Delphi. Разве что в режиме совместимости (Firebird ) c 3.0...
Открытие компилятора позволила бы другим компания создать инструменты совместимые с Delphi. Free Pascal собирается под огроменный зоопарк всего включая JVM и даже JS с оговорками. Тот же Free Pascal смог бы сделать на 100% совместимый с Delphi режим совместимости. Условный JetBrains мог бы сделать IDE для этого компилятора и т.п.
Условный JetBrains делает IDE для популярных ЯП. Для потерявшего былую популярность Delphi он этого делать не станет.
Они даже свой AppCode для разработки под macOS / iOS зарезали, а это куда как более популярные платформы.
JetBrains делает эксперименты и по сути все их IDE являются прощупыванием почвы, сейчас сделать IDE на Delphi невозможно просто потому что компилятор закрыт и сильно пришит к Delphi, но если бы он был открыт и свободно доступен то эксперименты бы были стопроцентов.
Для потерявшего былую популярность Delphi он этого делать не станет.
У них до сих пор существует IDE для рельсов которые уже давно не популярны.
Чем вам мешает закрытость компилятора?
Для того чтобы dcc32.exe вызвать исходники не нужны.
У них до сих пор существует IDE для рельсов которые уже давно не популярны.
Когда RubyMine появился, эта популярность была.
Чем вам мешает закрытость компилятора? Для того чтобы
dcc32.exeвызвать исходники не нужны.
Пользователю как минимум понадобится лицензия на содержащую его ide, причем с не слишком адекватным ценником. Да и наверняка такое использование компилятора прикроют поправками в лицензии на следующий же день, если еще не.
Плюс, windows-only компиляторы это какое то мракобесие в 2025
Appcode же прикрыли. Когда rubymine прикроют?
я думаю с дельфи у них одна лига. Разве что взлёт и падение популярности у ruby были стремительнее
вопрос в том когда бы это сделали. Сейчас это даст меньше, чем в эпоху когда популярность начинала падать
Да, только многое так и осталось экспериментами или буквально расщепляет язык, затрудняя написание универсального кода. Ну это где string в desktop-версиях 1-based, а в мобильных 0-based. Где в первом варианте строки изменяемые, а во втором - нет.
С .NET пытались, но не осилили. ЕМНИП, только Delphi 8 имела .NET версию. А до этого была попытка в Kylix, выйти за пределы венды. И снова максимально странное решение. Пишем аналог VCL - CLX, который способен не только с WinAPI работать. А с чем же мы будет работать в Linux? Хм... Есть GTK+, написанный на C и Qt, написанный на C++. Ещё старые. GTK первой версии и Qt второй. Цеплять C++ библиотеку с классами к не C++ программе всегда тяжело. Поэтому давайте выберем Qt! Напишем деклассификационную библиотеку, которую придётся постоянно таскать с приложением и которая протухнет, когда выйдет Qt3. И так - много всего...
D7 тоже .Net версию имела. Правда, только компилятор.
Ну это где string в desktop-версиях 1-based, а в мобильных 0-based.
Это давно не так.
Где в первом варианте строки изменяемые, а во втором - нет.
Это тоже.
Всего два "эксперимента" были не удачными: .Net и Kylix. При чем Kylix просто появился слишком рано для своего времени.
Все остальное, что введено - работает и развивается. И фичи языка (синтаксис) и фичи RAD: сборки под любые платформы, дизайнеры и т.д.
Это давно не так.
Что в настольных можно включить 0-based я знаю, хотите сказать, что в мобильных стало можно включать 1-based?
При чем Kylix просто появился слишком рано для своего времени.
Там не срок был проблемой. А ооочень странный выбор библиотеки виджетов. Имея GTK выбрали Qt, заставили таскать с каждым приложением динамическую библиотеку, а когда вышла Qt3 вся эта система протухла...
Delphi и его диалект в FPC - прекрасные языки, причем достаточно современные. Все эти годы он не топтался на месте: добавили языковые фишки вроде неймспейсинга, дженериков, анонимных функций
К сожалению в результате многолетнего наслоения правок, сам язык иногда выглядит странно. Моя любимая фишка: array of T в описании переменной и параметра функции значит совершенно разное. Есть нормальные типы, а есть managed, которые ведут себя по разному. И есть случаи, где dynarray ведет себя третьим образом :)
> люди иногда перестают думать сами и собирают программы из всего готового
Знаете- дельфи с концепцией компонентного подхода уже был средой в рамках этого тренда. Максимизации повторного использования кода. Причина понятна- экономия денег (на ЗП разработчиков), времени (собственно rad), снижение количество ошибок- готовые компоненты обычно протестированы хорошо и доведены до ума, самописные- не всегда
И мне кажется и на делфи уже qsort или линейно конгруэнтный метод писали только студенты которые изучали эти алгоритмы. Остальные пользовались готовой библиотекой
Почему питон убогий, а js норм?
Basic. Который тянула ms виде VB и VBA , пока не поменяла его на Visual Basic .NET, где от оригинала осталось уже совсем мало. Язык ещё более древний чем паскаль, и в изначальном виде архаичный. Кто начинал с УКНЦ и Спектрума вспомнят нумерацию строк,GO TO (привет Дейкстре) и прочие особенности, которые в 21 веке уже выглядят совсем странными.
Но уже в конце 80-х (то есть до Delphi) Microsoft выпустил гораздо менее архаичный QuickBasic, практически приблизив его к Pascal. В итоге, как мне кажется, Visual Basic .NET и помог победить Delphi.
basic и visual как маркетинговые наименования превзошли конкурента(ов) - нью-паскалю надо было назваться хотя бы dolphin или оторвавшись от синтаксиса паскаля (никак с ним не ассоциируясь) назваться dream и тп попав в тренды уняв боль школьников от насилия паскалём (единицы же потом осили в дельфи) а ворд их так не запугал ... даже можно было исправить ситуацию дав синтаксис на родном языке аля 1с - реально изменилось бы отношение (даже к ашанову и его аналогам в других странах)
Если оторвать паскалю синтаксис паскаля, то ничего не останется.
уняв боль школьников от насилия паскалём (единицы же потом осили в дельфи)
У вас странные фантазии, какая ещё боль?
даже можно было исправить ситуацию дав синтаксис на родном языке аля 1с
Поздравляю, вы переизобрели ШАЯ!
по мне qbasic (кстати простая версия входила в dos)- всё таки куда менее функциональна по сравнению с борланд паскалем (его тогдашний конкурент)
Видимо, это вторая попытка написать нечто более похожее на статью, чем на черновик. Но, пожалуйста, хотя бы пользуйтесь автоматическими проверками орфографии и грамматики. Вот только одно предложение и в нём более десятка ошибок:
Но это и причина не успеха из за того что меньше сообщества, эконсистема, да и ЛПР решающий сделать ставку на это решения берет на себя ещё и риски вендором с которым, что то может случиться через пару лет и это создаст проблемы при дальнейшей разработки системы.
Вы так говорите про капитализм, как будто это что-то плохое )
В остальном всё верно: Дельфи - это ниша Windows АРМ (Win95 - NT - XP), в эпоху отсутствия широкополосного интернета и удобных серверных решений.
Проблема была даже не в Дельфи как таковой, а в такой нудной и скучной вещи как сопровождение ПО.
Программу мало написать - ее надо установить, настроить, и сопровождать - исправлять баги и глюки, слетевшие настройки, обновлять.
Знаменитое "у меня программма не работает!! - какая? - моя!!! Я ничего не нажимала!!!".
Потом оказывается что то ли диск забит, то ли сеть слетела и базу не видит, то ли вирус чего-то поломал, то ли еще 100500 причин, из-за которых сисадмин-эникейшик бегает как укушенный между сотрудниками и чинит, исправляет и обновляет, да еще для разных версий Винды (потому что есть и другой софт со своими требованиями).
Особенно если еще и программа кривая.
Когда появилась возможность заменить этот зоопарк на 1 (один) сервер и браузеры - конечно же, его заменили.
Если бы на Дельфи можно было писать веб-системы - всё могло бы пойди иначе, но Паскаля не было ни в Линуксе (по сути не было, он там как пятое колесо в телеге), ни в браузерах.
Сейчас к слову можно и Линукс и Веб. Понятно что немало времени утеряно, однако лучше поздно чем никогда
Если бы на Дельфи можно было писать веб-системы - всё могло бы пойди иначе, но Паскаля не было ни в Линуксе (по сути не было, он там как пятое колесо в телеге), ни в браузерах.
Чем это отличается от C++/C/Java/C#/Rust? Или они исполняются браузером нативно и давно?
Дельфи - это ниша Windows АРМ (Win95 - NT - XP), в эпоху отсутствия широкополосного интернета и удобных серверных решений.
Именно поэтому в ней есть компоненты для работы с SQL, "голым" TCP, браузером?
Проблема была даже не в Дельфи как таковой
Проблема была именно в Дельфи. Она хороша только для ObjectPascal/Delphi. А в нём неудобный синтаксис и приколы с изоляцией внутри проекта.
из-за которых сисадмин-эникейшик бегает как укушенный между сотрудниками и чинит, исправляет и обновляет
Т.е. в точности, как сегодня?
Когда появилась возможность заменить этот зоопарк на 1 (один) сервер
Нормально написанную программу всегда можно было кинуть на сетевую шару и пользоваться.
Или в RDP завернуть. Вот Вам и Ваш "священный" 1 (один) сервер.
Если бы на Дельфи можно было писать веб-системы - всё могло бы пойди иначе
Так можно было, совершенно спокойно.
ни в браузерах
Так и сейчас там ничего кроме JS нету, хотя казалось бы.
там кстати, тоже не один. А балансировки, кластер субд, кубер с контейнерами на куче серверов.
Даже с терминальными серверами- я лично админил фермы и на 30 серверов. Ограничение фактическое -70 пользователей на один rds севе
В дельфи были инструменты, позволяющие быстро "накидать" интерфейс к БД - это чуть ли ни единственное преимущество (куча наляпаных корпоративных "баз данных").
Сегодня эникейщик не бегает с обновлением программ. Даже не знаю, есть ли они еще...
Чтобы была нормально написанная программа - ее не должно быть просто писать )
Тогда не каждый студень, освоивший мышку, будет подаваться в программисты.
Чем ниже порог вхождения - тем больше рукож, ээ, коекакеров.
Что и подтвердилось с появлением PHP. На PHP писать сайт было еще проще.
В дельфи были инструменты, позволяющие быстро "накидать" интерфейс к БД - это чуть ли ни единственное преимущество
Во-первых, не только. Никаких проблем писать консольные приложения, GUI, клиент-серверные в Delphi не было, готовые компоненты были для многих вещей (за минусом разве что консоли).
Во-вторых, задача "накидать интерфейс к БД" совершенно типовая для того времени. Что плохого в том, что вместо dBase/Clipper появился инструмент, который позволял делать то же самое с использованием GUI WIndows быстрее и проще?
(куча наляпаных корпоративных "баз данных")
А сегодня Django, Node.js (подставьте собственный фреймворк), позволяющие сделать "кучу наляпанных веб-сервисов" - "это другое"(c).
Сегодня эникейщик не бегает с обновлением программ. Даже не знаю, есть ли они еще...
Конечно нету. Все давно запилили свои лунапарки с Agile и микросервисами.
Blender, GIMP, Cisco Packet Tracer всё это заброшено уже, наверное, лет 50 как.
Чтобы была нормально написанная программа - ее не должно быть просто писать )
"Вы не поверите"(с)
Ровно наоборот, это для того, чтобы получить приложение, которое нельзя просто положить на сетевую шару, в Дельфи приходилось "не просто писать".
Что и подтвердилось с появлением PHP. На PHP писать сайт было еще проще.
Бенц не запилил на свой автомобиль АКПП, неужто не понимал, что с АКПП управлять автомобилем намного проще?
для Дельфи есть компонент UniGUI - пишешь программу с окошками и кнопочками как обычно, запускаешь её на сервере, а клиент через браузер работает в этой программе
интересно. А в проде тестировали это? с тысячами пользователей
Да. Не с тысячами, но с тысячей одновременно. Работает отлично, узкое место оказывается уже база. Вообще оно может на кластерах работать из коробки. Также в коробке существует стресс-тул, можно просто взять и погонять прямо на своих форомочках и сценариях. На кластере производитель показывал скриншоты с 30 тысячами юзеров одновременных. Сам вживую я такого не видел, но тысячу видел (и делал) лично.
Из интересного по теме веба, тут у нас в чате (https://t.me/Delphi_Lazarus) кинули свежие тесты HTTP серверов. Паскалевский Мормот на FPC - достаточно высоко, где-то на первом месте, можете глянуть:
https://www.techempower.com/benchmarks/#section=data-r23&test=cached-query
сами авторы пишут что нет ограничений на число пользователей, зависит от мощности вашего сервера - https://www.unigui.com/explore/unigui-hyperserver
а как всё выглядит можно онлайн заценить - https://prime.fmsoft.net/demo/desktop/mdemo.dll
В проде это у многих работает и уже далеко не первый год. И нагрузки в десятки тысяч легко выдерживает даже один инстанс севера
на виндовом сервере.
Со всеми полагающимися плюшками работы с Виндой - глюки, неустранимые преимущества и вирусы с антивирусами.
Сопровождение клиентского ПО и установка ODBC, конечно требовала затрат. Но не радикально более высоких. VDI вполне себе существуют параллельно с физ арм и терминально серверами.
С обновлениями- вопрос решаемый. Можете через GPO накатить на АРМ. Или систем центр. Или на сетевом диске хранить. Или на худой конец- клиент выкачивает с сервера свою новую версию и создаёт батник которому передаёт управления после завышения своей работы. Батник старую версию удаляет, а новый файл переименовывает в имя старого. Костыль-но видел и такое
Что бы не бегать между пользователями есть инструменты удаленного доступа. Начиная с подключение по rdp сотрудника ТП к нулевой сессии пользователя и разнообразных проприетарных решений.
Ну а если на АРМ настройки слетают и вирусы.. то веб морда проблему не решит. Совсем. В банковской системе из браузера сохранил сотрудник данные на рабочий стол и всё- у вас не защищаемые данные c pci/dss+ПДН. ПК пользователя подключены к порту не в верном VLAN -он через браузер и не зайдет. веб морды не сильно работу по поддержки рабочих мест сократили
А капитализм- скорее да. Плохо
1. Не всегда лучшие технические стандарты выигрывают. Иногда- те у кого более весомый владелец который может в рекламу вложиться
2. Отчуждение. Если с неравенством ещё в теории можно работать через прогрессивное налогообложения (что правда обходиться на практике офшорами), то вот с отчуждением -проблемы. Почитайте если интересно Фромм. концепция человека у маркса
Маркс устарел ))
А если серьезно - все претензии к капитализму почему-то всегда выглядят как ворчание обиженных: им не дали, их обошли, ОБИДЕЛИ таких хороших!
Да, не дали и обошли - но в принципе никто не мешал брать и обходить самим. В отличии от "более справедливых систем", которые точно так же всегда вырождаются в кумовство, или иными словами - в группу приблатненных, которые всегда равнее чем другие, зато вот вырваться из "других" вам уже не дадут: у кормушки мест мало. Для вас - уравниловка и почетные грамоты со значками.
Та же человеческая "приматная" иерархия, просто основанная на других принципах.
Гораздо интереснее было бы, если б был указан факто, что разработчик Турбо Паскаля, Дельфи и С# один и тот же человек: Хейлсберг Андерс. Он так же участвовал в разработке MFC когда перешел из Борланда в Микрософт.
можно сказать, бог дал - бог взял
Это мне кажется и так известно всем кто всерьёз Дельфи интересовался. А переход освещён в статье на которую отвечал.
Но если хотите занимательных фактов
Вирт до Паскаля создал
Euler (1965)
Algol-W (1966)
После паскаля
Modula (1975)
Modula-2 (1978)
Появилась в модуле модульность, а ещё и параллелизм. Борланд
а далее
Oberon (1987)
Oberon-2 (1991)
Это анти Ада. языки минимистичные, насколько можно. Ещё и ОС на обероне запилил
https://habr.com/ru/articles/258727/
Это главная причина того, что C# задушил Delphi, C# это просто обновленная версия Delphi от того чё человека
Всем, кто всерьез интересовался Дельфи, вся эта статья больше как ностальгия, нежели откровение о том же, что произошло. Тем более то что факт, который я упомянул имеет существенную часть ответа на тему заголовка "Как Микрософт задушил Дельфи".
Borland сами выстрелили себе в ногу, выпустив на замену дешевому Turbo Pascal дорогую среду с ориентацией на базы данных. Не догадывались, как это отразится на популярности? Ну и качество кодогенерации застряло в прошлом веке, что не помогало в конкуренции
2. Экосистема: библиотеки, фреймворки, инструменты
— Python: PyPI: 553 тыс. пакетов . От NumPy для науки до Django для веба.
— JavaScript: npm — крупнейший репозиторий (2.1 млн пакетов).
Delphi когда то имел огромную базу актуальных компонентов -torry delphi pages. Было там 30 тыс компонентом, насколько помню. .Зашел сейчас- компонентов и их библиотек- 8 476, за последние 30 дней обновлено только 17. Многие компоненты из "золотого века" Delphi в современных версиях не заведутся. А для многих задач, актуальных сегодня, просто нет компонентов/библиотек. А без них писать- долго и дорого. Поэтому, для системного администрированию я перешел на PowerShell, а для интеграции ИС- Питон.
Вот этот пункт зацепил немного.
1) Torry никуда в общем не делся, можно убедиться лично: https://torry.net/. 30к компонент там никогда не было, сайт постоянно пополняется и сейчас. Большая часть кода, думается порядка 98-99% (в строках) можно перенести почти с любой старой версии Делфи. Язык имеет феноменальную обратную совместимость.
2) Делфи за счет пакета Python4Delphi можно сказать что включает в себя всё богатство библиотек Питона. Не вместо, а вместе. Проект активно развивается, пользуйтесь: https://github.com/pyscripter/python4delphi
Можно посмотреть еще на Эмбаркадеровские репы, связанные с Питоном и не только:
https://github.com/Embarcadero?q=python&type=all&language=&sort=
https://github.com/orgs/Embarcadero/repositories?type=all
3) 'Для многих задач нет компонент'. Список был бы интересен к утверждению
Да, язык очевидно не находится в топ 3 или топ 5. Но из топ 10 языков язык выпадал редко и сейчас вот (если верить Тиобу) на 9-м месте. Несмотря на объективную ситуацию с владением описанную в статье. Напомню, языков программирования в мире около трех тысяч. Мне кажется что это позиция достаточно хороша, что бы писать на этом языке. Потому как пишут и на тысячах (и это не оборот речи) менее популярных языков.
С пунктом "Для многих задач нет компонент" я тоже не согласен, но без основательным его тоже не назвать. Лично мне не хватает некоторых фундаментальных библиотек, опенсорсных:
1. MQTT
2. Нормальный Protobuf
3. Кроссплатформенный HTML Render
4. Полноценной OpenCV (свежей)
В остальном, какие бы задачи не решал, проблем не было
Если нет реализации чего-то на каком то языке что мешает подключить dll/so/dylib и пользоваться. Это касается и MQTT и OpenCV, вот Вам хороший кроссплатформенный HTML Render https://sciter.com бесплатный для использования с подключением библиотеки, в проект можно легко затащить через OpenGL контекст.
давайте простой пример. из скопа даже не проф разраба. А обычного админа
1. необходимо очистить поле SID-History у ряда объектов в AD
2. Нужно навешать на все папки в сетевых шарах сервера дополнительное право для ещё одной группы пользователей. Кроме тех папок у которых включено наследование и нет своих групп.
3.Нужно создать папки для всех УЗ членов определённой группы и назначить на них права owner этой уз
Задачи решаются в повершел довольно просто. А в дельфи подозреваю, только через win32, последняя ещё и через работу с ldap.
трудоёмкость решения задачи вырастет очень сильно.
Понятно, что речь о нативных возможностях. Скрипты будут всегда лучше работать в своих областях как вот в приведенном примере или JS в вебе (можно сказать что монополист, однако FPC уже и в WebAsm умеет собирать).
Обычный админ - это скрипты, а не полноценная программа. Скриптовый язык априори имеет огромное количество готового кода для мелких, редких, уникальных задач, потому что именно скриптовый языком удобнее пользоваться в данном случае и именно для него такие же админы уже до тебя создали готовое решение.
Насколько я помню, Delphi погубила конская ценовая политика в 90-х и начала нулевых. На пост-советском пространстве он был очень популярен просто потому-что все студенты и подавляющее большинство не-студентов использовали ворованную версию.
да помню цену 150 тыс руб,по тому курсу было 5000 долларов
самое интересное, что ms в бытность студенчества моего в провинциальном политехе выдавала мне вполне лицензионную вижуал студио. Даже в коробочке с дисками. Была договорённость на уровне кафедры. Единственное отличие от коммерческой- запрещено использовать для разработки коммерческого ПО. Формально- лицензия для учёбы.
MS в этом плане всегда были "умнее" Борландов. Они как я понимаю и сейчас имеют лицензии для своих продуктов, как в учебных заведениях (бесплатные), так и семейные (сильно дешевле корпоративных), и пиратов не сильно гнобят (даже massgrave на своем гитхабе хостят). Хотя сам Филип Кан быстро поднялся на турбо паскале в том числе и за счет низкой цены (по американским меркам того времени), это помимо быстрой компиляции и зачатков IDE.
Наверняка в этой теме есть спецы. Какую версию Delphi рекомендуете поставить чисто для экспериментов с языком? Я интересуюсь языками программирования как таковыми, и оказалось что в онлайн-компиляторах Дельфи отсутствует. Поэтому думаю скачать что-то легкое из старого. Интересует например RTTI, который вроде как в Lazarys в полной мере не поддерживается(?).
Ну и вообще какие есть интересные особенности языка, отличающие его от С++/C#/Java?
Basic. Который тянула ms виде VB и VBA , пока не поменяла его на Visual Basic .NET, где от оригинала осталось уже совсем мало. Язык ещё более древний чем паскаль, и в изначальном виде архаичный. Кто начинал с УКНЦ и Спектрума вспомнят нумерацию строк,GO TO (привет Дейкстре) и прочие особенности, которые в 21 веке уже выглядят совсем странными.
Господи, вот это жонглирование фактами... Патчем тут 21-й век и нумерация строк с goto?
Или, по мнению, автора непременным атрибутом написания кода на VB/VBA даже на рубеже 21-го века является неизбежное использование нумерации кода и goto?
Общего у VB/VBA с теми Бейсиками из 60-х не больше, чем общего между JS и Си. То, что и там и тут используются фигурнвньскобочки и есть ключевое слово break ещё не делают два языка имеющими «много общего».
Я тоже хотел вчера на этот факт обратить внимание ассоциацией, что сравнение изначального бэйска c VB (не говоря уже про VB.NET) равносильно сравнению садовой тачки с карьерным самосвалом.
Да и упоминание в связи GOTO имени Дейкстры, а в следующем предложении уже о связи "бэйсика и ума" без имени некоего классика выглядит странным, хотя это был тот же Дейкстра :)
У Delphi был нерастраченный потенциал, связанный с созданием мастеров. В своё время я впечатлился тому, что писал С. Орлик в книге "Секреты Delphi на примерах: Версии 1.0 и 2.0". Ведь, вместе с компонентами можно было разрабатывать специализированные редакторы значений полей компонентов и мастера для сборки более сложных задач.
Можно было бы подтягивать к программированию в ИДЕ архитектуру приложения, создавая специализированные модули, типа модуля данных, где собирались компоненты для работы с базами данных.
Я, к сожалению, не успел поработать над созданием компонентов (особенно визуальных). Крайне интересно было создавать их налету. Но я этого не умел делать. Тут мало вызвать конструктор с нужными параметрами и выстроить цепочку старшинства компонентов. Многое было заточено именно под работу на этапе проектирования. В исходном коде даже можно было проверить, в каком режиме находится компонент, и если он находится в режиме дизайнера, то можно было сделать что-то особое.
Но у Delphi/C++Builder была родовая травма: все визуальные компоненты — это надстройка над нативными компонентами Windows. Вроде, и так понятно. Но. Не было никакого единого подхода к программированию компонентов. Например, чтобы сделать календарь, нужно было взять за основу какой-нибудь Grid. В результате, смешивались различные задачи: собственно, визуальное представление (управление) и логика работы. С моей точки зрения можно было бы взять за основу список и определённым образом комбинируя списки можно было бы создавать довольные сложные конструкции. А логика должна поставляться отдельно. Для этого нужна композиция объектов.
И тут мы возвращаемся к компонентам Windows. С одной стороны, в Windows не предложено хорошего лаконичного набора визуальных компонентов. С другой стороны, при создании библиотек (что в Dephi, что в Visual Studio), каждый класс становится сборником фактически разнородных объектов, с которым даже в редакторе свойств работать трудно, даже и при тематическом разделении, а тематическое разделение должно было быть реализовано при помощи композиции объектов классов совершенно различных иерархий. На уровне языка, это непосредственно упирается в отсутствие множественного наследования, от которого сознательно отказались.
И ещё. Меня всегда доставало, что в VCL есть классы с пометкой "Custom", где часть свойств была закрытой, а потом публиковалось (published). Было бы гораздо удобнее иметь класс, у которого все новые свойства объявлены открытыми, и тогда можно было бы создавать другие классы, которые могут нормально работать с объектами данного класса. На этом можно было бы построить архитектуру приложения: вот у нас есть компонент, вот его обработчики, мы берём другой класс и делает так, что этот класс содержит сами обработчики... (Наверное, мн следует вернуться и посмотреть, что же это было. Тогда можно будет написать статью в раздел "Ненормальное программирование".)
Delphi не одним VCL богат и сам язык не завязан на Windows.
Ну и:
Не все визуальные компоненты в VCL были "надстройками над нативными" классами Windows. Существует целое семейство TGraphicControl, которое не имеет связей с winapi (это например TImage, TShape, TSpeedButton, ...).
Custom специально создавали, чтобы, если ты хочешь отпочковаться от контрола (например TStringGrid), брал именно Custom класс (TCustomGrid), а не конечный класс.
Если ты хочешь контрол Календаря, то стоило для начала решить: "Натив или не натив". Если натив, то наследуешься от TControl и реализуешь нативный виндовый контрол (он уже есть в ос), а если не натив, то можно выбрать либо тоже базовый TControl, либо TGraphicControl и либо рисовать всё самому, либо использовать наследника.
Delphi имеет и кроссплатформенный фреймворк, где все работает сейчас иначе, чем в VCL
а что насчет интерфейса IDE, был ли удобен? SDI применяемый в Delphi, как мне кажется проигрывает мульти-документному, как например в Visual Studio.
Насколько я помню, у Delphi и С++Builder был весьма необычный интерфейс - множество как-бы независимых окон. Тулбар с компонентами, окно редактора, окно свойств, еще что-то - все по отдельности раскидано по рабочему столу вперемешку с окнами других программ. Смотрелось... необычно, ярко, навороченно. Но не помню насколько удобно, я только будучи студентом что-то там делал немножко, а дальше работал в Visual Studio.
Это до определенных версий был SDI, причем многим он полюбился. Сейчас уже много лет тоже MDI, точнее не MDI, а SDI, но окно одно, с табами и панелями, равно как в VS. MDI это немного не то, его сама МС не рекомендует использовать давно.
его сама МС не рекомендует использовать давно
а можете дать ссылку, странно почему не рекомендует?
хм, я не нашел рекомендации не использовать. Или вы чтото другое имели ввиду?
Там замечание. Что с Win95 все приложения в Windows переходят на SDI. Не все и не сразу перешли, но MS Office они перевели с MDI
У них сменилась концепция, фокус сместился с приложения на "документ", стало один документ - одно главное окно, вместо одно приложение - в нем много "документов". Все шло к переключалке/отображалке открытых "документов" в таскбаре.
Проблем с интерфейсом в Дельфи по-моему никто не испытывал и было вполне комфортно. Я по крайней мере не помню чтобы мне прям очень хотелось MDI как Visual Studio.
It's great
Delphi живее всех живых, просто появилось много лентяев, которые накидывают библиотечки, прикручивают к ним пару строк своего кода и вуаля "готов в продакшен". НО качество этих библиотек по сути никем не подтверждено и зачастую начинаются пляски с бубнами позднее. Скорость и вхождение в разработку снизились, как и снизилось качество кода и его ресурсоемкость. А ведь кто писал на Delphi и C++/Qt мечтали, что когда аппаратная часть станет мощнее, то и программы смогут становится круче... Но нет, оказалось так это плохо работает... Яркий пример Skype(<100Мб) -> Skype Electron (>300 Мб) -> Teams (>900Мб)... Стал ли скайп лучше первого? Я лично считаю что нет, но он стал прожорливым до нельзя.
Очень проблемным в Delphi было то, что интерфейс программы получался стандартным, что хорошо для корпоративных пользователей, но вот для обывателей нужны были рюшечки, мигалки и прочая "непотребность" которая довольно быстро реализовывалась во Flash который и дал популярность JavaScript, а не браузер сам по себе, как тут преподносят...
RE: Как Microsoft задушил Delphi, создав .NET: история одного программиста и одного чемодана