Comments 98
В середине 2000х писали на нём систему прогнозирования закупок (для продуктового магазина), более с Дельфи не пересекался, хотя его "собрата" Билдера применяли аж до 2020 года (для обучения школьников)
покупали лицензию за $5к для обучения школьников? UPD. Пошел проверил сколько сейчас стоит -- $500 на год, $1500 постоянная.
Откуда это число?
Погорячился. Перепутал с стоимостью на студию architect. Пошел проверил сколько сейчас стоит -- $500 на год, $1500 постоянная. Возможно я плохо думаю о наших школах, но с трудом верится, что билдер покупался)
Раньше была программа для школ и вузов. Они не платили за использование.
И сейчас вы не совсем корректно посмотрели цены. Нет цены "на год". Все цены - постоянные. Купил и пользуешься сколько угодно. Дальнейшие покупки - это переход на новые мажорные релизы.
1 000 000 лицензий.
https://www.osp.ru/news/2008/0204/4752522
Конечно нет, и винды все пиратские (но уточню, это было не в школе, школьник лишь возрастная категория)
Не стоит 5000$, а бесплатна до $5 000 дохода в год
Платформа Linux в Delphi CE не поддерживается
Недавно, в официальной группе по Delphi, был конкурс. Писали игру "Сапер". Это вот моя. Посмотреть и поиграть можно здесь. Игра доступна в мобильных магазинах. https://github.com/HemulGM/MineSweeperFMX
Как у них дела с поддержкой корпоративных клиентов из России?
У нас было две лицензии Prof, продление каждой стоило до 24 года все 35 тыс. руб. Потом официальные продажи прекратились, но старые лицензии работают, просто обновления недоступны.
Держались до последнего. Только в конце прошлого года перестали продавать в РФ из-за санкций. В поддержке клиента думаю не откажут. Мы спокойно общаемся, создаём тикеты в системе багрепортов и т.д.
Когда то начинал с него. И до сих пор если надо под win пишу на нем. Просто теперь в основном пишу на cpp под микроконтроллеры или что то серверное ( пайтон, пхп, и прочее)
Вот так и не понял. Если сейчас есть задача побыстрому сбацать что то с формами под винду- какая есть альтернатива дельфи?
Вот только вчера была утилитарная задача - надо ввести три числа и рассчитать результат по определенной формуле. Написание такой утилитки под win на дельфи заняло примерно минут пять. И я могу скинуть exe как результат любому человеку, он у него запустится и он тоже сможет пользоватся. А какя современная альтернатива? - сделать то же самое за 5 мин?
Если сейчас есть задача побыстрому сбацать что то с формами под винду- какая есть альтернатива дельфи?
С# и WinForms, есть бесплатно в VS Studio Community из коробки, запускается везде где есть .NET Framework.
Edit: Только я вот не помню, не выкинули ли в новых версиях WinForms в пользу WPF.
А если так же быстро накидать, только кроссплатформенное приложение и без зависимостей?
Если сейчас есть задача побыстрому сбацать что то с формами под винду- какая есть альтернатива дельфи?
Qt (как родной на C++, так и портированный в Python). Сын подруги начал постигать программирование. Попросили придумать ему живую задачу. А у нас отдел кадров как раз мучается с допотопной программой Birthday Millenium. Паренёк за пару недель набросал аналог на Питоне (+ PyQt) с дополнительным полезным функционалом (формочки, кнопочки, поля ввода - всё честь по чести).
P.S. Хотя, конечно, с установкой Qt под винду тоже появились определённые сложности несколько лет назад ;).
Ты про танцы с бубном или что? Или тебе standalone сборки не нравятся?
Например, связка MSVS & wxFоrmBuilder. Результат работает хоть в старых, хоть в новых Windows, а ещё собирается для Linux.
Практически всё то же самое. Лэйауты вместо якорей, и ещё кое-где разница.
Однако, в Delphi всё готово из коробки, а то, о чем я упомянул, требует настройки. Ну и руку набить нужно, да. Как и везде.
HTML + JavaScript? Будет один html файл. Запускается в любой ОС.
Я понимаю, что у многих в печенках уже JavaScript. Но конкретно по этой задаче - по формуле посчитать три числа чем HTML + JavaScript то неугодил?
Работает везде где есть GUI с браузером. Не требует инсталлятора, компилятора, сборщика и так далее.
Чтоб написать такую программу, где 3 поля и кнопка, на делфи нужно буквально 2 минуты, это с учетом открытия среды разработки и сборки под Винду. Я могу записать видео, если нужно. И инсталлятор ей тоже не требуется, так же как не требуется и браузер. Переключив платформу, тут же после сборки под Винду, я также соберу программу под Андроид, МакОС, Линукс, иос и буду иметь полноценное приложение, которое даже в магазине смогу разместить. И при этом буду иметь максимальную нативную производительность и доступ к чему потребуется, к железу, ос, файлам, внешним устройствам и т.д.
P.S. подобное видео я даже уже записывал https://youtu.be/ma5vupXa8ZE
Всякие Qt, Flutter, Unity так не умеют? Никогда с ними не работал, но по описанию похоже что должны справиться. Интересно насколько это вообще частая задача, т.е. тут по описанию достаточно консольной утилиты, если сложные расчеты с графиками то какой-нибудь python, если что-то сложно и доступ с любого устройства, то веб с бэком. Какая реально ниша остала у Delphi в кровавом Энтерпрайзе, кроме поддержки старого кода, чтобы прям осознано выбрать его для новой разработки?
В Unity создание UI - кошмарное. Нет никакого стандарта и вообще минимум возможностей без переписывания всего.
Flutter не имеет дизайнера.
Qt - единственный нормальный конкурент, только и тут делфи в простоте и скорости сборки под все на голову выше.
Какая задача? 3 поля и кнопка? Я не знаю, а вот задача: кроссплатформенный софт - это пожалуйста. Например, я писал игру, где-то здесь есть ссылка на неё. Один проект, одно и то же окно, один и тот же код - итого: на своем рабочем ПК я собрал исполнительные файлы для всех ос, с этого же ПК я могу тестировать и отлаживать программу на всех платформах. И все это не занимает почти нисколько времени при сборке.
Не важно, какой сложности расчеты, нужны ли графики, всё это легко делается на делфи, с окнами или без. Нужен бэкенд - на делфи он пишется не менее быстро и просто, чем на ноде или пхп.
Современный делфи не позволяет собирать старые проекты, он не проходит для легаси проектов. Их нужно долго или нужно было планомерно обновлять с самого начала. А покупают именно новые версии.
я писал игру
Мне кажется для игр Unity подходит лучше.
Нужен бэкенд - на делфи он пишется не менее быстро и просто
Делфи хороший язык, я изначально разрабатывал на нем, но в последнее время у него появилось много конкурентов при этом бесплатных. И у него проблемы с поддержкой новых технологий, например лет пять назад пришлось самому писать реализацию WebSocket, т.к. то что было работало глючно, незнаю может уже запилили нормальную библиотеку
кроссплатформенный софт - это пожалуйста
Не все там так радужно, мы очень долго старый код портировали под линукс, причем там как проблема с портированием бэка, так и со старыми проектами на Vcl
Мне кажется для игр Unity подходит лучше.
Я где-то говорил иначе? При чем тут это? Это вы приплели Unity как средство, с помощью которого "быстро" можно сделать программу с GUI.
у него проблемы с поддержкой новых технологий, например лет пять назад пришлось самому писать реализацию WebSocket
А вы думаете каким образом появляются библиотеки для других языков? Их пишут люди и делают доступными всем! Когда несколько лет назад стрельнул GPT и появилось публичное API для работы с OpenAI, для каких языков были библиотеки? Да только для тех, для которых сами разработчики GPT написали обертки - это был только питон. Через несколько месяцев я уже опубликовал библиотеку для Делфи с полным покрытием всех функций API. Сейчас ссылка на мою библиотеку для Delphi находится на оф. сайте OpenAI.
Но вернемся к WebSocket - плохо вы искали. Есть (как и 5 лет назад) несколько бесплатных реализаций и несколько платных. Примерно те же 5 лет назад я разрабатывал систему обучения для пользователей с внутренним чатом, который как раз работал на вебсокетах.
Не все там так радужно, мы очень долго старый код портировали под линукс, причем там как проблема с портированием бэка, так и со старыми проектами на Vcl
Во-первых, никто не говорит о портировании, речь о создании. Если бэк написан нормально, он сам будет без проблем работать под Линукс, его не надо адаптировать. Во-вторых, проекты VCL портировать надо на FMX, потому что именно этот фреймворк не привязан к конкретной платформе.
Сейчас у меня несколько бэкендов на Delphi, которые я переписал с тормознутого Питона. Работают прекрасно. При чем, разрабатываю я бэкенд на Винде, тестирую тут же, а поднимается на прод бэкенд через CI/CD под Линуксом сам, без моего участия. И мне не надо специально под Линуксом его собирать или отлаживать, всё собирается и тестируется на Винде.
Не соглашусь, если Qt только формочки для вас, то он шире, намного шире просто изучите
Нет, просто речь сейчас именно о "формочках". В Делфи тоже хрен знает сколько всего. Например, из коробки есть REST клиент, клиент для работы с Amazon S3, BAAS и даже REST сервер (правда сервер только в ентерпрайз) и т.д.
Я знаю, что qt многое на борту имеет, например тот же 3D движок и Делфи, кстати, тоже имеет, правда сильно примитивнее из коробки
Чтобы написать такую программу, вообще не нужна ни среда разработки, ни компилятор. И скорее всего чатгпт сделает это за 10 секунд. Правильный ответ уже дан выше. Но не желающие развиваться личности придумают любой сценарий, лишь бы оправдать использование некроязыка. Программы на 2 поля и кнопку отсутствуют в реальной жизни, а выбор того или иного языка в первую очередь определяется доменом и как следствие наличием готовых библиотеки для реализации функционала. Скорость накликивания формочки тут рассматривается в последнюю очередь
Что вы за ерунду несете? Вы это сейчас всё серьезно написали или это такой вид "забавы"?
"2 поля и кнопка" - это гипотетический пример, описывающий простую программу, а не буквально 2 поля и 1 кнопка.
Delphi - язык, моложе Питона на 4 года, однако Питон почему-то стильный-модный-молодежный, а Delphi, который релизится каждые пол года, - "ужасное старье".
С какой стати вы решили, что я "не желаю развиваться", вы сюда с "Битвы экстрасенсов" пришли? Я думаю что да, ведь умом вы тут точно не блещете. Оправдываться и называть все языки и инструменты, которыми я владею - я не собираюсь.
Выбор того или иного языка обусловлен не столько наличием готовой реализации, сколько знаниями, умениями и опытом человека, который хочет решить задачу, потому что большинство языков (экосистем) одновременно имеют эти реализации в готовом виде. Использование CUDA ядер, работу с OpenAI, звуком, видео, изображениями, 3D рендером, например, реализовано на многих языках.
Создание GUI - это тоже из области "готовых библиотек и реализации функционала" и именно в Delphi эта часть реализована лучше, чем в большинстве языков.
Так почему я НЕ должен выбирать Delphi, если на нем имеются готовые библиотеки для решения задач?
Создание 3-х мерной формы, прямо на рабочем столе, для Delphi - это такая же пара минут, как и "2 поля и 1 кнопка".
Здесь я написал всего 10-20 строк кода.
Предложите инструмент, который решает эту задачу быстрее и проще.
Delphi CE кастрирован до упора. Если уж очень хочется писать на object-pascal с формочками, то лучше вместо него взять опенсорсный Lazarus.
Он полностью соответствует редакции Профессионал. Отсутствуют только драйверы для подключения к сетевым бд, отсутствует сборка под Линукс и не доступен компилятор из командной строки.
И чему это мешает?
Подключению к СУБД, сборке под Линукс, устанавке сторонних библиотек. И использованию в случае, если твоей годовой доход.превышае 5000 $.
Строение компоненты никто не запрещает ставить. Запрещена сборка через командную строку. Если у тебя есть сторонний пакет, то через среду разработки ты без проблем его установишь. Не установишь ты такие пакеты, которые используют отдельные батники для сборки или установщики, которые используют компилятор в обход среды разработки.
Если что, таких сторонних компонентов меньшинство.
В 2008 на Delphi начали писать ремейк движка умирающей игры Knights and Merchants. Добавили мультиплеер и редактор карт и еще кучу всего. Проект и игра до сих пор живы - KaM Remake. Исходники есть на гитхабе.
В 2013 форкнул свой проект на движке и перешел в 3D. До сих пор пишу по 1-2 тысячи коммитов в год. Долгострой - Knights Province.
Занятно, у меня знакомый участвовал, который Zbl
А Knights Province был на стим, он коммерческий или опен сурс?
Помню его, он еще Delphi MVP был когда-то (а может и сейчас им всё еще является). Давно не общались.
В будущем надеюсь Knights Province продавать, чтобы отбить хоть какие-то расходы, так что не опенсорс. Сейчас есть страничка на Стиме, но она скорее как плейсхолдер. Всё никак не доходят руки перевести игру в Early Access. Последние лет 10 просто выкладываю мажорные сборки на сайт, а минорные в Дискорде и Реддите.
Не являюсь. Уже лет 8 на Delphi особо ничего не делаю и требования для поддержания статуса не соблюдал, из-за чего меня отстранили. Развлекался немного над KaM Remake на досуге, но потом IDE стала такой ужасной, что в ней стало невозможно работать. А после C# и Rider туда просто болезненно вернуться.
Но подчеркну, что Delphi лучше C++. Сейчас работаю в С++ и дорабатываю старый проект. Там такая задница, эти их Generic, анонимки, указатели и ссылки ужасны. Вот где боль, а Delphi как язык прекрасен. И не даром С# создал выходец из Delphi.
Насчет С++ согласен - он явно идет не туда. Когда толко появился как "С с классами" было отлично. А в последнее время туда тащат все, что увидят где-то в других местах (все жду когда в С++ появятся трейты из Rust :-). В результате получается монстр.
К счастью, сейчас ушел от всего этого на платформу, где все совсем другое. И основной язык другой - ближе всего (из широко известного) к классическому паскалю.
За эти 8 лет среда сильно изменилась. Как визуально, так и технически
Да, визуально она стала приятной, помню еще Delphi 7 перекрашивал в темный стиль, дабы соответствала актуальной версии, что стояла дома. Последняя версия в которой что-то делал, была 2021. Там было много проблем в синхронизации проверки синтаксиса и компилятора. Он весь проект подкрашивал красным, тысячи ошибок, хотя спокойно компилировал и собирал. Предыдущая версия работала лучше, но проблемы иногда тоже всплывали. Еще бесило всегда, если есть хоть одна ошибка, отключались подсказки при написании кода.
А целом, Delphi мой первый язык, мой вход в индустрию и любовь на всю жизнь :D
У Delphi был ряд действительно не самых удачных версий с разнообразными глюками как IDE, так и, что хуже, компилятора. Я поэтому пережидал на проверенных XE5, XE8. Сейчас вот и 11 и 12 достаточно стабильные.
LSP, конечно, по прежнему глючит, Ctrl+Space тоже иногда отваливается, и компилятор почти всегда не в состоянии скомпилировать проект с первого раза, но на качество работы и сборки это влияет не столь сильно - полный ребилд за 20сек не так страшен.
Но вообще подумываю, что пора дробить проект на части (DLL или BPL), т.к. 500к строк кода Делфу явно нагружают больше, чем ей хотелось бы.
Я бы сказал, что делфи - самый высоко прыгнувший из компилируемых языков к современному мейнстриму (Java, C#, Kotlin - думаю это языки самой мейнстримной парадигмы)
C++ это конечно стандарт, но очень расплывшийся и полный дыр и старья. Батя так сказать. Если бы не существовало JS, Я бы не любил его больше всего)
Да, он самый, Я помню заморачивался)
А по поводу игры - конечно публикуй, мне кажется это хороший кейс для опен сурсных проектов - иметь, так сказать, понятную точку входа.
С 1995 года сеть магазинов работает на комплексе программ написанных на Дельфи. 30 лет... Это же уму непостижимо. И развивается, и расширяется, и не требует сотен программистов. Попытки перевести всех в веб регулярно проваливаются, люди не хотят и всё тут. Да и платить лишние деньги, зачем?
Конечно, всё общение с внешним миром через АПИ на Го, но внутри компании Дельфи правит миром.
Так и живут.
А чего бы им не жить когда все работает... Там же софт не ради софта а для решения задач бизнеса. И пока задачи бизнеса решаются - будет жить.
В Дельфчми не имел дело, много писал на 6-м билдере. Под винду - самое оно.
Упоминавшиеся тут wxWidgets - это совсем другое. Тут и Qt можно приплести и GTK, но там все сложнее и своя идеология. А аналогов дельфи/билдера, сравнимых по удобству и скорости решения простых типовых задач, пожалуй, так и нет.
Эх, ностальгия..
Этот язык, на пару с паскалем, сделал меня разработчиком. Даже на полках пылятся старые проекты, 3д движки и прочие игры.
Но сейчас не пользуюсь - не та инфраструктура, не те задачи..
Мой любимый Total commander написан на Delphi.
Сам активно использую open source альтернативу Delphi - Lazarus. В чем-то он конечно сильно уступает Delphi. Например, разработка под Android всё еще сырая, для IOS практически отсутствует, не все компоненты для Delphi совместимы с Lazarus, и еще много всего.
Но всё же это замечательный инструмент. Хорошая кроссплатформенность, приемлемые возможности кросс-компиляции, прекрасная поддержка старых систем, удобная IDE, быстрая компиляция, простота создания программ. Да и на выходе получаются небольшие (2-5 Мб) самодостаточные программы, независимые от от всяких Java Runtime, DotNet, VC Redistributable и прочего. Сам в основном создаю им portable приложухи.
На нем делаются некоторые вполне "взрослые" проги, многие из которых сам пользую: Total Commander, Double Commander, PeaZip, Cheat Engine, Greenfish Icon Editor Pro и др.
Давно уже ищу достойную замену из-за (незаслуженно) низкой популярности паскаля. Но всё в чем-то да уступает. Нет совершенства в мире ПО.
Никто не мешает использовать C++ Builder. По сути, всё то же самое, всё-равно, "объектники" все дельфийские, только заголовочные файлы к ним сишные.
Мне, даже, самому интересно проверить, работает ли мой C++ Builder. Много можно было бы сделать на нём, имея все преимущества компилируемого языка программирования, допускающего, в том числе, и непосредственную работу с памятью через указатели. Я бы развернулся бы.
Увы, но для C++ Builder я не знаю достойной свободной альтернативы. Есть, конечно, и Qt, и wxWidgets, и FLTK, и еще тонна всего, но оно всю намного заморочнее. Да и C++ далеко не такой простой в использовании язык как паскаль. Пишу на нем, но прочитать, наверное, далеко не все сразу смогу. Писать на нем получается дольше. Постоянно надо держать в голове много особенностей, UB всяких сортов помнить. Шаблоны до сих пор нормально не освоил. Delphi - это про легкую и быструю разработку. Эдакий компилируемый Python с упором на быстрое создание GUI.
Было бы интересно посмотреть на то, если бы кто-то взял и придумал, какие должны быть визуальные и невизуальные компоненты на самом деле. Тогда можно было бы организовать и средства разработки. Если брать за основу Dephi, то было бы очень удобно иметь универсальную библиотеку компонентов, независимую от платформы. (В этом случае, очевидно, потребуется ещё отдельная специализированная среда разработки самих компонентов под конкретную систему. Но для разработки приложений нужна единая среда.)
В чём, вообще, проблема разработки в Dephi/C++ Builder? В том, что если Вы хотите разработать свой компонент, Вы должны взять какой-то существующий компонент и произвести наследование. Сами компоненты сложносоставные. С точки зрения системного анализа, такие компоненты нужно разбивать на более простые объекты. Ведь, лучше всего задачи решать при помощи композиции, когда есть некоторый типовой визуальный компонент и компонент, реализующий логику работы. Логика может быть весьма разнообразной, но визуальное представление может быть всегда оно и то же.
Очень заманчиво заняться сейчас анализом возможностей. Например, список. Есть множество классов: TList, TStringList, TListBox, TListView... Надо как-то разобраться! Наверняка существует способ более понятного описания. Предлагаю над этим порассуждать.
Это уже сделано в Delphi и прекрасно работает в штатном фреймворке FMX. У меня есть статья на тему этого фреймворка, можете почитать
А что у них там сделано? Помится несколько лет назад (уж, не десять ли уже?!!) я столкнулся с FireMonkey. Да, это, кажется, была попытка, но не вполне удачная. Хотя, какую-то клоссплатформенность они получили.
А что за статья?
Это полноценно рабочий фреймворк с огромными возможностями.
Статья про FMX. Вы уже давно могли её увидеть, просто зайдя в мой профиль. https://habr.com/ru/articles/833804/
И вы здесь путаете визуальные компоненты и просто классы RTL. TList, TStringList, TList<T>, TObjectList<T> и другие списочные классы - это RTL, а TListBox, TListView - визуальные компоненты фреймворка VCL, при чем основанные на WinAPI.
Например, список. Есть множество классов: TList, TStringList, TListBox, TListView... Надо как-то разобраться! Наверняка существует способ более понятного описания. Предлагаю над этим порассуждать.
О чем тут рассуждать не совсем понятно.
TList - список произвольных объектов. Чего угодно.
TStringList - список конкретных объектов TString
И то и другое "невизуальные компоненты" (и да, есть еще, по крайне мере в билдере, TThreadList - список со встроенной блокировкой для использования в многопотчных приложениях - метод TTHreadList::Lock возвращает TList которым можно попользоваться, а потом "отпустить" TThreadList::Unlock)
TListBox и TListView - это вообще про другое. Это визуальные компоненты. В винде связаны с соответствующими интерфейсными элементами ListBox и ListView.
В том-то и дело, что всё завязано на Win API, всё является оболочкой. Оно и понятно. Но хотелось бы подумать о том, а что надо было бы программисту.
Не все завязано, а только визуальные компоненты ListBox и ListView и только в VCL
Ну тут надо обратить взор в историю. Дельфи (и Билдер) изначально создавались под винду и VCL создавалась как надстройка над WinAPI. Ну и плюс библиотека классов общего назначения.
Все остальное (мультиплатформенность) присрали уже потом.
У платформы и IDE Delphi и ихнего С++ просто нет конкурентов, это один из самых мощных, а может быть и самая мощная среда разработки для Windows. Там продумано всё, что только придет в голову, там огромный пакет готовых функций и библиотек. До сих пор при разработке на Delphi я узнаю что-то новое, что-то приятное и что упрощает разработку, а оказывается это было в стандартных библиотеках уже очень давно.
Многие хейтят "формашлепство", мол в вот все готовенькое, а так и должно быть в современной IDE, зачем описывать базовые вещи и тратить на это кучу времени, когда это можно делать через генератор и сосредоточится на самой идее, самом функционале, а кому надо те всегда могут и вручную этим заниматься.
Delphi и их С++ это гениальная, продвинутая среда разработки, обогнавшее всех и вся на года.
До сих пор существуют IDE, где нужно вручную описывать кнопки, события, создавать окна, экраны, это абсурд в 2025 году.
Язык развивается, IDE развивается и раз она продается дело в целом хорошо идут, чем я очень рад. Еще у них и бесплатная версия есть, это тоже очень круто.
Расстраивает только условия этой бесплатной версии. Она для тех у кого годовой доход не больше 5000$. Это ж 420$ в месяц. Т.е. даже условный продавец в Пятерочке не может ее использовать. Получается, что бесплатная она разве что для бедных студентов и индусов. Та же MS Visual Studio Community Edition бесплатна при доходе до миллиона $.
Я думаю, что это как раз и есть основная причина его "смерти" ну или если угодно - такого уровня жизни.
Это коммерческий продукт.
В то время как давно появились мощные экосистемы, где и инструменты и языки бесплатные или опенсурсные и поддерживаются мощной инфраструктурой (например корпорациями)
Соответственно майки драйвят .net, сделали его опен сурсным, VS бесплатна для некоммерческого использования, большая часть стека открыта.
Гугл работает как минимум над стеком инструментов для android и т.д.
Даже инструменты c++, которые проприетарные (от того же MS) конкурируют с опен сурсными компиляторами.
JS завоевал интернет и над его развитием работают основные мейджоры браузеров ну и т.д
У делфи такой инфраструктуры или эксклюзивной ниши нет.
Лучше конечно проконсультироваться с вендором, но по идее, 5000$ это касается именно доходов от использования программ написанных на Delphi CE, а не в целом.
То есть пока условный продавец Пятерочки пользуется Delphi CE только для своих проектов и имеет с них менее 5000$ в год - всё ок. Как только он получает с них более 5000$, или вдруг начинает использовать их в своей работе для блага Пятерочки - CE больше не положена.
Увы, это качается всего дохода вообще, в т.ч. не связанным с Delphi. Есть на русском лицензионное соглашение, про Community edition на 5-й странице.
Похоже что вы правы. Несмотря на реверанс в эту сторону упомянутый в FAQ. Во всех остальных случаях в тексте Соглашения, действительно, многократно повторяется про совокупный доход.
Весь современный веб это про ручное описывание экрана, событий и стилей
Я из Delphi ем, я с Delphi сплю, я на Delphi женат уже больше 20 лет. В Delphi есть свои шикарные библиотеки типа DevExpress или FastReport. В С++ ничего достаточно близкого, имхо, нет.
Однако, сравнивать с C++ его не стоит - Delphi в проигрыше.
Я уже не говорю о стоимости лицензии - тут Delphi проигрывал всегда. А уж тем более сейчас, когда есть MSVS CE с совершенно подавляющими (по сравнению с условиями от Embarcadero) условиями испльзования. Куча халявных (да ещё и open-source) IDE.
Крайне жидкое комьюнити. Мало собственных развитых библитек, при этом крайне непросто использовать не - дельфийские: для dll придется ручками делать обертку, в случае изменения интерфейса снова переделывать всё ручками (из-за этого в Delphi часто используют устаревшие версии). Полность нельзя использовать массу удобнейших C++ библиотек в формате header - only. Также нельзя использовать библитеки, требующие сабклассинга.
Врожденная колченогость кода. Странные правила с завершающей ";" и точкой в конце модуля. Профи щедро персыпают код try-finally, ибо в Delphi отсутствует RAII. Особо отважные наследуются от интерфейсов, но таковых мало. В Delphi до сих пор нет RAW - строк. Попытки расширения синтаксиса часто заброшены на половине дороги: например, для записей введены конструкторы, но деструкторов, срабатывающих при выходе из области видимости, так и не подвезли. Итераторы (например, по массиву) работают с копиями элементов, что резко снижает ценность этих итераторов. Collections Delphi с stl С++ можно сопоставить, но лучше не надо. Сравнивать темплейты С++ и дженерики Delphi тоже не стоит. Лямбды, которыми можно и хочется пользоваться.
Больная архитектура VCL. Например, кто-то придумал "гениальную" вещь -TDataSet, реализовать рабочего наследника от которого можно после довольно долгого пребывания в позе креветки. Для сравнения, реализовать кастомный источник данных для VirtualStringView, view's DevExpress, для отбражения / редактрования гридов wxWidgets и Qt я могу за 10 минут, между тем. И - фантастически "удобная и полезная" прокладка - TDataSource.
Про эффективность исполняемого кода сейчас говорить не модно, тем не менее, сранение не в пользу Delphi снова. Я как-то в Delphi запускал тестовую программу, написанную DWS - скрипте, так вот - она работал быстрее, чем та же программа на чистом Delphi.
Клепать формочки в wxWidgets я могу так же быстро, как и в Delphi, однако, после формошлёпства, начинается кодинг и отладка, а отладчик Delphi и рядом не стоял с возможностями отладчика MSVS.
Хотя С++ куда сложнее, чем Delphi, в Delphi - кодинг почти нет притока молоджежи.
Минусы - как "дельфисту - предателю"? Очень конструктивно.
для dll придется ручками делать обертку, в случае изменения интерфейса снова переделывать всё ручками
Как и для любого другого языка.
Полность нельзя использовать массу удобнейших C++ библиотек в формате header - only. Также нельзя использовать библитеки, требующие сабклассинга
Как и для любого другого компилируемого языка, который не с++.
Странные правила с завершающей ";" и точкой в конце модуля.
Очень смешно
Профи щедро персыпают код try-finally, ибо в Delphi отсутствует RAII. Особо отважные наследуются от интерфейсов, но таковых мало.
Какие глупости
для записей введены конструкторы, но деструкторов, срабатывающих при выходе из области видимости, так и не подвезли
Это заблуждение
Более того, сделать аналог defer из других языков - это дело 100 простых строк кода. https://github.com/HemulGM/System.Defer
В Delphi до сих пор нет RAW - строк
System.RawByteString существует давно
Итераторы (например, по массиву) работают с копиями элементов,
Это заблуждение
Collections Delphi с stl С++ можно сопоставить, но лучше не надо. Сравнивать темплейты С++ и дженерики Delphi тоже не стоит.
С этим согласен, в с++ это треш полный, особенно шаблоны.
Лямбд в Делфи пока нет, есть анонимные функции.
TDataSet и TDataSource никого отношения к VCL не имеют.
Я как-то в Delphi запускал тестовую программу, написанную DWS - скрипте, так вот - она работал быстрее, чем та же программа на чистом Delphi
Это говорит лишь о том, что вы плохо пишите программы на Делфи.
Клепать формочки в wxWidgets я могу так же быстро, как и в Delphi
Нет не можете. Даже близко дизайнер WX рядом не стоит с дизайнером VCL, и тем более с кроссплатформенным FMX.
после формошлёпства, начинается кодинг и отладка, а отладчик Delphi и рядом не стоял с возможностями отладчика MSVS
Это тоже глупость.
Я сомневаюсь, что вы хоть что-то хорошо знаете в Делфи.
System.RawByteString существует давно
Смотрите, вот пример raw - строки на C++, строка включает в себя несколько переводов строк:
std::cout << R"(
Электрон
неисчерпаем,
как
и
атом
)";Как и для любого другого компилируемого языка, который не с++.
Я говорю о том, что есть масса сторонних библиотек (С/С++), которые очень трудно или вообще нельзя использовать на Delpi. На Delphi таких библиотек просто нет.
...
Остальное - это эмоции.
Больная архитектура VCL. Например, кто-то придумал "гениальную" вещь -TDataSet, реализовать рабочего наследника от которого можно после довольно долгого пребывания в позе креветки. Для сравнения, реализовать кастомный источник данных для VirtualStringView, view's DevExpress, для отбражения / редактрования гридов wxWidgets и Qt я могу за 10 минут, между тем. И - фантастически "удобная и полезная" прокладка - TDataSource.
Вот, мне всегда было интересно, кто-нибудь пытался что-то сделать на базе TDataSet. Я успел порядком забыть эти вещи, но насколько я ещё помню, при работе с таблицей БД надо было строить трёхэтажную конструкцию с участием этого самого TDataSource посередине (и с TADOTable и TDBGrid). Вроде бы, при подчинённости двух таблиц, следовало в одной таблице указывать другую в качестве "материнской". Для этого, такая трёхзвенная конструкция и задумывалась, наверное.
Мне ещё было всегда интересно (но сам я так и не решился попробовать), можно ли создать экземпляр TDataSet налету. С визуальными компонентами было хотя бы понятно, что нужно делать, чтобы они заработали после создания. Это, скорее, такая концептуальная проблема Delphi: слишком многое завязано на визуальное проектирование, а хотелось бы иметь некую концепцию управления программными объектами, допускающую расширение.
Если продолжать пример с БД, то при работе с отдельными столбцами таблиц все эти столбцы в явном виде создаются конструктором прямо в коде формы (или модуля данных). Да, так, конечно, удобно с ними работать.
А что там в wxWidgets и Qt?
Ручками. С wxWidgets сами данные могут храниться где угодно, хоть в массиве, хоть генерироваться на лету; ты создаёшь наследника класса wxGridTableBase и реализуешь доступ к данным путем создания собственной реализации нескольких виртуальных методов (GetValue/SetValue/GetNumberRows...). В Qt схема похожая, но "всё более развито".
В Delphi похожий подход реализован, например, в DevExpress и в VirtualTreeViee, но кодить чуток побольше.
... Следует признать, что "из коробки" (как в Delphi) нет такого богатства готовых драйверов ни в Qt ни тем более в wxWidgets (их там вообще нет). Зато собственные источники данных (например, для гридов) в Qt/wxWidgets реализуются просто и удобно.
В Delphi, сейчас, тоже гриды из коробки имеют GetValue/SetValue/RowCount, при чем с возможностью указать тип редактора ячейки, как минимум кроссплатформенные их версии. Так что и этот гештальт закрыт.
Вдобавок, из коробки есть REST компоненты/классы, которые позволяют преобразовать JSON в датасет и подключить к таблице. Т.е. можно в дизайнтайм описать REST запрос на сервер, получить ответ, впихнуть все это в адаптер, прикрепить к таблице и созерцать данные с сервера в дизайнтайм, без единой строчки кода.
Стюардесса мертва, но тело ее живет.
С FMX проблема в сборке под Linux, из коробки они собирают только консольные приложения, а для GUI нужен FMX for Linux как отдельная обёртка. Дополнительная печаль в том, что основной разработчик FMX и FMX for Linux Евгений Крюков умер в августе 2024 года и дальнейший статус проектов, учитывая то, что FMX for linux это проект с закрытыми исходниками, до конца не понятен. Также не понятен статус остального проекта Евгения - CrossVCL для сборки VCL приложений под Линукс. Если у вас есть какая-то информация, поделитесь ей пожалуйста.
Эмбаркадеро уже решила проблему с FMXLinux и 12.3 уже поставляется с оберткой. И, я надеюсь, что в будущем откажутся от закрытости этой части и создадут нормальную платформу Линукс, как для других платформ.
Спасибо за ответ. Да, я видел что для 12.3 они выложили FMX for linux, хотя лучше бы конечно он был частью самого продукта, а не надстройкой.
С CrossVCL вопрос пока остаётся открытым. Для Emb данный проект скорее в минус, т.к. они стараются перетащить всех с VCL на FMX, но технологически проект был интересный и мы щупали демку - простое VCL приложение без сторонних компонентов успешно скомпилировалось и запустились в Линуксе.
По мне так проблемка сейчас в том, что штатно в дистрибутиве нет некоторых весьма важных для современной отрасли компонентов - поддержка Websockets, MQTT , подключения к удаленным базам данных при использовании FireDAC под мобильными системами, поддержка из коробки именно, а не покупкой сторонних компонентов. Плюс, возникают проблемки, когда хочешь использовать в FMX приложении компонент, который частично использует VCL для вторичных своих задач.
Маркет библиотек и компонентов неплохо начал, хотя и медленно развивается. Можно было бы интегрировать тот же awesome pascal перечень.
Жив ли Delphi в 2025 году? Погружение в технологии, релизы и мнение сообщества