Comments 171
В середине 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 тыс. руб. Потом официальные продажи прекратились, но старые лицензии работают, просто обновления недоступны.
Вы имеете ввиду автообновленият типа под баги и тп? Оно вроде должно работать через впны.
Нет. Я имею в виду обновления на следующую версию. Пока мы платили эти 35 тыс., нам всегда была доступна актуальная версия. Если не продлевать, на на последней версии можно работать и дальше, а вот новые не будут доступны.
Что качается патчей, то они также теперь нам недоступны из-за закрытия доступа в личном кабинете. Типа мы подписку же эту не оплатили, а оплатить и не можем сейчас :-)
Держались до последнего. Только в конце прошлого года перестали продавать в РФ из-за санкций. В поддержке клиента думаю не откажут. Мы спокойно общаемся, создаём тикеты в системе багрепортов и т.д.
Когда то начинал с него. И до сих пор если надо под win пишу на нем. Просто теперь в основном пишу на cpp под микроконтроллеры или что то серверное ( пайтон, пхп, и прочее)
Вот так и не понял. Если сейчас есть задача побыстрому сбацать что то с формами под винду- какая есть альтернатива дельфи?
Вот только вчера была утилитарная задача - надо ввести три числа и рассчитать результат по определенной формуле. Написание такой утилитки под win на дельфи заняло примерно минут пять. И я могу скинуть exe как результат любому человеку, он у него запустится и он тоже сможет пользоватся. А какя современная альтернатива? - сделать то же самое за 5 мин?
Если сейчас есть задача побыстрому сбацать что то с формами под винду- какая есть альтернатива дельфи?
С# и WinForms, есть бесплатно в VS Studio Community из коробки, запускается везде где есть .NET Framework.
Edit: Только я вот не помню, не выкинули ли в новых версиях WinForms в пользу WPF.
А если так же быстро накидать, только кроссплатформенное приложение и без зависимостей?
PascalABC.NET?
C#, дизайнер там есть
C# имеет дизайнер для Winforms и WPF, которые не кроссплатформенные. Для остальных фреймворков нет дизайнеров. Avalonia и прочие, несколько менее известно максимум могут иметь LivePreview
Не находишь, что 3000$ за кроссплатформенный дизайнер форм слишком дорого?
Даже за хороший.
Кстати, вероятно благодаря дизайнеру, Винформс до сих пор и поддерживается.
Собственно, ответ получился развернутым, достойным отдельного поста.
Если сейчас есть задача побыстрому сбацать что то с формами под винду- какая есть альтернатива дельфи?
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 движок и Делфи, кстати, тоже имеет, правда сильно примитивнее из коробки
Что вы за ерунду несете? Вы это сейчас всё серьезно написали или это такой вид "забавы"?
"2 поля и кнопка" - это гипотетический пример, описывающий простую программу, а не буквально 2 поля и 1 кнопка.
Delphi - язык, моложе Питона на 4 года, однако Питон почему-то стильный-модный-молодежный, а Delphi, который релизится каждые пол года, - "ужасное старье".
С какой стати вы решили, что я "не желаю развиваться", вы сюда с "Битвы экстрасенсов" пришли? Я думаю что да, ведь умом вы тут точно не блещете. Оправдываться и называть все языки и инструменты, которыми я владею - я не собираюсь.
Выбор того или иного языка обусловлен не столько наличием готовой реализации, сколько знаниями, умениями и опытом человека, который хочет решить задачу, потому что большинство языков (экосистем) одновременно имеют эти реализации в готовом виде. Использование CUDA ядер, работу с OpenAI, звуком, видео, изображениями, 3D рендером, например, реализовано на многих языках.
Создание GUI - это тоже из области "готовых библиотек и реализации функционала" и именно в Delphi эта часть реализована лучше, чем в большинстве языков.
Так почему я НЕ должен выбирать Delphi, если на нем имеются готовые библиотеки для решения задач?
Создание 3-х мерной формы, прямо на рабочем столе, для Delphi - это такая же пара минут, как и "2 поля и 1 кнопка".
Здесь я написал всего 10-20 строк кода.
Предложите инструмент, который решает эту задачу быстрее и проще.
Наверняка всё так. Но зачем программа с тремя полями и кнопкой. Зачем платить за иде и учить это всё? Чтобы за 2 минуты такое мочь?
Если это не на продажу, то бери бесплатную версию среды и делай бесплатно. Учить в случае js и html нужно гораздо больше.
Понимаю, согласен. И действительно инструмент для этого очень приятный.
Несмотря на то что можно такое и иначе сделать. Но сам себе в своё время делал похожее через Delphi
Я собственно среагировал на то, что это указывается как килер-фича. Вот с этим мне согласится сложно.
Мы же понимаем, что спускаясь на этот уровень, мы собственно обсуждаем нишу всяких скриптовых питонов, пхп и иже с ними. Ниша таких утилит ограниченна, будет существовать всегда и жить будет долго... но тут в этой нише.
Если програть нужно только такие утилиты, то оно понятно. А если её развивать придётся? А если её срочно портировать придётся на другую OS, а уже написана на VCL была... А как доставлять этот бинарь до пользователя?
Я спрашиваю всё это - поскольку не представляю как это делается в реальной жизни. Как у меня это сейчас - я понимаю, а как с использованием Delphi - вообще нет.
Всё это справедливо для любого компилируемого языка, а не только для Делфи.
Десятки лет пользователи устанавливали и устанавливают программы и проблем и вопросов с этим не было. Ты либо скачиваешь программу или инсталлятор, либо устанавливаешь через пакетный менеджер, либо устанавливаешь из магазинов.
Обновлять можно, скрыто (при запуске), можно через диалоговое окно или баннер. Можно обновлять через магазин в автоматическом или ручном режиме.
На мобильных телефонах в большинстве своем именно приложения - программы и это никого не удивляет.
Программы, в отличие от сайтов могут быть автономны. Они могут не требовать постоянное подключение к сети и могут работать, даже если разработчикам надоело держать сервер. Программы просто напросто надёжнее. И если интернет сейчас почти повсюду, то вот от закрытия сервера никто не спасет.
Если ты пишешь программу на VCL, ты должен понимать, что этот фреймворк предназначен исключительно для Windows. Хотя, даже подобную проблему можно решить через CrossVcl, инструмент, позволяющий собирать Vcl-приложения для других платформ.
Но даже если не брать в расчет CrossVcl, переписать требуется только GUI, на кроссплатформенный фреймворк (FMX). А вся кодовая база останется в неизменном виде. Можно даже вести параллельно проект на этих фреймворках.
Да - мобилки это сторы, с проверками на их стороне... С web - уже как я понимаю проще. Я хз как оно там делается, но у меня web админка обновляется мгновенно.
Мне проблемы фронтов - мало известны, но я понимаю, что создание UI в нативных приложениях на котлине и свифте - это и есть нативные приложения для целевых устройств. С использованием прямых инструментов и подходов и элементов и вот этого всего. Которые меняются с выходом новых версий дроида и iOS.
Создавая сколь ни будь приличную систему, у меня возникает вопрос, а зачем страдать от наличия VCL, CrossVcl, FMX - чтобы что? Завтра узнать как в случае с ксамарином от майкрософт - всё этот фреймворк больше не поддерживается?
Как будет смотреться UI на всех этих фонах CE, хуавеях и прочем зоопарке устройств... одному хонору известно.
Ведь именно по этому все радуются что приложение написанное 10 лет назад на делфе комплируется и работает на новой Винде - и ведь почему, да потому, что использует родное win api внутри, а его майкрософт не трогает ))
Радует такое - конечно, нужно это кому-то, наверное да, но может и не нужно на самом деле.
Ну а переходя к серверной части, тут я совсем не понимаю зачем использовать делфю. Тут такой выбор из инструментов, таких-же взрослых, и простых и сложных, и мощных и недорогих. На любой вкус и на любую зарплату.
Пример шуточной реальной утилиты: как-то на каком-то вечернем симпозиуме по поводу пятницы 13-е, возник вопрос - а сколько их в году и календарик бы к ним. Ну тут же накидал формочку в которой вводишь год, а она тебе список и календарик. Очень давно дело было, но недавно с удивлением узнал, что кто-то этой утилитой пользуется %)
Если бы там был под капотом какой-то интерпетируемый язык, который надо специально ставить/обновлять, или сервер, который надо поддерживать, то померло бы еще лет 10 назад. А так вот exe-шник - запустил - работает.
Вот-вот. Мой пример. У AutoCAD есть классная штука, он логгирует действия и всякую инфу в текстовый файл.
Соответственно - есть чертёж, в моём случае карта, выбираешь объекты на чертеже, даёшь комаманду info и там в файлике куча полезной инфы. И да, взял делфю сделал себе утилитку, из регистри получил путь где файлик лежит, распарсил и получил в нужном формате файлик уже для импорта в систему геологического моделирования.
Класс.
А сейчас: консюмер в 12 инстансах на чтение из кафки, паттерн outbox сюда и outbox туда, консольное логгирование и так чтобы в логах 25 сервисов развернутых на 4х ДЦ всё было можно найти, а ещё метрики в графану разумные отправить нужно. И всё в трёх контурах: dev/stage/prod
Жесть короче ))
Создавая сколь ни будь приличную систему, у меня возникает вопрос, а зачем страдать от наличия VCL, CrossVcl, FMX - чтобы что? Завтра узнать как в случае с ксамарином от майкрософт - всё этот фреймворк больше не поддерживается?
Всё точно так же, как и с любым фреймворком на JS. Зачем писать на X фреймворке, если этот фреймворк через год станет заброшенным и появится десяток новых? Более того, существует вероятность, что ваш сервис вовсе перестанет работать, если зависимость внешняя и не выгружена локально на ваш сервер (как недавно было с некоторой JS библиотекой).
Среду разработки и этот фреймворк (Delphi, FMX), который у тебя на руках, ты можешь использовать сколько угодно, даже если этот фреймворк перестанут развивать. Потому что у него ещё меньше зависимостей от ОС, чем у VCL. Т.е. ещё более устойчиво к изменениям winapi.
Сноска
Любое приложение на Windows использует winapi, прямо или опосредовано. VCL - это обертка над отдельной большой частью winapi. FMX её не использует, а использует только необходимый минимум для запуска приложения, который вообще вряд ли поменяют когда-либо.
Как будет смотреться UI на всех этих фонах CE, хуавеях и прочем зоопарке устройств... одному хонору известно.
FMX? Ровно так же как и 10 лет назад. Без каких-либо изменений. Т.к. внешний вид и функционал определяет именно фреймворк.
Я хз как оно там делается, но у меня web админка обновляется мгновенно.
Телеграм у меня (на ПК) обновляется в один клик по баннеру, когда есть обновление. И занимает обновление секунды 2-3. Не дольше, чем обновить страницу в браузере. Т.к. обновление заранее скачивается и потом появляется баннер. Если имеется магазин, то ты даже не будешь знать, когда у тебя было обновление. Ты просто запускаешь приложение и оно новое. У вас на мобильном телефоне приложения обновляются регулярно. Не думаю, что это вам как-то мешает.
я понимаю, что создание UI в нативных приложениях на котлине и свифте - это и есть нативные приложения для целевых устройств. С использованием прямых инструментов и подходов и элементов и вот этого всего. Которые меняются с выходом новых версий дроида и iOS.
FMX - фреймворк для не нативного UI, однако существует и другой фреймворк (FGX), который уже позволяет одной кодовой базой создавать для iOS, Android UI-нативные приложения. Однако, прошу заметить, что, скорее всего, больше половины приложений на вашем телефоне использует не нативный интерфейс (или не нативный вид нативных элементов). Например, вся экосистема Яндекс-приложений.
Но и у не нативного UI есть свои плюсы, вид этого приложения никогда не меняется. На какой бы версии платформы он не был запущен. Пример - те же Яндекс-приложения.
Ну а переходя к серверной части, тут я совсем не понимаю зачем использовать делфю. Тут такой выбор из инструментов, таких-же взрослых, и простых и сложных, и мощных и недорогих. На любой вкус и на любую зарплату.
Как и в Делфи. Множество разных бэкенд-фреймворков на любой вкус и любую сложность. Плюс ко всему, я могу использовать код бэкенда для сборки клиентских приложений. Например, я используют одни и те же DTO классы и для бэкенда и для клиентов, одни и те же константы из одних и тех же файлов. Другими словами, при создании клиент-серверного решения, я создаю 3 репозитория: клиентское приложение, сервер и общие модули. И мне не требуется описывать и дважды обновлять классы с данными между клиентом и сервером. Расширил DTO для новой функции, оно автоматически расширилось и для клиента, достаточно затянуть изменения и использовать новое поле. Это значит, что мне достаточно один раз описать ORM-класс таблицы и я могу использовать его и на сервере для запросов и на клиенте при получении данных с сервера (похоже на упрощенный RPC, не требующий конвертации моделей).
Я использую удобный мне инструмент для создания приложений - Delphi. Мне нет смысла использовать, например node.js, когда я с такой же легкостью и дополнительными преимуществами, о которых писал выше, напишу бэкенд на Delphi. И не будет никаких проблем, если этот же бэкенд будут использовать для создания браузерных решений (собственно у нас и есть уже так). У нас есть общий бэкенд, который реализует некоторый функционал, который применяется в клиентских приложениях и частично в браузерных. Хотя для браузера, разработчики уже используют OpenAPI спецификацию (конечно же, во многих фреймворках Делфи есть, автогенерация OpenAPI), а я могу просто использовать код бэкенда, что на порядок быстрее. Вдобавок ко всему, нам не требуется нанимать дополнительных разработчиков, ведь уже есть в компании те, кто пишет на приложения на Делфи.
Всё точно так же, как и с любым фреймворком на JS. Зачем писать на X фреймворке
Наверное так, react | angular - имя им легион, вроде как на js
Пишут отлично - под разные браузеры. Наверное и на делфи так-же. Просто есть сомнение, что библиотека для одного языка и для одного компилятора - прослужит достаточно долго. Верю, что прослужит. Страдание от зависимостей у фронтов на js - наверное да, какие-то страдания есть. Упаси господь заниматься фронтом.
FMX? Ровно так же как и 10 лет назад. Без каких-либо изменений. Т.к. внешний вид и функционал определяет именно фреймворк.
Наверняка да, как определяет фреймворк, но не так как решит iOS или дроид и возможно не так как решит совет по дизу.
Если имеется магазин, то ты даже не будешь знать, когда у тебя было обновление. Ты просто запускаешь приложение и оно новое. У вас на мобильном телефоне приложения обновляются регулярно. Не думаю, что это вам как-то мешает.
Обновление мобильного приложения, на сколько я понимаю, ни чем не отличается от того где оно создано. Кем-то создана apk - отправляйся на проверку и выкладывайся в стор. Дальше проблема пользователя. У меня что-то само обновляется, что-то нет, хз как оно там работает. Если делфя собирает apk (или как она там называется) - то всё отлично. Тут выше предлагали exe на диск выкладывать и ярлыком его запускать - вот такой путь уже забавен.
Как и в Делфи. Множество разных бэкенд-фреймворков на любой вкус и любую сложность.
Мне это не очень знакомо - в golang фреймворки не частые гости в проектах. Чаще всего всё руками, ну или годогенерация - её я как-то недолюбливаю.
Плюс ко всему, я могу использовать код бэкенда для сборки клиентских приложений.
Да - прикольная возможность, язык ведь один. На сколько это удобно если команда фронтов одна, а бэка другая - мне пока не понятно. Про ORM ничего не скажу, хз что это. Мне привычно, что есть описание json у некого api - его придерживаются и всё.
У нас есть общий бэкенд, который реализует некоторый функционал, который применяется в клиентских приложениях и частично в браузерных. Хотя для браузера, разработчики уже используют OpenAPI спецификацию
Тут я потерялся )) Есть какие-то клиентские фронты написаные на делфи с FMX которые ходят к http серверу написанному на делфи? Но являются вероятно исполнимыми файлами Win
И есть команда фронтов пишущая уже не на делфи для браузера - так? А клиентское приложение собрать как браузерное нельзя?
Мне привычно, что сервер - оторван от фронта. И как бы это сделано намеренно. Он является http или grpc сервером, с описанным апи. Кто на той стороне его дёргает, зачем, когда - уже как бы не дело сервера. Всё прикрыто балансерами и ингрисами для удобства управления трафиком. В принципе на чем написаны эти сервера - не важно, где крутятся - не важно.
Похоже что с делфи можно создавать что-то аналогичное.
Но на серверной стороне у меня одна любовь - golang
Это на столько красивая и классная штука ))
За делфю рад, не верю что попытка усидеть на двух стульях закончится успехом, но миру от моей веры и неверия, не холодно не жарко.
Бэки на js (node.js) страдают от зависимостей не хуже фронта. Не очень давний пример - нужен маленький rest сервис для интеграции с платежной системой, буквально на 2 эндпоинта. Ну делов-то - накидали пару экранов кода на ноде, развернули, запустили - красота.
Через год понадобилось развернуть сервис на другой машине, и тут началось: ой, а у нас уже нет этой версии библиотеки в собранном виде. Если очень надо - вон сорцы, скомпильте библиотеку работы с оракл сами. Ну или возьмите новую.версию библиотеки. Новая версия - 32-битная вервия драйверов - фу-фу-фу, только 64 бит... Ну на тебе отдельная инсталяция oracle client 64-bit. Как не видишь пути? Все вменяемые библиотеки обходят обходят все предложенные версии библиотек, а ты не умеешь? Ну вот тебе жесткий путь к нужной версии OracleClient. Тут NestJS заявляет, что он тоже старый и не гарантирует работу с новыми библиотеками доступа - меня бы тоже обновить. После обновления прога тупо не собирается. По факту там один аргумент поменялся в функции, но чтоб найти что не работает пришлось пересобрать проект с нуля.
Да, мне не хватало знаний чтоб локализовать ошибку. Более квалифицированный человек, возможно, сходу бы решил.
Но вот сам подход, что развертывание небольшого проекта тащит из интернета тучу кода, который потом пытается скомпилиться транспилироваться из ts в js и падает на ошибках несовместимости параметров функций...
Я конечно не настоящий сварщик, наверно есть рецепты как с этим бороться, но на фоне монолитных исполняемых файлов я испытал неприятный вайб от починки мелкого интеграционного сервиса с архитектурой "скачаем вот всё как в настроечном файле настроено"
Но на серверной стороне у меня одна любовь - golang
Это на столько красивая и классная штука ))За делфю рад, не верю что попытка усидеть на двух стульях закончится успехом, но миру от моей веры и неверия, не холодно не жарко.
Если смотреть с серверной стороны, то Дельфи примерно между Го и С/C++. У нее все объекты распределяются в heap (Гусары и Д'Артаньяны молчать - можно всякое наворотить, но если вам такое нужно, то идите в С). Но с другой стороны там нет гарбаж коллектора. Автоматический подсчет ссылок? Вам надо в интерфейсы - оно там само считает и освобождает.
Давно смотрю на Go и он мне афигенно нравится. Но почему-то ощущение, что на нем можно сделать утилиту типа grep, но вот сервис а-ля фрирадиус или будет жить в перезапускаемых контейнерах недолго но продуктивно, или сдохнет за сутки когда придет stopworld и сервис просто не сможет переварить udp-пакеты
Мы живем в контейнерах, это да, но аларм на перезапуск пода в контейнере - это прям уже инцидент.
Сервисы предоставляющие http сервера и обслуживающие большую нагрузку - вполне могут жить произвольно долгое время. Собственно гошка и хайлоад - синонимы.
Уронить гошный сервис нагрузкой можно, как и всё на этом свете, если там нет защиты
Если поясните что такое stopworld и что такое udp-пакет наверное смогу ответить точнее
Но зачем программа с тремя полями и кнопкой
Это целый класс микро-приложений, примерно как из области - а зачем нужны продвинутые скриптовые языки, но только в GUI.
Например, пример какого-нибудь расчета. Или опрос приборчика.
Или и таких много - GUI для консольных утилит, где визуально выбираются параметры, коих вагон и помнить неудобно.
Вот пример такой утилиты. Python + tk
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
Чемтно - выглядит ровно также, как я её и помню :)))
Ну смотря с какого времени сравнивать. С версиями до 2009 колоссальная разница, после 2009 добавили скины, убрали лишним линии, выпуклости, вкладки имеют цвета, в среде появился сплит для редактора, вынос окон по отдельности или группами, скроллбар теперь с аннотациями, добавили управление светлым/темным режимом, добавили межстрочный интервал, новые шрифты для редактора, избавились от вебвью на главной странице, теперь там можно организовывать свой рабочий стол с возможностью добавлять плагины туда, обновили и расширили окно автокомплита, добавили удаление размером шрифта, кодировкой и типом подсветки внизу редактора.
И многое всякое. Все что вспомнил
У Delphi был ряд действительно не самых удачных версий с разнообразными глюками как IDE, так и, что хуже, компилятора. Я поэтому пережидал на проверенных XE5, XE8. Сейчас вот и 11 и 12 достаточно стабильные.
LSP, конечно, по прежнему глючит, Ctrl+Space тоже иногда отваливается, и компилятор почти всегда не в состоянии скомпилировать проект с первого раза, но на качество работы и сборки это влияет не столь сильно - полный ребилд за 20сек не так страшен.
Но вообще подумываю, что пора дробить проект на части (DLL или BPL), т.к. 500к строк кода Делфу явно нагружают больше, чем ей хотелось бы.
Я бы сказал, что делфи - самый высоко прыгнувший из компилируемых языков к современному мейнстриму (Java, C#, Kotlin - думаю это языки самой мейнстримной парадигмы)
C++ это конечно стандарт, но очень расплывшийся и полный дыр и старья. Батя так сказать. Если бы не существовало JS, Я бы не любил его больше всего)
О, меня оказывается тоже отстранили от MVP, хотя я несколько раз сдувал пыль с делфи, когда делал хотфиксы и обновления на игру.
Да, он самый, Я помню заморачивался)
А по поводу игры - конечно публикуй, мне кажется это хороший кейс для опен сурсных проектов - иметь, так сказать, понятную точку входа.
С 1995 года сеть магазинов работает на комплексе программ написанных на Дельфи. 30 лет... Это же уму непостижимо. И развивается, и расширяется, и не требует сотен программистов. Попытки перевести всех в веб регулярно проваливаются, люди не хотят и всё тут. Да и платить лишние деньги, зачем?
Конечно, всё общение с внешним миром через АПИ на Го, но внутри компании Дельфи правит миром.
Так и живут.
А чего бы им не жить когда все работает... Там же софт не ради софта а для решения задач бизнеса. И пока задачи бизнеса решаются - будет жить.
В Дельфчми не имел дело, много писал на 6-м билдере. Под винду - самое оно.
Упоминавшиеся тут wxWidgets - это совсем другое. Тут и Qt можно приплести и GTK, но там все сложнее и своя идеология. А аналогов дельфи/билдера, сравнимых по удобству и скорости решения простых типовых задач, пожалуй, так и нет.
Эх, ностальгия..
Этот язык, на пару с паскалем, сделал меня разработчиком. Даже на полках пылятся старые проекты, 3д движки и прочие игры.
Но сейчас не пользуюсь - не та инфраструктура, не те задачи..
Мой любимый Total commander написан на Delphi.
А мой любимы Double Commander на Lazarus (под линукс есть два варианта - с Qt и с GTK)
На Delphi 2, странноватый какой-то автор этой софтины, за 30 лет не осилить в рефакторинг
Это его сознательное решение.
Ну и, предполагаю, дело также в обратной совместимости. Возможно, в его случае проще самостоятельно поддержать новую ОС, зная WinAPI и всё попутное, чем постоянно гнаться и подстраиваться под новые версии RAD, лишив юзеров поддержки старых ОС и/или себя -- выбранных преимуществ 2-ой версии.
В своё время, TotalCmd был центром моей вселенной. Это была тулза #1 для всего. Настраивал плагины, кнопочки в тулбарах, цвета, писал конфиги, изучал сторонние сборки... Вот только своих плагинов не писал, а так наизусть его облазил. Но наигрался. В какой-то момент просто стало хватать виндового Проводника. А потом и с винды ушёл.
С обратной совместимостью в Дельфи проблем практически нет.
В своё время, TotalCmd был центром моей вселенной.
Для меня он и сейчас центр вселенной. Плагины есть практически для всех задач. Плюс из коробки огромное количество возможностей.
Наверное, надо статью запилить по его возможностям ))
Сам активно использую 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 запрос на сервер, получить ответ, впихнуть все это в адаптер, прикрепить к таблице и созерцать данные с сервера в дизайнтайм, без единой строчки кода.
Это потому что не надо использовать TDataSet в прикладных программах. Это базовый класс для всех прикладных потомков, которых и надо юзать в программе. Единственный резон наследовать этот класс - если вы сами хотите реализовать какой-то свой экзотичный dataset, но аккуратно это сделать работа сильно сложнее чем пользоваться датасетами в прикладных целях.
Навскидку в моих проектах чаще всего используется
TClientDataSet (иерархия классов TClientDataSet <-TCustomClientDataSet<-TWideDataSet<-TDataSet), если это клиентское приложение работающее с локальными данными.
TOracleDataSet/TOracleQuery (TOracleDataSet<-TDataSet) если работа с базой и не связана с визуальщиной - TOracleQuery крайне плохо дружит с теми же гридами - все будет тормозить при скроллах.
Если нужна и база и визуальщина, то связка компонентов будет следующей (дальше не иерархия наследования, а логическая связь компонентов):
DbGrid - TDatasource - TProvider - TOracleDataSet. Да, выглядит переусложноненно, но зато позволяет растащить это по трехзвенке - первые два клиент, вторые два сервер приложений. И да, оно просто накликивается мышкой в простейшем варианте - фактически трехзвенка мышкой.
Вот, мне всегда было интересно, кто-нибудь пытался что-то сделать на базе TDataSet.
Ну, я делал свой датасет для стрёмного кастомного протокола, который выплёвывал данные из DB2 на AS/400. Там надо было унаследовать десятка полтора методов, насколько я помню, но в общем случае половина из них могла быть просто затычками. Не так чтоб и суперсложно.
Мне ещё было всегда интересно (но сам я так и не решился попробовать), можно ли создать экземпляр TDataSet налету.
А что вас удерживало-то от эксперимента?
Это, скорее, такая концептуальная проблема Delphi: слишком многое завязано на визуальное проектирование
Визуальное проектирование в Delphi вам на выходе давало JSON-подобный скрипт с описанием формы, который потом просто выполнялся в рантайме десериализатором. Всё то же, естественно, можно было делать и программным путём, в этом и красота, и простота архитектуры Delphi.
Это, скорее, такая концептуальная проблема Delphi: слишком многое завязано на визуальное проектирование, а хотелось бы иметь некую концепцию управления программными объектами, допускающую расширение
Всё что ты можешь создать визуально, ты можешь без каких-либо проблем или сложностей сделать и кодом. Дизайнер Делфи не создает магический код, а простое описание того, что (какой контрол или компонент), где (положение в иерархии) и с какими свойствами (ключ/значение) создавать. Создание кодом тоже часто практикуется в Делфи, особенно, когда ты не хочешь создавать дизайнтайм пакет для визуального/невизуального компонента.
Например, моя библиотека для работы с OpenAI. Тянешь репозиторий с гитхаба и ты можешь установить пакет и использовать невизуальный компонент, а можешь ничего не устанавливать и создать компонент исключительно через код.
var OpenAI: IOpenAI := TOpenAI.Create('sk-your-token');В Delphi есть свои шикарные библиотеки типа DevExpress
Если мерить по количеству свистоперделок, уровней наследования и по количеству уровней наследования свистоперделок, то да, DevExpress вне конкуренции.
Исследуя их исходники как будто бы да. Но вот кто-то смог в обычном гриде повторить всю функциональность Excel? Сортировка? Да. Сортировка по нескольким полям? Да. Инкрементальный поиск по столбцу - да. Группировка по полю - ну драг'n'дропни в поле под хедером. Локальные для групп summary поля - min, max, count, avg...
Ну вот круче только PivotGrid от того же DevEx
Старый добрый EhLib ещё, например. Он по функционалу, конечно, попроще, но зато в нём нет этого дикого оверинжиниринга
Спасибо за подсказку. Надо посмотреть. А то от засилья DevEx немного страшно - он классный, он на всех платформах, но там тысяча неочевидных классов внутри. Когда прилетает exception, то там call stack хуже чем в java (парни, извините, но у вас такие длинные callstack, что в tail не помещается (шутка, не обижайтесь))
А оно умеет в пивотинг или дрилл-даун?
А там можно пересортировать столбцы с колонками мышью? И раскрыть ячейку для более подробного анализа? (это не спор и не соревнование между фреймворками, просто интересно)
Стюардесса мертва, но тело ее живет.
С 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 перечень.
Нашел тут свой курсач за 98 год - первый опыт оконного приложения (интерфейс на Билдере, работает со звуком через Win32 API). Все спокойно запустилось на Win 10.
Смогу ли я более чем через четверть века запустить (без бубнов) сегодняшние свои проги (C# WPF) - большие сомнения.
Мой основной язык -1С. На Дельфи в виде отдельной Dll пишется то, что невозможно сделать в 1С (распознание datamatrix с картинки), либо выполняется адски долго (хэширование миллионов строк md5) ну или закрытый код 1С и работает у сотни клиентов и на паре заводов уровня страны, продукцию которых вы видите каждый день в сетевых магазинах.
Дельфи прекрасно своим охерительно простым механизмом работы с Idispatch. Как страдают 1Сники при создании внешних компонент на C++/ C# достойно отдельной саги.
Недавно узнал про фишку работы с объектами через их интерфейс с контролем числа ссылок и уничтожением объекта при обнулении, без вызова free(). Кто нибудь в курсе, это используется в продуктиве?
Давайте так, такой среды, где можно писать нативные приложение, без всяких платформ типа .net или java почти нет. Язык сильно проще c++, огромное количество фреимворков, быстрая разработка графического интерфейса и уже кросплатформенность
К сожалению на делфе я денег не зарабатывал, по этому права голоса не имею ))
Вопрос. А не кажется ли, что по сути главным отличием от мейнстрима, является то, что делфя и не фронт и не бэк? А именно сразу вместе?
Бэком вполне может быть. Есть и фреймворки и разные orm отдельно. Под Линуксом прекрасно работает. У нас несколько бэкендов переписано с Питона на Делфи.
И фронтом в браузере Делфи может быть, через трансляцию (pas2js). TMS Web Core, например. Ещё есть UniGui, с другим подходом (северный рендер).
Не мейнстрим он, потому что не опенсорс.
Использовать Delphi для бэка наверняка можно, но вот зачем - тут я не очень понимаю. На бэке точно есть опенсорс решения и вполне заточенные для этого, очень удобные, очень мощные, очень бесплатные и при этом абсолютно промышленных масштабов.
Ну на фронте тоже есть специализированные инструменты, как под платформы, так и под стандарты этих платформ.
Собственно разделение фронта и бэка состоялось скорее всего именно из желания использовать специализированные инструменты.
Не вижу причин отказываться от Делфи в бжкенде. Делфи у нас в компании используется для создания главного нашего продукта. Отдельные или внутренние приложения мы тоже пишем на Делфи, так почему бы и бэкенд не писать на нём? Этим вопросом в нашей компании я задался 2 года назад, когда мне надоели проблемы с бэкендом на Питоне, который делала отдельная команда. Я полностью переписал весь бэкенд на Делфи и все проблемы с производительностью, развертыванием и добавлением функционала ушли.
Если есть экспертиза в стеке, если стек уже годами устаканился и решает проблемы, то действительно причин его менять нет. Хрен на хрен менять - только время терять ))
Уверен детские болезни с хитрыми системами подключения к базам данных, ко всяким кафкам и редисам - в прошлом.
Про питон ничего не скажу - динамическая типизация не моё, я не могу этого переварить, наверное если припрёт - смогу, но надеюсь не случится...
Совершенно не кажется. Говорю как один из соавторов трехзвенного приложения (CRM модуль биллинговой системы) на 200+ окон. Совершенно органично пишутся как клиентская часть, так и бэк (сервер приложений). Архитектура: тонкий клиент/сервер приложений, связь по DCOM.
Доставка тонкого клиента на устройство пользователя - это какой-то инструмент?
Сервер приложений в кубере запускается, через докер и ci/cd гитлаба развёртывание ?
Для мобилки свой клиент пишется?
Дизайн UI для клиента в Figma создаётся?
Мне известен просто только такой подход - у этого подхода соответственно свои возможности ну и свои ограничения, по этому и спрашиваю.
У нас мобилки + web и серваки на golang
Отвечу по некоторым пунктам от себя. Я тоже пишу бэкенд на Делфи.
Да, Делфи легко развертывается в докере и может собираться через GitLab ci/cd. У нас все именно так работает. Только докер нам не нужен.
В делфи нет зависимостей и нет нужды в настройке окружения. GitLab запускает сборку бэкенда и деплоит его на сервер в виде просто бинарной программы. И перезапускает север.
Дизайн для клиента, например у нас, создаётся в figma, да. Потом переносится в проект.
Если нужно мобильное приложение, то я просто собираю этот же проект под мобильную платформу. Если нужно, могу специально для мобильного экрана подправить (не сделать новую, а именно подправить) форму. Сдвинуть что-то, изменить текст, размер и т.д. Эти изменения будут применимы именно для конкретной платформы и/или размера экрана. Либо, можно изначально писать адаптивный интерфейс. Например, у меня в GitHub есть приложение ChatGPT, который имеет адаптивный интерфейс и этот один проект в неизменном виде собирается под все платформы.
У нас в докере тоже нет ни каких зависимостей. Но докер используем для другого. В одном образе (в котором есть компилятор гошки) собираем бинарь, а потом бинарь пихаем в образ с голым альпайн и уже его отправляем в кубер.
С точки зрения серверной части похоже существенных различий нет. Это радует за мою юношескую любовь ))
Ну а про фронт - тут я на чужом поле, не мне судить о простоте, надёжности и удобстве создания клиентов для всех видов мобилок и вэбки.
Доставка на клиент - samba сервер - зачем что-то куда-то доставлять, если можно сделать ярлык на расшареный каталог сервера. Речь конечно про работу внутри корпоративной сети. Делали версии с автообновлением клиента (через ftp или http), но оно вобщем-то не нужно в такой конфигурации сети.
А зачем нужен докер, если сервер приложений можно запустить на железном сервере?
Для мобилки клиента нет - это кровавый энтерпрайз для телекома - там в окнах иконки кнопок в одну строку не влазят 8-\ По этой же причине никакой фигмы - и вообще зачем она нужна, если быстрее накидать концепт интерфейса прямо в дельфе и сразу показать заказчику?
Да, понял. Видел такие системы визуально, в лукойле например, вот в ростелекоме тоже.
Но энтерпрайз он разный, не все идут по пути бинаря на диске W:/
У нас тоже энтерпрайз, но и фигма и вэб админки и всё вот это. Клиент - либо просто браузер (любой), либо мобилка. Соответственно работа с любого устройства удалённо.
Мне известно, что на Delphi написан биллинг и чего-то там ещё в ростелеком например. В качестве базы - Oracle. Не буду переобуваться в Вангу, но боль им предстоит испытать.
За что любил Delphi. То что ты сделал билд. Отдал клиенту. И тебе пофиг какая у него винда. Все работало из коробки. Кто-то скажет что есть же .Net. Но с какой версии винды, эти приложения стали запускаться на чистой винде? Когда-то ругали delphi что исполняемые файлы толстые, но теперь размер приложения перестал иметь значение.
Сейчас напишут, что .net в винде идёт из коробки. Только я не помню с какой версии винды и какой версии .net
Для этого есть интернет. Таблица
И приложение под предустановленный NET конечно, маленькое.
Толстые... хаха... Тут видел под андроид калькулятор, банальный, но весил 200Мб!!!! 200Мб Карл!!!! Просто калькулятор...
Прекрасный продукт, Delphi 7 всегда лежит в папочке на случай когда нужно быстро накидать какое-то приложением для Windows и не тащить с собой кучу зависимостей и другой белиберды, и один exe-файл работает на 90% ОС от мелкомягких. А это проблема, у многих заводов и ВПК до сих пор стоит Windows XP, а бывали машины и с Windows 98 и это в 2020-х годах... Несколько раз наблюдал следы предыдущих подрядчиков, попытки установить nodejs или питона, но как сказали сотрудники: "что-то у них ничего не взлетело"...
И вот где-то год назад под один проект нужно было сделать мобильное приложение для работы с серверами и тех.оборудованием. Я ни разу не делал ничего для мобильных устройств, и погуглив наткнулся что на Delphi можно написать без сильных проблем... решил попробовать, и за несколько дней написал. Работа с серверами была реализована банально через restapi, а вот было технологическое оборудование где был свой проприетарный протокол реализованный поверх udp, и это все сделал на старой доброй Indy, и все с полпинка заработал на мобилах/планшетах, был даже в шоке.
П.С. Пару раз натыкались на станки где стоит MS-DOS а управляющее ПО написано на таких вещах как FoxPro или Clipper. И это все пашет без поддержки десятки лет, и даже не уверен живы ли программисты которые это все писали.
Одна из причин почему Delphi теряла популярность, это еще по тем временам очень большой размер исполняемых файлов, с этим кто как боролся, но это не помогало.
Но Delphi(хотя как и Visual Studio) уже тогда предлагали в своем арсенале удобные визуальные инструменты отладки, из коробки.
Сейчас если вы хотите дебажить что-то, то руками из терминала и с бубном, по крайней мере в большинстве случаев.
Жив ли Delphi в 2025 году? Погружение в технологии, релизы и мнение сообщества