Comments 64
— нативный компилируемый код, имеющий максимальную производительность
— маленькие по объему приложения, включая минимальное потребление ОЗУ и процессора в большинстве типовых случаев
— быстрая разработка UI, здесь на самом деле «формошлепство» по праву лучшее)))
— простая связка UI и данных
— отсутствие необходимости таскания с приложением кучи библиотек, как правило достаточно одного исполнимого файла (в большинстве типовых случаев)
Мне правда интересно, пару лет сам на нем писал, давным давно.
2. Многие не любят Паскаль.
Достаточно сказать, что там даже поддержка Unicode появилась только в 2010-м, да и то кривая. А уж 64-битный компилятор они потом ещё много лет пилили (то, что родилось в 2011-м, состояло главным образом из глюков и багов).
Ну и плюс поставили не на ту лошадь, вложив слишком много усилий в поддержку FireMonkey.
Ну и плюс поставили не на ту лошадь, вложив слишком много усилий в поддержку FireMonkey.Вот здесь я с вами не соглашусь. Именно FMX начала вытаскивать делфи из ямы и без поддержки кроссплатформенности делфи наверное к сегодняшнему дню практически бы умерло.
Да, объективно в плане сравнения с VCL у FMX есть известные проблемы со скоростью и качеством отрисовки экранных элементов. Но вот тот факт, что сейчас можно делать приложения с единым кодом и для мобильных, и для мака и для линуксов, перекрывает все существующие недостатки с лихвой.
А если вспомнить еще и про библиотеку FGX Native, где мобильные приложения визуально вообще не отличаются от нативных, то однозначно можно сделать вывод — делфи развивается в правильном направлении.
UPD. Ниже пишут
Более того, список поддерживаемых Linux-платформ крайне ограниченэто не совсем так. Список дистрибутивов, на которых работают приложения делфи (с использованием FMXLinux) достаточно обширен, упоминается 166 различных дистрибутивов.
Кстати, примерно в годы популярности делфи, больше в маковской сфере, но существовал не менее кроссплатформенный RealBASIC. Может кто на нём писал и в курсе, что там в основе лежало и жив ли он до сих пор?
Для десктоп приложений 500$/год сразу выбивает кучу моделей использования, потому и непопулярна. Выходит что если у вас огромная команда то есть и другие варианты менее завязанные на пожелания разработчика ide а если это "для себя внутри компании с непонятным и нестабильным экономическим эффектом" то это дорого, по крайней мере в России.
Копейки, это когда основная сфера — это разработка ПО, когда по копейке складывается на delphi + компоненты + бд + среда для бд + ...
А вот скорость разработки ПО для мелких организаций как раз очень важна. Плюс лёгкость сборки под различные платформы.
"А вот скорость разработки ПО для мелких организаций как раз очень важна. " Как работавший, могу сказать что, на мой взгляд, не постоянно (хотелось бы больше всегда но, не всегда нужно), вообще собственная разработка(для организаций, доход которых идёт не с ит) она живёт немного не так как разработка на заказчика, на мой взгляд.
- к тому в небольшой фирме разработчик по факту с delphi будет работать 2ч из 8ми(так как он один на всё)… т.е. затраты на конкретное ПО будут для такой организации более высокими чем у специализирующейся на разработке ПО компании которая будет использовать лицензию не на 10-20% а на 80-90%
Нов таком крайнем случае можно вообще ничего не покупать. Есть другие способы.
А вот когда организация дорастёт до штата хотя бы 3-5 человек, хороший инструмент будет играть сильную роль!
То же самое касается электроники. В начале можно пользоваться и китайской станцией за 1000 руб. и самым дешёвым осциллографом, а вот по мере развития уже начинаете «обрастать» серьёзными инструментами.
1. Не все библиотеки, что есть под Delphi, имеются и под Lazarus.
2. По сравнению с Delphi компиляция проходит намного дольше!
Может что ещё есть, не претендую на истину, но для себя вот эти два отмечаю.
Зато он бесплатный, а это уже большой плюс!
Tkinter так-то да, только для Питона. Потому что это реализация Tk на Питоне. Однако...
Отпишу про то, что знаю (Qt):
- GUI старого скайпа написан на дэлфи, нового на электроне. Qt там никогда не было.
- Проблем с компиляцией Qt под windows ни разу не встречал за 9 лет работы
- Правильные флаги компиляции, QtLite, статическая линковка, UPX или аналоги — дают очень маленький вес приложения. Конечно, если есть такая цель. Я ухитрялся заворачивать GUI рантайм с сетью в 8 мегабайт (а Qt4 так и в 5 влазил).
Единственный минус Qt — это некоторые танцы с бубном чтобы заставить одинаково выглядеть сложные QtWidgets приложения на всех платформах, особенно с нормальной поддержкой dpi scaling. У QtQuick (QML) такой проблемы нет.
Информация о том, что в скайпе использовался Qt была взята из википедии (Вот ссылка на вики Qt, а вот Skype). И там и там указано, что разработано с использованием Qt.
При работе с Qt я тоже не замечал проблем с компиляцией, но достаточно часто на форумах встречал людей с подобными проблемами.
С весом согласен, при грамотном коде и хорошей оптимизации, конечно можно получить приложение с небольшим весом, но к сожалению не все разработчики об этом думают.
Да, виноват, Линукс и Симбиан версии были на Qt, но это было очень давно и без QML и, главное, не кроссплатформенно.
Если кто-то на каком-то форуме не может скомпилировать, то это не значит, что есть проблемы с компиляцией. Так можно сказать абсолютно про любую библиотеку. Я, к примеру, не смог с ходу скомпилировать буст под виндовс с помощью clang.
Если разработчик даже минимально не думает о весе дистрибутива, то может это ему и не надо? Или он просто не умеет. В любом случае — это не проблема Qt, ибо в Qt достаточно инструментов чтобы получить бинарник вменяемого размера.
В общем, то что вы написали в качестве недостатков именно Qt — таковыми не являются.
Впрочем, подрезав необходимые DLL, можно уложиться в 30Мб, или как ниже написали — использовать общий рантайм на систему.
Статически линковаться можно и с GPL, в том числе для коммерческого использования. Но это не всегда приемлемо.
Указан у Qt "Большой вес приложения":
Например статическая сборка в windows приложения может занимать <10 Mb exe, это правда много для gui приложения, которое не требует больше никаких зависимостей и установки, чтобы его запустить на любом компьютере?
Последний релиз JavaFX вышел 2 года назад.
Увы, ощущение, что его хотят похоронить (
Насколько я знаю, у JetBrains все продукты на JavaFX. И очень даже зачетные интерфейсы.
Но тем не менее, JavaFX проигрывает многим другим фреймворкам. Это видно и по числу разрабов и по активности в SO. А жаль. Java божественна.
А как же Neutralinojs?
Compose for Desktop — было объявлено на днях, в стадии альфы.
Qt, к сожалению, очень дорогой. Но возможности у него фантастические.
U++ забыли
Ничего себе, у Qt проблемы с компиляцией под Windows, а у Gtk — нет? Как по мне, поднять сборку Gtk на win гораздо больше мороки, чем пользоваться Qt Creator, который сразу с компилятором и QMake идёт. При этом Gtk застряла в значительной своей части на древних autotools, хотя вроде пытаются перейти на meson.
http://root.cern.ch
из того, что мне тогда нравилось
http://www.fox-toolkit.org/
Была ещё парочка либ. Но, уже не помню.
Мой друг, бывший коллега по ЦЕРНу, продолжил эти занятия, уже много лет работает в Qt
Фреймворки и библиотеки для кроссплатформенной разработки десктопных программ