Комментарии 476
Лично что касается меня, я хорошо помню время когда еще был студентом и решил перейти с Delphi на С++. Эта причина - паскаль.
А потом я узнал про C# и решил изучать его. Потому что это не паскаль, и уже тогда было ясно что C++ это немного не то чего я жду от программирования.
Меня еще, тогда сильно "настораживал", "дай бог память-BDE", который надо было с приложением таскать, в те "лаконичные" годы, почему-то это казалось некрасиво .
BDE, к тому же, был ещё тем изделием. Например, для работы BDE нужно было его DLL загружать по фиксированному адресу во всех процессах, где он использовался. В Win9x это обеспечивалось автоматически (такая у нне была архитектура), но при переходе на ядро NT (Win2K и страше)это нередко создавало, мягко говоря, неудобство: например, если программа имело много подключенных DLL, которые перекрывали нужный адрес (впочем, адрес задавался в конфигурации, так чо бороться с этим было можно).
Но, начиная с Delphi 5, появиласт возможнсть использовать ADO, которая и в практически любой Windows уже была, и такого ограничения на адре загрузки DLL не имела.
По факту — Delphi-приложения вполне можно было собирать без всякого таскания BDE, особенно с переходом на dbExpress, ADO или сторонние компоненты. А вот .NET — ты уже так просто не унес. Нужен рантайм, нужная версия, и всё это должно быть в системе. То есть "таскать с собой" всё равно приходилось, просто это выглядело аккуратнее и называлось иначе.
А я не стал коммерческим программистом, но начинал программистом-энтузиастом на Турбо Паскале. Я очень люблю Паскаль, на нём можно было делать хорошие, красивые программы - при этом с самыми различными подходами. Мне не нравился оригинальный подход Паскаля в некоторых местах. К примеру, я изобрёл для себя хранение указателей на функции с возможностью их переопределения "на ходу" - для программирования текстового, а затем графического интерфейсов под DOS. Это было быстро, компактно и красиво. И именно из-за этого я невзлюбил ООП, видевшийся мне как способ скрыть "под капотом" кучу мусора (чем ООП в итоге и стал, лол). Я пробовал изучать С, но этот язык произвёл на меня впечатление тем, что можно было сделать из кода болото, в котором можно было увязнуть через неделю проектирования. В дальнейшем - уже после выхода винды-98 - я пытался использовать Дельфи, изучать ООП, и примерно до 2007 года считал себя программистом. С 2007 года начался мой коммерческий путь в ИТ, но это был путь "нам надо дописать вот тут функционал под вот это, и заведи новых пользователей в АД, продумай сервер для чатов внутри фирмы, а у Юли картридж закончился, а у Андрея офис с ошибкой вылетает" - и в 2010 я полностью переключился на системное администрирование уже в другой фирме. Не знаю, есть ли вина Паскаля как стартового языка в данном вопросе, но мой выбор точно есть.
Тоже не стал практикующим программистом, ушел в сети….
Мой первый коммерческий проект был тоже на Delphi 7, но я бы не сказал, что бы было легко, весь этот визуал на FastReport это чертов ад, чуть одно подвинешь - все заново переделывать. В бездну такие решения. После этого ада PHP+JS были реально глотком воздуха
В такой же ситуации я перешёл с Borland Delphi на Borland C++ Builder. То же редактор форм и VCL, только вместо паскаля - плюсы
И вместо миллисекунд компиляции — часы.
За сколько миллисекунд соберётся андроид из исходников, если исходники на Delphi?
филоцераптор размышляет.жпг
Компиляция - секунды 2-3, если проект не большой, а сборка больше, секунд 10, т.к. это уже на совести java инструментов.
А дальше он закончил с C# и вел разработку другого известного проекта Microsoft - TypeScript.
и переписал его компилятор на go, а не на родной c#
Да, именно так. После работы над C# Андерс Хейлсберг продолжил свою карьеру в Microsoft, и одним из его ключевых проектов стал TypeScript. Это язык, который стал революционным шагом в сторону более строгой типизации для JavaScript, и теперь он активно используется во всём мире для разработки крупных и сложных приложений. В некотором смысле, TypeScript стал продолжением того пути, который начал C#, но уже в веб-разработке.
Когда "программист со стажем" пишет про Delphi почему-то всегда вспоминается этот мем.
Теперь на месте Delphi Rust.
Не уловил аналогии. Раскроете мысль?
Почти в каждой теме где обсуждается какой-либо ЯП - находится любитель Раста который рассказывает как в нем хорошо все архитектурно реализовано (:
Так хорошо же. Хотя ладно, макросы, которые убивают в IDE понимание что происходит и вездесущий &self в методах. И отвратный синтаксис для логов и дебага. И немного странный async-await. Но в остальном - действительно хорошо сделано.
А я такой, напишите любой пример на любом языке и я скажу почему на Rust это безопаснее и быстрее )
Один rust не (....)
-- Импортируем стандартный модуль Vect (векторы с зависимой длиной)
import Data.Vect
-- Функция, которая безопасно суммирует два вектора поэлементно
vectAdd : Num a => Vect n a -> Vect n a -> Vect n a
vectAdd Nil Nil = Nil -- векторы кончились, результат пустой вектор
vectAdd (x :: xs) (y :: ys) = (x + y) :: (vectAdd xs ys)
-- Пример использования
vec1 : Vect 3 Int
vec1 = [1, 2, 3]
vec2 : Vect 3 Int
vec2 = [4, 5, 6]
-- Результат будет гарантированно иметь те же 3 элемента
vecSum : Vect 3 Int
vecSum = vectAdd vec1 vec2
Проверки compile time не получится сделать в rust
Это Idris
Аналог вектора, длину которого мы знаем в compile-time, это std:array.
"Безопасное" сложение, гарантирующее сложение лишь векторов одинакового размера, легко написать что в rust, что в c++ с использованием этого типа.
С каких это пор std::array гарантирует, что в нем содержится ровно три элемента? Если речь идет про рантайм-безопасное сложение, с проверками ифами, — то это и близко не похоже на пример выше.
По сути это обычный array.
int x[3]; равнозначно std::array<int,3> x;
Компилятор выделяет место под 3 элемента для этого типа.
А когда я начну писать и читать по смещению 5, всё отыквится. Удобно.
Складываем вектор длины 3 и длины 2. Ошибка будет только в рантайме. При компиляции мы этого не увидим. Ну или писать отдельно vect2, vect3,... vect999
Вот пример
#include <array>
template<size_t N>
std::array<int, N> add(const std::array<int, N>& s1, const std::array<int, N>& s2)
{
std::array<int, N> result;
for (size_t i = 0; i < N; i++)
result[i] = s1[i] + s2[i];
return result;
}
int main()
{
std::array<int, 3> a1 = { 1, 2, 3 };
std::array<int, 3> a2 = { 4, 5, 6 };
auto sum = add(a1, a2);
return 0;
}
All You Need Is Rust!
Вся мысль)
А для windows одним из лучших вариантов для нативных гуи приложений. Lazarus для гуи и Rust для внутренней логики. Гуи на Rust пока нет хорошего.
А чем Tauri не устраивает или вам надо прям только кнопочки рисовать и туда обработчики засовывать?
юзаю крейт egui для гуи, но это конечно боль... Не подскажите в двух словах как подружить Лазарус с Раст? Ну или может есть хороший мануал?
А вот в дельфи есть прекрасная рисовалка графиков от тичарт, а в нете фиг =)
И работает результирующий софт, как выяснилось, местами побыстрее (
Недодушил, оно ещё дёргается.
Не просто дергается, а с легкостью может составить конкуренцию в кроссплатформенной разработке (особенно с GUI)
Qt прекрасен для кроссплатформенной разработки с GUI.
И таскать с собой кучу либ на много мегабайт
Отнюдь, для хорошего GUI на Qt придется приложить гораздо больше сил, чем в Delphi (RAD Studio). При этом всё так же на выходе один исполнительный файл без лишних зависимостей.
Отнюдь, для хорошего GUI на Qt придется приложить гораздо больше сил, чем в Delphi (RAD Studio)
И конечно же бенчмарки Вы сможете сходу приложить?
При этом всё так же на выходе один исполнительный файл без лишних зависимостей.
Вы можете убрать лишние зависимости и в Qt не поверите, и даже можно слинковать статически в один файл. Вот только теперь внимание вопрос, а что это дает? Клиенту абсолютно фиолетово один у Вас файл или нет. А linux-ах дак вообще это даже хорошо потому что клиент легко может затащить qt-овые зависимости сам и шарить их между приложениями и не только.
Бенчмарки чего? Создания UI между двумя программистами на скорость?
Если Вам и сравнивать нечем то зачем Вы утверждаете о то что к чему-то надо прилагать больше сил чем другому?
Для этого не нужны бенчмарки. Достаточно посмотреть, сколько времени и сил уходит у человека для создания корректного UI.
Или просто знать, насколько сложно или просто делается та или иная вещь в дизайнере. Я использовал оба. И общался с теми, кто постоянно работает на Qt. Так что смело могу сказать то, что сказал выше.
Для этого не нужны бенчмарки. Достаточно посмотреть, сколько времени и сил уходит у человека для создания корректного UI.
"Джентльменам принято верить на слово" (с)
Или просто знать, насколько сложно или просто делается та или иная вещь в дизайнере.
Пример будет?
Я несколько лет разрабатывал на C++ Builder (тот же Дельфи, вид в профиль) и Qt. Небо и земля. В пользу Qt. На Qt адаптивный интерфейс в разы проще сделать.
После C++ BUILDER (догадываюсь, Дельфи такой же) Qt был глотком свежего воздуха. Кривой пиксель-зависимый UI, страшный, не логичный API без хорошей документации. Это про билдер. Хуже только MFC был.
Да и не нужно сравнивать кроссплатформенный подход Qt и нативный VCL (что в билдер, что в Делфи), сравнивать нужно с тоже кроссплатформенным фреймворком в Делфи - FMX. И именно его я имею ввиду, когда говорю о том, где проще создавать интерфейс. В FMX тоже не пиксельный подход, а свои "пиксели", устройства же разные бывают. И подходы к отправке тебя разные: и векторный и растровый вариант доступны. И рендер на выбор (dx, d2d, opengl, opengles, skia, metal, vulkan) и разные варианты слоев и автовыравнивание и т.д. Всё там есть. И есть CSS-like подход, только в виде дизайнера. Можете посмотреть статью мною написанную.
Для меня после VCL именно Qt был глотком из бочки дёгтя. Все что раньше делалось интуитивно и работало на абсолютном большинстве конфигураций, нужно было запинывать и дорабатывать напильником. Переход на electron по сравнению с Qt не выглядел чем-то неестественным.
Уже нет. Слишком тяжёлый, нет поддержки даже ранних вин10, дурацкие ограничения лицензии. Альтернативой мне видится таури. Как только появится свободное время, буду вкатываться туда)
Del
Недавно, спустя 15 лет, решил посмотреть, на что сейчас способна кроссплатформенная Делфи, и не смог: нет версии для МакОс
Также как и нет версии Visual Studio для MacOS. Кроссплатформенность в том, что можно скомпилированный бинарник запустить на разных платформах, а не в том, что саму IDE можно где-то кроме как на Windows запустить.
Визуал Студия под макос вообще-то есть. Только сняли её с поддержки.
Вот сразу видно, что вы только что загуглили и совсем не в курсе вопроса.
Visual Studio for Mac не имеет ни малейшего отношения к Visual Studio, так же как и Visual Studio Code. Это просто MS в нейминге изгаляется, и по факту это был переименованный MonoDevelop
Это понятно. Точнее, скомпилировать разные бинарники под разные платформы.
Непонятно только, что мешает сделать это с самой РАД студией. Ведь она компилирует сама себя.
Нет, сама RAD Studio написана на .NET и WinForms. Только ранние версии, вплоть до Delphi 7 были написаны на самой Delphi.
Для продукта, заявленного как среда разработки общего назначения это...нехороший звоночек что ее нельзя использовать именно так как заявлено.
RAD Studio всегда была написана на Delphi и VCL, а не на Winforms. .net там есть лишь для некоторых инструментов типа рефакторинга.
Вранье, извините за грубость. Дельфи написан на Дельфи. Точнее рад-студия итд. Компилятор несколько "модернизировали" в нескольких последних версиях, там теперь торчат следы llvm, что впрочем только к лучшему.
Думаю, вы чересчур много требуете от кроссплатформенности.
До сих пор считалось хорошим результатом возможность скомпилировать и запустить один и тот же программный текст под разными платформами. В реальности это не всегда удавалось.
Среда разборки не кроссплатформенная.
нет версии для МакОс
Была. Использовал под Air 2017. Чисто мне субъективно VS не очень нравится как IDE, и я предпочел под мак использовать VSCode. В принципе, его же майки и рекомендуют использовать. И в Visual Studio бесило, что версии под винду и мак сильно отличались визуально.
Ну и есть Rider, который сейчас бесплатный для некоммерческого использования.
А вообще, кроссплатформа не средой разработки определяется, а возможностью запустить под разные ОС. И тут палка о двух концах. Если мы за Web приложения говорим, то они успешно пакуются в докер и +- одинаково работают в контейнере под любой ОС. А вот с десктопными приложениями не так все просто.
Не было. Это MonoDevelop была, и от Visual Studio там только название было (они её переименовали, когда официально признали Mono и поглотили Xamarin). Ну и соответственно ни одной общей строки кода с версией под Windows. Две совершенно разные IDE.
А вообще, кроссплатформа не средой разработки определяется, а возможностью запустить под разные ОС.
Ну да, я так и написал)
ни одной общей строки кода с версией под Windows
Изначально ни одной, а потом они постепенно заменяли код редактора и других компонентов как раз с целью унификации с виндовой Visual Studio (ну и ещё интерфейс постепенно с Gtk на Cocoa переписывали), и, соответственно, этот код жил не в открытом репозитории MonoDevelop, а в закрытых проприетарных расширениях, поставляемых в составе Visual Studio for Mac.
А зачем? Мак дорого стрёмно неудобно, мне конечно мак нравится, поиграться и забыть как страшный сон, особенно когда у моих клиентов начинаются глюки с программным обеспечением на маке, с купленным программным обеспечением, на дорогом мак про, чур меня...
Если действительно интересно, то вот зачем.
Для меня нет принципиальной разницы, на чем писать код, но мак выигрывает в качестве сборки и автономности. Это легкий, крепкий и мощный ноут, который я могу бросить в рюкзак, не боясь за его целостность и что через пару часов сядет аккум.
По поводу цены - не встречал аналогов от других производителей за аналогичную сумму. Разве что Surface, но в наших краях его не так просто достать, и за гораздо бОльшие деньги. У меня есть виндовый ноут для игр(Asus Strix Scar). Он стоит вдвое дороже моего мака и требует гораздо более нежного обращения, у него хуже клавиатура и трекпад. (Ещё он совсем не держит заряд и много весит, но это уже плата за высокий ФПС в играх). Ещё существенный минус — я не могу просто закрыть крышку в любой момент и рассчитывать, что откроется система в том же состоянии. Со спящим режимом постоянные проблемы.
Дома они оба подключены к одному комплекту моник+мышь+клава, и если работать, то действительно почти нет разницы между операционками. Только меню пуск вместо Спотлайт, и консоль WSL вместо терминала
Я так полагаю, что он "с легкостью может", но просто не хочет :) Позиции у дельфей так себе.
То есть неуспех всей технологии объясняется тем, что один человек решил заняться другим продуктом? И всё? Больше не нашлось никого, кто бы поднял упавшее знамя?
Хейлсберг по сути ушел ровно через год после первого релиза (первый релиз 1995 год, Хейлсберг ушел в 96), а пик популярности был примерно после нулевых, т.е. не то, чтобы это сильно ударило по языку. Основная проблема это сам МС, с которым сложно было конкурировать. МС принципиально втюхивала C#: бесплатная среда разработки, полное копирование самых удачных решений из Delphi, тонны сахара в язык.
Не то чтобы это было плохо, но это как раздавать бесплатно мороженое рядом с другим мороженщиком, который его продает. МС как крупнейшая компания могла раздавать мороженое, Борланд - нет.
Всегда думал что .net в первую очередь конкурирует с java
Борланд тоже мог бы сделать Community Edition и сделать ценник сопоставимым с Visual Studio. Думаю, это только увеличило бы их прибыль. Просто менеджмент компании оказался слишком ригидным и пропустил момент, когда рынок поменялся.
Появилась Community Edition, без проблем пересобрал все свои приложения 20 летней давности.Это они, конечно, сильно маху дали. Помню встречу с разработчиком Indy тогда, он понимал что в СНГ была большая серая армия поклонников Delphi.
Ну теперь хоть можно писать без оглядки. Хотя уже успел Lazarus попробовать. Интересно, что в итоге сдвинуло с места и заставило разработчиков сделать Community Edition... Но я этому очень рад в любом случае, по сути легализует много моего кода (хватает Community Edition).
Я знаю, что сейчас есть Community Edition, но им надо было в 2005-м её выпускать, край в 2006-м. Потом момент уже был упущен.
Turbo Delphi 2006 не спасла
Точно, подзабыл про неё. Впрочем, емнип, она была сыровата и не позволяла сторонние компоненты использовать, что в целом было основной фишкой Delphi.
Был финт ушами, который позволял включить использование сторонних компрнентов.
Но таки да, для большинства, незнакомого с этим финтом, это было проблемой.
Впрочем, проблема проявлялась только в визуальном редакторе. Но, опять же, терялась основная фишка Дельфи при первом появлении стороннего компонента еа форме.
и даже тут - чтобы скачать VS Community Edition не надо ничего, просто идёшь и качаешь. Чтобы скачать у Эмбаркадеро - а заполни-ка нам формочку, а то нам продать рекламщикам нечего...
Скачать может ничего и не надо, а вот чтобы запустить (если не путаю) надо заводить аккаунт в майкрософте.
разве? я по работе его запускаю регулярно на установку, и ничего не спрашивает.
на установку да, ничего не спрашивает. А вот чтобы запустить спрашивает раз в год или около того.
https://learn.microsoft.com/en-us/answers/questions/1496331/do-you-have-to-sign-in-to-use-visual-studio-2022-c
Они сделали. Только рынок уже был просран.
.NET конкурировал с Java и был сделан по лекалам Java и Delphi тут совсем ни при чем. Конкурентом Delphi был Visual Basic потому что эти два продукта были очень сильно похожи по функционалу (и существовали в одно время) и возможностям и нацелены на один и тот же сегмент рынка. Выводы в статье крайне спорные. Delphi как продукт как существовал в своей нише так и существует, уменьшение популярности связано с тем что в начале нулевых произошел сильный сдвиг на Web платформу всего что только можно и Delphi как инструмент нацеленный на desktop разработку стал мало кому нужен, потому что и desktop разработка стала мало кому нужна. Попытка в мобилки была обречена на провал потому что там властвуют не сдвигаемые технологии, на андроиде Java которая вряд ли куда-то денется а там и Kotlin-ы подтянулись а на iOS даже не стоит пытаться тамошняя публика умеет только в инструменты самого эпла и боготворит их. Кроссплатформа для мобил тоже обречена на провал, потому что там высочайшая конкуренция. Что с серверами и веб? Там тоже уже давно много мастодонтов которых тяжко сдвинуть. Также тут есть доля злой шутки, язык Pascal и его производные в сообществе считались (и до сих пор много кем считаются) "игрушечным" не серьезным языком, это примерно как с PHP до сих пор много людей считают что он плох просто потому что кто-то где-то его поливал гомном. Delphi программисты считались теми кто "программирует мышкой", т.е. сам по себе инструмент не воспринимался серьезно. И я это не выдумал я сам начинал как Delphi программист и первые деньги заработал именно разрабатывая на Delphi. Итого проблема не в инструменте как таковом (а он хорош) а в том что компания инструмент делавшая (все компании) не подстроились под рынок во время и упустили огромные сегменты куда могли зайти первыми и стать мейнстримом.
А МС, купивший акции Борланда тут не при чем. И совсем не участвовал в установке курса инструмента.
C# может и сделан по лекалам Java, только вот WinForms, на половину, до сих пор состоит из тех же классов с теми же именами, что и VCL в Delphi. C#, руками главного архитектора, взяли что можно из Delphi и вели его напрямую в провал имея право голоса купленными акциями.
Ну и если посмотреть на современные возможности Delphi и экосистемы, то мы имеем штатный кроссплатформенный фреймворк FMX (под все платформы), сторонний (от нашего разработчика) нативный фреймворк для Android/iOS - FGX, кучу веб-фреймворков, включая бэкенд фреймворки и фронтенд фреймворки (MARS, Horse, DMVC, UniGUI, TMS Web Core, mORMot, RAD Server и т.д.).
Всё это позволяет покрыть почти все что нужно
А МС, купивший акции Борланда тут не при чем. И совсем не участвовал в установке курса инструмента.
нет. они купили немного, когда борланд уже был в заднице (1999) и это были выброшенные деньги. Из соображений поддержать конкурента на плаву. Потому что монополизация рынка проблема отдельная и большой компании нужен хоть какой конкурент для отвода антимонопольной комиссии.
влиять на продукты и политику они разумеется не могли - это было бы конфликт интересов и незаконно, тем более не решающий пакет.
там еще была история, с переманиванием инженеров (логично раз компания дохнет и она под боком) борланд вроде судил MS а те в компенсацию купили стоки. но насколько достоверно - неясно. так то терки были постоянно меэду всеми компаниями в долине. Пока не договорились не тягать инженеров.
C# может и сделан по лекалам Java, только вот WinForms, на половину, до сих пор состоит из тех же классов с теми же именами, что и VCL в Delphi.
WinForms это древняя технология существующая до сих пор только потому что есть легаси написанное на ней. И вообще ничего удивительного в копировании хороших вещей от конкурента нет, этим все занимаются.
Ну и если посмотреть на современные возможности Delphi и экосистемы, то мы имеем штатный кроссплатформенный фреймворк FMX (под все платформы), сторонний (от нашего разработчика) нативный фреймворк для Android/iOS - FGX, кучу веб-фреймворков, включая бэкенд фреймворки и фронтенд фреймворки (MARS, Horse, DMVC, UniGUI, TMS Web Core, mORMot, RAD Server и т.д.).
Всё это позволяет покрыть почти все что нужно
Еще раз я не говорю инструмент что-то не умеет и он плох в том что он делает. Проблема лежит не в технической плоскости, а в том что у него маленькое сообщество (по сравнению с мейнстримными языками) а также маленькая известность. Одно это дает очень много недостатков инструменту (банально попробуйте настроить github actions для проекта delphi) уменьшает фонд новичков (потому что на курсах учат модно-молодежные технологии). Все эти процессы не происходят одномоментно, все это растягивается на годы, но факт в том что Delphi как инструмент сейчас не особо популярен и то что он может или нет этого не изменит.
Как по мне в свое время надо было отдавать в Open Source компилятор языка и IDE это дало бы сильнейший буст популярности а также дало "лишние руки" на поддержку все этого добра, но это надо было делать до того как появился Free Pascal и Lazarus, сейчас уже поезд ушел.
А МС, купивший акции Борланда тут не при чем. И совсем не участвовал в установке курса инструмента.
C#, руками главного архитектора, взяли что можно из Delphi и вели его напрямую в провал имея право голоса купленными акциями.
А Borland только простите Delphi имел в портфолио? Вообще то у него в портфолио была целая россыпь языков. И эта история о которой Вы говорите очень туманна и голословно утверждать что вот прям чтобы Delphi убить это было сделано.
С java он конкурировал в вебе. На десктопе жабой и не пахло. Были mfc, delphi и qt. Winforms вышли как замена устаревшей mfc и как конкурент delphi и qt на десктопе. Но десктоп умер. Потом и delphi и winforms и wpf сейчас нахер никому не нужны.
Не уверен, что именно платформа .NET сыграла решающую роль в спаде популярности Delphi. Всё-таки Delphi того времени — это компиляция в исполняемый код, а .NET — это платформа с управляемым кодом. Платформа .NET конкурировала скорее с Java, и до появления среды Mono, реализованной для различных операционных систем, было неизвестно, насколько она будет успешной. А прямым конкурентом Delphi был, скорее, Visual Basic.
Так и есть. Более того, я читал что это в странах СНГ Delphi был настолько широко распространен, а там, на западе, в основном использовали Visual Basic для аналогичных вещей.
Конечному пользователю абсолютно безразлично, исполняемый там код или управляемый. Как, по большому счету - и программисту, если разговор идет не о лютом хайлоаде.
Во времена Delphi и Visual Basic это было не совсем так — производительность компьютеров была ещё не настолько высокой, чтобы замедление выполнения байт-кода по сравнению с машинным кодом можно было игнорировать.
согласен. Помню как в начале 2000х работали программы на .NET. Это было очень медленно и уныло. Да, это было сильно лучше и быстрее чем гуи-аналоги на жава, но с делфей нечего было сравнивать.
Согласен, что причина была в том, что за .нет стояли деньги и влияние микрософт, который тогда был монополистом.
А делать учетное ПО, завязанное на СУБД на делфе было быстро и легко. Уже в конце 90х под вторую и третью делфю была куча доп.компонентов от генераторов отчетов до навороченных ДБ-гридов. До сих пор помню eh-grid, многострочный грид, которые умел почти все. А на QT поставляется примитиынй грид, как на семой первой делфе, а все остльное надопилить вручную.
Но основной причиной ухода делфи, стало то, что мир с середины 2000х пошел в полностью сторону веба, а не десктоп-приложений. Делфи в ту нишу так и не вошло полноценно.
Делать учётное ПО ещё легче и быстрее чем в Delphi было в Visual FoxPro. Пока в Net не появился linq. Я тогда и перешёл с FoxPro и Delphi (на котором делал АктивХ компоненты для того, чего не хватало в фоксе) полностью на C# и это было супер. Шарп мне полностью заменил ту связку, увеличил продуктивность и дал кучу новых возможностей. А потом в Net появился xaml и gui вышел на новый уровень...
Фокспро рулил в этой нише до делфи. Особенно фокспро для ДОС был прорывом в свое время. А потом микрософт сама убила этот продукт, хотя он был крайне восстребован. Конечно, BDE для локальных БД был не так хорош, как движок фокса для дбф-файлов, но по совокупности факторов для клиент-серверных приложений делфи был лучше. А ведь еще в параллеьной реальности жил-был Sybase Powerbuilder.
появился xaml и gui вышел на новый уровень
По сути, мы получили браузерную страничку со своим странным DOM и CSS.
Если в VCL Grid можно вгрузить хоть 50.000 строк и всё будет прокручиваться со скорости движения курсора мыши, то в WPF начинаются неприятные микро-фризы.
С другой стороны, в VCL простые бизнес-задачи решаются простыми средствами. Если надо строки с отрицательными остатками подкрасить красным, просто в коде пишешь if ... then Font.Color := clRed; В WPF же надо всё обмазать темплейтами, биндингами, дататриггерами и конверторами. А потом, когда рендер начинает применять эти портянки стилей на 50.000 строк, это просто выжирает процессорное время.
У меня нет опыта с FMX, но боюсь, что если они пошли по пути WPF, то взяли с собой и все эти недостатки.
Нет, не по пути WPF. Млн строк в гриде будут отображаться как и 100 строк
А потом, когда рендер начинает применять эти портянки стилей на 50.000 строк, это просто выжирает процессорное время.
Ну если у программиста руки не из того места, то причем тут фреймворк то? С виртуализацией ничего нигде не тормозит
Получается, что фреймоврк требует большой внимательности и аккуратности от программиста. Обычно как на проектах: таск, разраб поставил грид тяп-ляп, задача закрыта. Тюнить никто не будет. Отсюда и предрассудки, что WPF интерфейсы - медленные.
Так же меня бесил в WPF мыльный субпиксельный рендеринг до появления 4к экранов. Потому что никто не заморачивался с разметкой SnapToDevicePixels и т.п. И типа чел, что тебе глазам больно от мыла, это чисто твоя проблема, всем остальным нормально.
Я делал на Delphi программы разных инженерных расчетов и скорость вычислений была ой как важна. Вставки на ассемблере хорошо помогали с узкими местами, тем более что модель памяти плоская и пишется легко.
И Borland C++ Builder)
Delphi был человечным, понятным, продуктивным. Его можно было выучить в колледже и сразу писать серьёзные программы.
Автор: программист с стажем, переживший взлёт и падение Delphi, и наблюдающий, как старый чемодан .NET до сих пор стучит колёсиками в коридорах корпораций.
я программист, который учил pascal/delphi в колледже/универе с 2005 года, года с 2007 по возможности начал писать C# (.Net), потом ушел вообще в другую сферу по программированию, но для windows все еще предпочитаю C#.
.NET Framework (1.0–4.8) продолжает жить в тысячах старых приложений.
Почему вы пытаетесь выставить достоинство платформы как недостаток? Одна из целей .Net - заменить зоопарк существующих библиотек (или хотя бы больше не плодить новые семейства несовместимых библиотек) одной расширяемой - пусть даже путем хранения старых версий. Вам не встречались приложения и игры НЕ-.net, для нормальной работы которых нужно патчить систему?
Его нельзя просто выбросить: слишком большая зависимость.
любую активно используемую технологию нельзя просто выбросить. Например, большинство банкоматов до сих пор работают на windows XP. Скорее то, что про Delphi все быстро забыли, говорит о том, что он был всем так "нужен".
Даже в .NET 8 всё ещё чувствуется наследие WinForms и старого API.
как вы поняли, что там наследие WinForms, а не например, WPF, про который вы не упомянули?
И почему у вас поддержка старого API для совместимости снова оказалась недостатком? Вы хотите, чтобы он был полностью удален из исходного кода, а потом людям пришлось писать его эмулятор?
Одна из целей .Net - заменить зоопарк существующих библиотек
Собственным зоопарком библиотек? И в чем тогда его преимущество? Сейчас существует десяток несовместимых наборов ДотНет библиотек и для конкретного приложения, особенно для старых проектов, необходимо отдельно ставить нужную версию ДотНета. Проекты на Delphi, созданные ещё в 2000х запустятся на Win11 без каких-либо манипуляций.
Вы про разработку или запуск? Если про запуск, то всё, что написано под framework 4+ запускается на рантайма 4.8(всмысле ОС использует один рантайм). Добавить к этому framework 3.5 и можно сказать, что все приложения запускаются.
Более того, старому приложению можно было добавить <supportedRuntime version="v4.0" /> и с большой вероятностью оно бы запустилось на новом рантайме.
У нас старый проект, разработку которого начали до нас (и прошло несколько поколений вендорной разработки) в 2005-м, до сих пор успешно работает, активно развивается, абсолютное большинство библиотек из NuGet подходят. Да 100% совместимости прям всех-всех библиотек нет, но уровень обратной совместимости колоссальный.
В основном они все совместимы. .NET это стандарт, там сложно сделать что-то несовместимое. В крайнем случае, переписывается легко.
Спасибо за комментарий, очень ценю вашу точку зрения.
Согласен, что .NET — это мощная и универсальная платформа, которая справляется с задачей обеспечения совместимости, решая проблему множества несовместимых библиотек и технологий. Это действительно один из важнейших её плюсов, особенно для старых приложений. Ваша аналогия с банкоматами, работающими на Windows XP, вполне уместна.
Однако, в моей статье я пытался отразить не столько техническую сторону, сколько личное восприятие того, как переход от Delphi к .NET и внедрение этих технологий повлияло на разработчиков, на культуру программирования и на ощущения самого процесса. Delphi был для нас чем-то более «человечным» и прямым в сравнении с более сложной и, как мне кажется, иногда обезличенной платформой .NET.
Что касается старого API и WinForms — да, вы правы, поддержка этого всего на самом деле необходима для совместимости. Я не утверждал, что это плохая идея, а скорее отмечал, что для многих разработчиков этот «старый чемодан» может быть тяжким грузом. Но опять же, это мнение, основанное на личном опыте работы с различными технологиями.
А про WPF — это, конечно, отдельная тема, но как я вижу, WinForms продолжает жить в части приложений, и его след всё ещё заметен в современной разработке. Возможно, в будущем я более детально разберу эту тему.
Забыли про CBuilder. Он использовал ту же платформу компонентов но с С++. Собственно, большинство продуктов промышленной автоматизации которые были начаты на Дельфи очень быстро перешли на CBuilder.
С Builder - это было для меня то что надо. Мы с товарищем даже книжку написали.
RAD технология не очень хорошо ложилась на C++, порождая более громоздкий и менее читаемый код. Borland C++ - это хорошая попытка, но не взлетело, как и другие подобные продукты (например, Visual Age C++). Выжили только среды с упрощенным визуальным проектированием, касающимся только наполнения окошек визуальными элементами и минимальной автоматизации связи этих элементов с кодом (как в QT).
Паскаль (точнее его объектный потомок) лучше подходил для RAD технологии.
И, кстати, нелюбовь к Паскалю, как мне кажется, чрезмерна и иррациональна. Как мне кажется, она обусловлена скорее не реальными недостатками языка (язык можно было развивать, а противостояние begin/end и фигурных скобочек не стоит того внимания, которое ему уделяется), а модным представлением о том, какой язык должен учить труЪ программист.
Да, это правда, с VCL c++ так красиво не совещался как Паскаль. Но в паскале не было темплейтов и соответственно нормальных коллекций как в STL, это как минимум. Я писал и на Дельфи и на CBuilder и помню насколько легче было реализовывать сложную прикладную логику на c++. Тоже не фонтан в сравнении с С#, но определенно легче.
И все продукты, которые тогда писали мои коллеги пометавшись между Дельфи и микрософтовским MFC остановились на сбилдере.
Но begin end это неудачное решение. Хотя в этом есть своя эстетика, на хороший паскалевский код приятно смотреть, а хороший сишный код мало отличается от плохого.
Именно begin end когда их приходилось писать много и часто, сильно подбешивали.
Delphi vs C++. Замечено однако, вот уже четверть века повторяется одна и та же знакомая картина: собираются паскалефобы и начинают пинать "мёртвого льва" с криками Delphi is dead. Особенно стараются те, кто этого льва в глаза не видел или может пробовал приручить, но не смог по разным обстоятельтвам и вообще его морда ему в зеркале не понравилась. А лев то оказывается и не мёртв, а просто спит регулярно, набирается сил. Не ровен час откусит голову кому-то, виртуально конечно. Это лирика, а проза такова, что Delphi (Object Pascal) самый лучший алгоритмический язык ООП по совокупности таких критериев как: - соответствие описания алгоритмов математическим операциям, обозначениям, процедурам и функциям. В классах в методах явно указано function и procedure (а не пустой void), про конструктор ясно написано, что это constructor (a destructor не "~" как в C++), "=" есть "=", отрицание not не "!" и т.д. и т.п. То-есть, Delphi отлично читабельный, а вы сеньоры попросите ИИ почитать вам вслух код вашего проекта на С/С++, без расшифровки значков естественно. Будет очень интересно, но страшно непонятно; - нечувствительность к регистру в Delphi избавляет от неизбежных случайных ошибок набора текста программ, позволяет писать привычные названия, переменные и идентификаторы, не подстриженные под одну гребёнку как обычно принято в СИ-подобных языках ради сокращения частоты нажатия клавиш и уменьшения ошибок для повышения скорости набора. Однако трудно разобраться без комментариев в таком коде даже самому автору на следующее утро, не выпив... чащечку кофе; - скорость компиляции бинарников библиотек и сборки готовых программ в Delphi всегда была высокой и в настоящий момент гораздо выше, чем в C++. Это можно легко проверить на тестовом проекте размером в 1Mb cо стандартным набором одинаковых управляющих элементов GUI (интерфейса, меню, контролов из набора офисных программ Microsoft); В итоге осмелюсь преположить, что Delphi (или его реинкарнация в виде Lazarus'а) никуда не денется и через 100500 лет. Потому как Object Pascal - язык строгого и безопасного алгоритмического программирования, а не язык шифрования кодирования, как C/С++ и другие ЯВУ, включая интерпретатор Python. Конечно, изучение современной среды IDE Delphi сложное дело, но оно того стоит, в ней решить можно практически всё с большой скоростью и оптимальной эффективностью.
Он ещё и про Delphi.NET и про С# Builder забыл, если уж рассказывать историю, то целиком)
Pascal я сразу не взлюбил. Когда появился Borland. Builder, то все компоненты "подсматривал" в Delphi
.NET Framework (1.0–4.8) продолжает жить в тысячах старых приложений.
Его нельзя просто выбросить: слишком большая зависимость.
А можно ли просто установить .NET 2.0 в W10?
он вроде идет там предустановленный
Среда выполнения (CLR) для .NET 2.0 входит в состав .NET 3.5. .NET 3.5 устанавливается штатно.
Delphi 6 до сих пор использую, когда нужно быстро набросать утилиту под винду. Если погуглить, все нужное под нее есть (даже хром собрать можно). Жалко конечно, что вымерла.
Лицензионную?
Community Edition теперь есть. Ее не хватает?
Community Edition теперь есть
Это хорошо, но сейчас не 2005й, а 2025й год. Поезд ушел.
У меня, например, зарплата выше ограничения для комьюнити 5к$ в год. Мне невозможно её легально использовать.
Да и обрезано там очень много.
Доход должен быть от использования среды разработки. Если ты используешь среду разработки вне работы - твой доход здесь не учитывается.
И нет, в Community версии ничего не урезано, кроме возможности сборки под Линукс
В лицензионном соглашении написано по русски, независимо, используется Д или нет для дохода, есть деньги - плати.
Обрезан ещё коннект к любым клиент северным субд, даже если они локально развёрнуты (технически то способа проверки локальности нет)
.
есть деньги - плати
А как это организовано? через справку от налоговой? О_о
Реализовано было довольно подло. В ехе файле компилятор прописывает твой идентификатор, а потом эмба присылала сначала письмо счастья на организацию, а потом проверку. Как эмба узнавала и вычисляла адресата (фирму) , уже не помню.
Если же ты энтуазист одиночка, ну не знаю, как определить, популярна ли твоя программа в продаже.
эмба присылала сначала письмо счастья на организацию, а потом проверку.
Это воще законно? О_о
Ну, не знаю. С таким подходом с Delphi можно связаться только по очень большой необходимости. При наличии очень дорогого очень легаси проекта, который нужно очень активно пилить.
Законно. Из лицензионного соглашения (раздел про Community Edition, русский вариант):
Embarcadero будет собирать информацию об использовании Вами Community Edition для целей аудита и улучшения наших продуктов и услуг. Для получения дополнительной информации о сборе, использовании и раскрытии персональных данных ознакомьтесь с Положением о конфиденциальности Embarcadero по адресу [...]
Я про требование предоставить финансовый отчёт.
Это ты сам проверяющим органам будешь предоставлять.
Кстати была тема - у вас куплены лицензии профессионал, а ехе собрано архитектом (тоже инфа записана в бинарник) , доплатите.
Бухгалтерская отчетность компаний в нормальных странах публична, выданный ключ содержит идентификатор, который потом перекочевывает в *.exe. Алгоритм: нашли exe-файл, посмотрели, кем сделан, посмотрели в отчетность — а там доход больше $5K. Можно даже не посылать проверяющих, а сразу в суд.
Индивидуалов, понятное дело, просто так не прижмешь, да они, скорее всего, и не ловят, им корпоративщики интереснее.
Бухгалтерская отчетность компаний в нормальных странах публична
Вот так просто любой хрен с горы может посмотреть налоговую декларацию любого Васи Пупкина?
Не «Васи Пупкина», а ООО «Хрен и редька». Отчетность организаций публична или доступна за символическую оплату. Сходите на сайт налоговой — там можно получить отчетность бесплатно (нет финансовых организаций типа банков, потому что их отчетность раньше лежала на сайте ЦБ, теперь ее начали секретить). Раньше эту базу держал Госкомстата/Росстат, и у меня в голове почему-то осело, что копия годового комлекта у них стоила 40 рублей — как раз за бумагу и за пять минут работы человека.
Ничего в ехе файл никто не вкомпиливает. Собранные программы не используются для проверки лицензии, проверкой лицензии занимается среда разработки. Если она появляется внутри сети компании, то и происходит идентификация компании. И приходит письмо.
Ничего в ехе файл никто не вкомпиливает. Собранные программы не используются для проверки лицензии, проверкой лицензии занимается среда разработки. Если она появляется внутри сети компании, то и происходит идентификация компании. И приходит письмо.
И нет, в Community версии ничего не урезано, кроме возможности сборки под Линукс
Так, некроссплатформенная IDE собирает кроссплатформенный софт на фраймворке, который сами раззрабы не используют почему-то. А теперь выясняется, что и софт собирается не только лишь под все ОС. Причём в бесплатной версии запрещена сборка именно под бесплатную ОС. Странно, и почему такая прекрасная среда разработки не пользуется популярностью ))
За бугром линух считается крутым энтерпрайзом, а не уделом голодранцев. Печально но факт
Я вам уже не один раз писал, что кроссплатформенный фреймворк появился сильно позже, в 2011 году. В то время как среда разработки развивается с 1995 года.
Среда разработки не может быть не фреймворке, который появился позже самой среды. Это разве не очевидно?
Линукс не доступен в бесплатной версии, потому что это считается Энетпрайз сектором!
Я вам уже не один раз писал
Я прекрасно знаю то, что вы мне пишите, если у вас в профиле верная дата рождения, я уже работал с Делфи в те времена, когда вы только читать учились.
Среда разработки не может быть не фреймворке, который появился позже самой среды. Это разве не очевидно?
Почему это очевидно, кому очевидно? Мне не очевидно. Почему не перевести среду на новый прекрасный фреймворк, сделав её привлекательной для большого количества разработчиков и выйдя на новые рынки?
Линукс не доступен в бесплатной версии, потому что это считается Энетпрайз сектором!
Кем считается? Я своим родственникам-пенсионерам всем поставил, они очень довольны, что теперь ОС не делает им голову.
Ваши все аргументы понятны. Это типовая ситуация для разработчика уровня мидл и ниже. Клиент говорит о потребностях, а ему в ответ начинают рассказывать о каких-то технических трудностях разработчиков. Спасибо, но нет, такая система мне не нужна, мне ваши трудности не интересны, я выберу среду, которая будет удобна мне. И, судя по "популярности" платформы, я такой далеко на один. А ведь я начинал с Делфи и Билдера под виндой, о чем я уже писал.
Самое главное, для меня, как для разработчика, это то, что выбирая фреймворк, я хочу быть уверен, что есть предпосылки того, что разработчик не забросит его через пол года. Если он сам не использует свой фреймворк, мне он тем более не нужен, риски очени высоки и никакие оправдания тут не помогут.
Что за ерунду вы тут пишите? Я и мой опыт тут вообще при чем? И тем более, при чем тут ваш опыт? Разговор идёт о состоявшемся факте:
Среда разработки создана на конкретном фреймворке. Почему Эмбаркадеро не начали переписывать всю среду целиком на новый фреймворк - мне не известно. Известно то, что фреймворки эти не совместимы никаким образом.
Кроссплатформенному фреймворку уже более 15 лет и его стабильно поддерживают. Это вам не веб с его ежемесячными "новыми" фреймворками.
Ваши же претензии абсолютно глупые. Печально, что вы используете Линукс и для него нет версии среды. Я её вам и не навязываю. Зато я использую Windows и мне крайне удобно, используя лишь одну ОС, иметь возможность собирать проект сразу под все платформы.
Что за ерунду вы тут пишите? ... Ваши же претензии абсолютно глупые.
Почему вы так переживаете, разве я вам запрещаю использовать вашу маргинальную среду разработки?
Я и мой опыт тут вообще при чем? И тем более, при чем тут ваш опыт?
Это был комментарий к вашему менторскому тону и хамоватой манере ведения дискуссии.
Разговор идёт о состоявшемся факте
Факт состоит в том, что некогда популярная среда отброшена на задворки индустрии и работают с ней только энтузиасты. Я вам попытался объяснить, почему в 2025 году выбранный производителем подход не радует разработчиков. А вы, зачем-то, на меня решили обидеться, как будто часовню тоже я развалил (с)
Всего вам хорошего.
Вы спорите с фанатиком. Тут к какому то здравому смыслу призывать бесполезно, у фетиша не может быть недостатков, он идеален. Даже то что вам кажется недостатками на самом деле преимущества. В каком то схожем холиваре я уже пытался данному товарищу намекнуть что разработчикам на том же маке мягко говоря не очень удобна windows-only ide какой бы она прекрасной на этом виндовсе ни была, под тот же дотнет хотя бы райдер есть который без плясок с бубном работает. Не, вообще не аргумент - мол прекрасно все работает, а то что под платной виртуалкой в режиме софтверной эмуляции х64 на арме и с подключеним дебаггера через сеть, нуачотакого, подумаешь мелочи какие.
Я где-то сказал, что Delphi не нужна кроссплатформенная среда разработки? Нет. Я такого не говорил. Я лишь ответил, почему она СЕЙЧАС не кроссплатформенная и тем более не переписана на новый фреймворк.
Для меня лично win-only не проблема, но о кроссплатформенной версии мы давно ведём разговоры с Эмбаркадеро. Побольшей части для того, чтобы вычистили всё не нужное из среды (а её будут вынуждены писать с нуля).
Так что не нужно причислять меня к неким фанатикам вин онли.
Я тоже
Дот нет и все инструменты разработки микрософт всегда были хуже и остались такими до сих пор. Дельфи до сих пор не превзойден и не имеет равных аналогов.
Если такие мысли греют вам душу и делают счастливее, то пусть :)
Я бы сказал "история рассудит", но она уже рассудила.
Работодатели с вами абсолютно согласны.
Хабр.Карьера это вообще не показатель.
Да, вакансий в РФ по Delphi немного но они есть. Embarcadero Tech официально продаёт корпоративные лицензии сейчас, в отличие от MS.
Да, вакансий в РФ по Delphi немного но они есть.
Ну так вы только подтверждаете этими словами тот факт что я привел - Delphi не востребована на рынке. Я сейчас работаю в компании, которая переписывает весь свой корпоративный софт с delphi на .net. И это не одна такая компания, мне периодически прилетают вакансии где компании хотят уйти с delphi, буквально на днях прилетала вакансия от ингосстраха.
Delphi был хорош многообразием готовых компонентов под любую задачу как бесплатных так и платных.
Я в свое время разработал комплекте ScaleRichView и RVMedia и продавал их по миру, долго меня кормило. Но потом вышел из проекта и оставил его партнеру. Он до сих пор живёт на них, продавая со своими.
trichview.com
На них в свое время были the bat, первый Skype. Это где выводился текст. Даже служба внешней разведки Украины их покупала в 2014-2015 году (для камер видео наблюдения). Среди клиентов были и Боинг и даже администрация штата Трансильвании по-моему. Основные продажи были из Европы, затем южная Америка, реже Китай и США. СНГ не рассматриваю, так как для них была низкая цена и они почти не давали прибыль при том что стоял на втором месте по покупкам.
Но в какой то момент Delphi сильно отстал от современных трендов и технологий.
Но в какой то момент Delphi сильно отстал от современных трендов и технологий.
А в чем такие-уж преимущества этих новых трендов и технологий? Как правило софт написанный по современным трендам и технологиям почему-то ощутимо прожорливее к ресурсам , при том же функционале, что и старый софт, написаный до этих трендов (тот же Skype например).
Преимущества этих новых трендов и технологий - в новых возможностях, инструментах.
Когда например я хотел расширить возможности на нейронках, чтобы добавить их в свою линейку RVMedia - то писать с нуля или переносить логику уже готовых решений с python был не готов. А тем более работа с CUDA.
Другой момент кроссплатформерность. Я тогда много намучился с этим. Они поздно ее отладили, когда она уже есть у всех. А мне очень не хватало этого. чтобы перенести компоненты на Android, iOS, Mac, Linux для полноценного создания мультимедийных компонентов под разные ОС. Чтобы пользователь мог быстро сделать чат или аналог TeamViewer не только под Win и Lin, но и Apple технику и мобильники.
Далее куча разных вещей вроде обращений к Redis, Kafka и другим. Они появились - но с большим опозданием. Когда компании уже во всю использовали данные технологии в Delphi их еще не было, или они были глюченные. При этом упор был на то, чтобы наплодить кучу компонентов, которые просто глючили. А под капотом был дикий ужас, заглушки, циклы вывода отрисовки без оптимизаций и так далее.
А в том, что маркетинговая парадигма сдвинулась от функционала в рюшечки.
Долго описывать, но надеюсь не придется.
Лазарус ещё есть.
«Ты тут лазаря не пой!» ©
На нем написан горячо любимый Double Commander, вполне себе кросплатформенная разработка.
В Delphi можно было накидать контролов и невизуальных компонентов на форму, и приложение почти готово, а в этих ваших новомодных фреймворках (в частности веб-фреймворках) так можно?)
Определенно да, .Net буквально про это. Из натива сразу же можно вспомнить Qt и его Qt Creator. Ну и если нужен именно Pascal - добро пожаловать в Lazarus.
Qt Creator
Насколько удобно работал конструктор форм в Delphi.. И насколько неудобно в Creator 'е..
Из натива сразу же можно вспомнить Qt и его Qt Creator.
Ну, я и в Dialog Editor из Windows SDK формы диалогов для MFC как-то рисовал - потому что язык Visual C++ был в требованиях. Но Delhi лучше.
Ни Net, ни qt-creator и близко не дотягивают до возможностей визуального проектирования Delphi. Единственный продукт, который приближался к Delphi по возможностям (но не по удобству) визуального проектирования - IBM Visual age.
По идее это не зависит от дельфи, это больше про возможности IDE
В Visual Studio есть визуальные конструкторы как минимум для WinForms и WPF, но я бы не сказал, что, используя только конструктор и ничего больше, можно сделать хоть сколько-то серьёзное приложение. Прототип или приложение для личного пользования, где есть только одно окно, пачка TextBox'ов с кнопками и остального по мелочи — пожалуйста. Но если нужен адаптивный дизайн, сложное поведение компонентов, иерархии — без ручного написания разметки и скриптов поведения никак.
Вы заблуждаетесь и очень сильно. Естественно, если форма не статичная, то просто кинуть всё на форму не получится, например, если содержимое загружается из сети. Однако, никто не мешает создавать отдельные части интерфейса (визуально) и манипулировать ими кодом (создавая их в нужном месте кодом). Например, "новостной портал": приложение грузит новости и элемент "новость" должен создаться динамически. Шаблон новости мы можем создать визуально (что, где и как расположено из обязательных частей). И так со всеми другими интерфейсами и проектами.
Т.е. будет дизайн окна, дизайн новости и т.д. Всё это визуально и быстро.
Но декларативного дизайна (xaml, qml) в дельфи до сих пор нет (и не надо)
Как нет, а dfm файл разве по сути не декларативное описание формы?
Нет, вроде описаний всяких layout в dfm не делали, хотя последние версии не следил
Не совсем.
Это, скорее, похоже на сериализацию в XML.
И, кстати, наличие параллельно кода и dfm создавало некоторые накладки, которые среда Delphi частично устраняла, но не полностью.
На мой взгляд, лучше бы они вместо dfm сделали генерацию кода конструктора формы, как это было позже сделано в winforms.
Так я вообще не об этом говорил. Динамический интерфейс возможен, но того же адаптивного дизайна тут не будет, конструктор захардкодит все отступы и тому подобное.
Я про более сложные интерфейсы с многоуровневыми структурами, где, например, текст в кнопке, кнопка в StackPanel, StackPanel в Grid, а Grid является одной из вкладок TabControl, который сам находится в главном Grid. Через визуальный конструктор будет крайне затруднительно задать, кто тут кому родитель и что как себя ведёт при смене, например, вкладки в TabControl. А если мы не считаем частью визуального конструктора окно свойств, которое по сути та же разметка, только где возможные свойства уже отображены заранее (причём при росте количества назначенных свойств такой подход становится неудобнее просто разметочного кода), то и вовсе невозможно.
Да и в целом в том же WPF куча задач, которые нельзя нормально сделать через конструктор, тот же биндинг данных с кастомными конвертерами и форматированием вывода. Или банальнейшая вещь — ComboBox с поиском, который при отсутствии найденного выводит соответствующее сообщение, через конструктор такое невозможно, надо лезть в Template ComboBox и вручную править/создавать триггеры через код разметки. Даже просто цвета элементов тоже далеко не все можно редактировать через конструктор без залезания в код и переопределения шаблонов стилей. И куча всего ещё.
Видимо вы никогда не пробовали и не пользовались дизайнером в Delphi. WPF и winforms рядом не стоял с возможностями дизайнера окна в Делфи, особенно, для кроссплатформенной разработки. Вы говорите о проблемах, которых не возникает в Delphi при создании UI
А причём тут это вообще?? Я нигде ничего не говорил про делфи. Человек, начавший ветку, спросил, есть ли визуальные конструкторы в других фреймворках, я рассказал про .NET и про ограничения его конструктора. И всё. Я нигде не упоминал делфи, не проводил с ним сравнений, не спрашивал, как там что-либо устроено, ни-че-го. Можно уже перестать оспаривать то, чего я не говорил?
Delphi тут как пример того, где с использованием дизайнера можно делать сложные интерфейсы. А вы, всё же, больше говорили о том, что через дизайнеры в целом не делают сложные, адаптивные интерфейсы.
И вот опять приписывание. Серьёзно, хватит уже. Я говорил про конструктор Visual Studio для .NET приложений и ничего более, нигде нет ни намёка, что я говорил про все конструкторы в мире разом. Я сказал о том, что он существует, и тут же в этом же предложении, через запятую начал выражать свои мысли по поводу того, на что он годен.
Конечно не делают, или у вас просто разные понятия о сложности интерфейсов.
Разумеется текстовой разметкой со стилями, где можно не только задать компоновку элементов интерфейса, но и переопределить вид, layout и поведение любой самой мелкой внутренней детали любого элемента, оперировать проще и функциональные чем тыкать мышкой между формой и панелью свойств.
Визуальным дизайнером со стилями, где можно не только задать компоновку элементов интерфейса, но и переопределить вид, layout и поведение любой самой мелкой внутренней детали любого элемента, оперировать проще и функциональные, чем постоянно смотреть в документацию, смотреть гайды и постоянно искать готовые шаблоны, и постоянно перезапускать программу, чтобы понять что на что повлияет и как.
Это фривольный ответ, но он хорошо показывает то, что все познается в сравнении.
Если вы никогда не пользовались хорошим дизайнером интерфейса, то вы будете боготворить "текстовую разметку".
А когда ты через дизайнер можешь сделать абсолютно всё, что и кодом, ещё и быстрее и нагляднее, то зачем мне это делать кодом?
Это спор такой же как Word vs LaTeX. Да, поначалу WYSIWYG редактор кажется прорывом и очень удобной штукой, пока создаваемый документ простой. А вот когда он становится сложным, тыканье мышкой превращается в ад, особенно когда нужны какие-нибудь массовые изменения. С созданием интерфейсов всё то же самое.
Не надо намекать на то, что у меня "мало опыта", в построении интерфейсов у меня, не смотря на ваш возраст, скорее всего больше опыта, особенно в построении через визуальный дизайнер. У меня даже интерфейс чата (динамический контент сообщений) во всех проектах построен через визуальный дизайнер. И даже динамический интерфейс, который полностью приходит с сервера тоже построен через дизайнер. Если вы не умеете и не знаете как использовать визуальный дизайнер и на что он способен, это только ваши проблемы и соответственно, исключительно ваше мнение на этот счёт.
На GitHub можете посмотреть примеры моих открытых проектов. Они все построены через дизайнер.
У меня даже интерфейс чата (динамический контент сообщений) во всех проектах построен через визуальный дизайнер.
Даже интерфейс целого чата? Вы молодец, снимаю шляпу.
соответственно, исключительно ваше мнение на этот счёт.
У меня мнение, а у вас истина в последней инстанции, я правильно вас понял?
Если вы действительно считаете, что "чат" - это просто, то вы, видимо, никогда не делали свой чат. Максимум, использовали WebView для его вывода в виде html.
Если вам сложно понять, то создать такой чат, это как свой html рендер реализовать. Чат - это вертикальный скрол сообщений, сообщение - контент из смешанного содержимого.
Если вы и так не понимаете, то прошу, покажите сами пример "сложного" интерфейса, который нельзя или очень сложно повторить через дизайнер.
Я даже не знаю, смеяться мне или плакать. Зачем вы продолжаете бежать за мной и оправдаваться, чтобы что? При этом, используя риторику в стиле: пи4@ра$ы, помогите! Я же согласился уже, что вы молодец и глаголите исключительно истины в последней инстанции. Ситуация на рынке полностью подтверждает ваши слова и следующий междупланетный хакатон будет проходить на Делфи. Я посностью признаю вашу правоту и отказываюсь вам оппонировать.
Я пользовался дизайнером делфи на примере 7й версии, ничего подобного там не было. И создавал на делфи компоненты и их конструкция не позволяла ничего толком переопределить в компонентах, кроме базовых свойств и метода рисования.
С поведением компонентов в делфи тоже ах, это, на сколько помню, только обработчики событий. Триггеры и анимации отсутствовали. Чего-то вроде DependencyProperty не было, датабиндинга чего угодно на что угодно тоже не было.
А вы вряд-ли пользовались средам с текстовой разметкой. В доки там надо лазить вряд-ли чаще чем с мышетыканием за счёт intellisence. И перезапускать приложение надо довольно редко.
В Delphi 7 не было. Мы же говорим о современном времени. Во времена д7 нигде такого не было. А сейчас, с кроссплатформенным фреймворком все это есть. И анимации и биндинги и прочее, прочее...
Вот на примере вашего чата с рендерингом. Представьте что вам нужно рендерить на экране объекты не в координатах окна, а в других, скажем географические объекты. В декартовой системе с другим направлением осей в метрах или в полярной в градусах.
Позволит ваш современный дельфийский фреймворк переопределить так лэйоут или будете ручные обертки писать для каждого визуала для конвертации координат?
А какая разница в каких координатах исходные данные, если ты должен их проецировать на конкретную 2д поверхность. Ну а так, можешь просто матрицу преобразования создать и использовать её.
Разница в том кто занимается этой проекцией. Если фреймворк типа vcl знает только про пиксели это одно, если про вершины и трансформации, это другое.
Этот фреймворк (FMX) работает с матрицами. И по умолчанию может работать в 3D с проекцией интерфейса. Так что "извращать" все что рисуется можно как угодно. Применять матрицы, применять шейдеры.
Фреймворк может работать, если я не писал, на: opengl (win, mac, linux), dx (win), d2d (win), gdi (win), skia (все ОС), vulkan (win), metal (iOS), opengles (ios, android) и может ещё с чем-то, что я забыл
И как только надо было сделать в контроле шаг влево-вправо, начиналось, как в преферансе - "кровавые 10".
Тем не менее, я и мои тогдашние коллеги считали существенным преимуществом Delphi возможность (и относительную легкость) написания своих элементов управления. В остальном тогдашнем мире разработки для Windows это было не так: для MFC сделать нестандартный элемент управления было отдельным квестом (я его проходил, если чо), а для Visual Basic элементы управления вообще нужно было писать отдельно, на Visual C++.
WinForms и WPF ровно так и работают. Asp.net forms тоже пытались в "накидать", но очень быстро ушли от этого (и слава богу). Хотя при желании можно нарыть визуальный конструктор клиентской части для web.
Выше уже про это писали, но всё равно скажу что универсальные решения из коробки далеко не всегда подходят. На сколь-нибудь сложных проектах либо ищешь стороннее решение, либо пишешь с нуля.
А это нормально перкжевывается системами контроля версий и можно ли нормально делать ревью кода?
Я помню тот секс с TPanel и их Alignment, чтобы сконструировать форму и это казалось таким неправильным. А потом мне пришлось создать формочку в Android Studio, лопни мои глазоньки. Дельфи - прелесть.
Далеко не все невизуальные контролы следует размещать "на форме".
Лично для меня, как и для многих, Delphi закончился как раз таки с выпилом компиляции нативных приложений в пользу .NET в Delphi 8. Сильно огорчившись по этому поводу перешел на C/C++ (в GNU-том исполнении), что, по правде говоря, даже в годы максимальной популярности Delphi воспринималось как серьезный апгрейд в профессиональном плане.
Delphi 8 - единственная версия с .Net, дальше на .Net забили и вернули полный натив
Не совсем. Для Turbodelphi была net версия.
Да, недавно узнал про это от кого-то на хабре спустя 20 лет. В любом случае, к этому моменту с Delphi я уже благополучно слез (а вскоре и с Windows вообще), поэтому меня это никак не коснулось.
Delphi 8 — это была единственная .NET-only версия, несколько последующих (2005, 2006, 2007) могли делать как .NET, так и нативный код. Потом .NET начали выносить в отдельные продукты, 2009 была уже снова чисто нативной.
Я пес его знает, но и в современгых версиях Delphi вроде есть возможность генерации нативных приложений. По крайней мере в Turbodelphi (соответствует, если не путаю, аерсии 2007) было две версии, нативная и net.
Да, в тот момент многие почувствовали себя обманутыми. Логичной была мысль, что раз остался только Дотнет, зачем теперь прослойка в виде Делфи? Максимальная ценность была в VCL, RAD, компактном и быстром коде на выходе, а не в языке.
Многие чувствовали себя обманутыми когда выяснилось, что отныне их код не только не будет исполняться напрямую процессором, но и будет вынужден таскать за собой весьма тяжелый рантайм.
Да, я прекрасно понимаю, что тех же Java-сеньоров не очень-то беспокоят подобные приземленные мирские проблемы бытия в силу старинной мантры о том, что человеческое время стоит дороже машинного. Однако, Delphi-плебеи в своем большинстве оказались к подобной постановке вопроса морально не готовы.
На данный момент опять набирает популярность, но уже скорее в виде lazarus-а. Я свои проекты на него переношу. Builder я как раз всегда не очень любил и старался переводить проекты с него на паскаль.
Автор сильно превозносит Delphi. Эта среда была известна только в СНГ (Россия, Казахстан), и то только потому, что ее удачно украли, крякнули и стали преподавать в институтах. Спросите любого западного программиста - он понятия не имеет, что за борланд, что за дельфи, он даже слов таких никогда не слышал. Из известных программ, написанных на Delphi - молдавский TheBat, русские QIP и AIMP, эстонский Skype да пожалуй и все.
FL Studio
Именно поэтому АНБ и ФБР США выпустили целый отчёт о необходимости перехода с C/C++ в критически важном коде на Rust, Java, C# и в том числе Delphi/Object Pascal
Total Commander
Не согласен про любых западных программистов. С 2000 до 2010 года участвовал в проектах с немецкими компаниями и Delphi был там очень популярен. Разработки для поддержки разного бизнеса до крупного. Эти разработки конечно не так известны, как TheBat. Возможно за океаном все было не так, пишу про Европу. Не знаю, как там что активировалось после продажи, но Borland Delphi вроде никаких кряков не требовал. Причем в середине 90х у меня лично было купленная в книжном магазине версия 3.0 Мое мнение почему популярность упала: неудачные попытки войти в Веб в качестве серверного языка. То же самое и с Power Builder произошло.
Delphi версии 5.5 требовала не кряков, а генеоатора ключей, которые требовалось ввести при установке). Для более поздних версий были и крякм.
Мы о каких годах говорим с 5.5? Я не совсем понял, в моём окружении всё кончилось на 4 версии, объясню 4 нас вполне устраивала до повсеместного применения XP, она была надёжна, проверена и работала безотказно, были просто тесты с 6, 7, 8, это помню только по эмблемам, где-то запускал, где-то видел, но это было чисто тесты, никто на них писать в 2005-2009 даже не думал, уже был fpc и весь код был переведен на него, из смешного помню что мы лет 5-6 ожидали выпуска 1 версии lazarus и издевались что он никогда не выйдет, давайте уже на чём-то типа 0.9.4, давай уже это в продукт пустим, что сыграло нам на руку когда внезапно нам сказали что теперь проблемы с лицензиями и мы обязаны выпускать станки только под управлением русского alt linux
Так Дельфи никогда и не был средой для крупных коммерческих проектов. Если кто то хотел зарабатывать миллионы, то предпочитали заморочиться с MFC. А для продуктов в вечной стадии POC или локальных продуктов в отрасли, создаваемых своими силами был в самый раз.
Просто в СНГ крупных коммерческих продуктов было поменьше а мелкой дешёвой разработки побольше.
Altium Designer (а вот это уже серьезнее медиаплееров и почтовых клиентов)
"эстонский Skype"... одного этого уже достаточно.
немецкий Total Commander
я года 4 назад ещё писал на дельфе. Внутренняя автоматизация для нужд соседнего отдела. Но я не разраб, мог позволит себе писать на том, к чему привык и что удобней. А у дельфи три проблемы:
1.Продукт от вендора. Но от вендора слабеющего (борланд) он пошел по рукам. За Java стоит Oracle, за c#, ms, за питоном огромное сообщество а не конкретный вендор- есть открытый процесс разработки и языка и интеретатора и куча ide. Загнется одна- перейдем на другую.
С дельфи же было почти без вариантов. Lazarus вышел довольно позно, остальные компиляторы паскаля довольно нишевы -fpc, gnu pascal, Free Pascal . Размер экосистемы оказался не велик, количество библиотек для разных задач ограниченно: от корректировки прав на файлах ntfs и корректировки sidhistory до работы с NoSql базами. для Питона- пожалуйста. Для повершела куча всего есть. Ну и для плюсов и .net. а для дельфи-увы
Sun/Oracle и MS могли выкладываться в своей продукт. У меня в бытность учебы в вузе была лицензионная ms visual studio c msdn на dvd дисках. MS раздавала. Как студенту ай ти специальности. Она могла вложиться в преподавании своих языков и раздавать лицензии. Дельфи же была пиратка. Лицензия стоила 999 долларов. У java и вовсе бесплатные IDE.
2. Есть мнение, что ему аукнулась роль первого языка в колледже. Куча некачественного кода джунами-недоучками написана и этот ореол перенесли на язык и среду.
3. Наконец -дельфа всё таки была заточена под winforms классические приложения. А массово стали популярны браузерные варианты (фондэнд+ бэкэнд), где дельфи не получила значимого распространения. + модная кроссплатформенность + мобильная разработка.
Я на Делфи писал cgi для iis, вполне себе бекенд
Дельфи была сильна работой с субд из коробки и набором датабоунд визуальных компонент. Но клиент/сервер требует энтерпрайз редакцию с ценником 3к $.
Это её и убило при ценнике на студию в 500$
После появления в Net wpf и linq с EntityFramework эта её сила вспоминается как наивное детство
В принципе да, примерно после 800-страничного учебника по ВПФ =)
И грид в ВПФ из коробки бедненький и тормозной.
Обидно, что потом ВПФ отменили, мутировали ее в мяуи, зря потрачено время.
Все xaml фреймворки в принципе одинаковы. Если надоело бегать за майрософтом есть вот Avalonia
Нужна интеграция в студию с нормальным визуальным редактором. Для авалонии или мяуи такое есть? Инвестированного времени жалко терять.
Потому что хамл на не тривиальных случаях превращается в вавилонскую башню и текстовым редактором задолбаться.
Я и от ВПФ то не особо в восторге в этом плане. Полу- визуальная правка а потом полу-визуальная отладка биндингов.
Так что в простых случаях предпочту винформс или дельфи
А ещё в Delphi не навязывала многослойную (слоистую) архитектуру - когда управление UI - отдельно, данные, получаемые из UI (можель данных) - отдельно, обработка данных (бизнес логика) отдельно, работа с БД (репозиторий). В результате приложение на Delhi, даже корпоративное, где снижение запутанности (coupling) - это необходимость, с легкостью превращалось в равномерную смесь обрабочиков UI, проверок введенных данных, обработки этих данных данных и сохранения в БД. Про coupling такой смеси говорить не приходилось, что делало типичное legacy на Delhi весьма жутким.
Впрочем, во-первых это была общая черта тогдашних средств разработки (тех же WinForms и WebForms в .NET, к примеру), а во-вторых, никто не запрещал таки придерживаться слоистой архитектуры.
Средства более позднего периода - в C# это WPF или MVC - стали слоистую архитектуру навязывать, и это дисциплинировало.
Размер экосистемы оказался не велик, количество библиотек для разных задач ограниченно: от корректировки прав на файлах ntfs и корректировки sidhistory до работы с NoSql базами
NoSQL есть в Delphi при чем из коробки (и уже лет 10), а ntfs и sid-history - это Winapi, с чем Delphi работал всегда прекрасно.
Лицензия стоила 999 долларов.
Используй Community версию. Она бесплатна для личного использования
А массово стали популярны браузерные варианты (фондэнд+ бэкэнд), где дельфи не получила значимого распространения. + модная кроссплатформенность + мобильная разработка.
Delphi уже давно кроссплатформенный язык, где ты можешь один и тот же проект собрать сразу под все платформы (Win/Linux/MacOS/iOS/Android)
А запустить саму IDE и работать под линухом можно?
Пока к сожалению нельзя. Недавно только, в этом году, появилась 64 битная версия среды.
Получается, саму IDE чем-то другим собирают, раз она саму себя не может собрать под все платформы?
Недавно только, в этом году, появилась 64 битная версия среды.
Как по мне, так это тоже говорит о том, что среда эта скорее мертва. Последний раз 32 битный процессор у меня был лет 20 назад.
Это я не к тому, чтобы фекалиями закидать, продукты Борланда очень любил, сначала это был С под DOS, потом Делфи, собственно, а потом С++ Билдер, на котором я довольно долго просидел.
Фреймворк VCL - не кроссплатформенный, он нативный для win32. Без костылей его нельзя собрать под другие платформы. Для создания кроссплатформенных приложений с GUI нужно использовать другой встроенный фреймворк - FMX.
Да будет вам известно, что Visual Studio тоже буквально пару лет назад (2022) вышла в 64 бита.
Фреймворк VCL - не кроссплатформенный, он нативный для win32. Без костылей его нельзя собрать под другие платформы. Для создания кроссплатформенных приложений с GUI нужно использовать другой встроенный фреймворк - FMX.
У меня есть классный фреймворк, используйте его все, но сам я буду использовать другой. Как по мне так звучит странно и не внушает доверия.
Да будет вам известно, что Visual Studio тоже буквально пару лет назад (2022) вышла в 64 бита.
Что я могу сказать, плохо там у вас на десктопе всё, VS Code с первой версии был 64 бит уже 10 лет назад.
Повторяю ещё раз, VCL - это нативный фреймворк. Он предназначен для создания нативных GUI в Windows средствами Windows. Этот фреймворк появился с первых версий Delphi, когда о кроссплатформе вообще никто не думал. Среда разработки изначально создавалась именно на этом фреймворке.
FMX - это кроссплатформенный фреймворк, созданный гораздо позже VCL для создания кроссплатформенных приложений и он не совместим с VCL по понятным причинам.
Смысла в 64 битной программе нет никакого, если она не потребляет более 2гб ОЗУ. По этому, большинство программ, в том числе новых - это 32 битные программы. Они более быстрые и экономичные чем 64 битные.
А у VS Code нет выбора, потому что жрет он ОЗУ как ненормальный и упал бы сразу, будь он 32 битным. Так что 64 бита - это не преимущество, а необходимость от безысходности.
Повторяю ещё раз, некроссплатформенный инструмент для кроссплатформенной разработки выглядит странно. Для меня это означает, что разработчики сами не используют то, что рекомендуют другим и это красный флаг. Что мне, пользователю линуха, делать с информацией о том, что на Делфи можно разрабатывать кроссплатформенные приложения? А что касается памяти, прямо сейчас у меня в VS Code открыт проект в котором суммарно под 300к файлов и "сожрал" он безумные 1ГБ из 128ГБ ОЗУ. Где вы тут проблему видите?
Смысла в 64 битной программе нет никакого, если она не потребляет более 2гб ОЗУ. По этому, большинство программ, в том числе новых - это 32 битные программы. Они более быстрые и экономичные чем 64 битные.
Хотелось бы посмотреть статистику. А то я не понимаю, как программа использующая больше регистров большей разрядности может быть медленнее программы, которая в этом ограничена. А что касается смыслов, использование 64 битов в конечном итоге позволит избавиться от второго комплекта библиотек. В эппл вроде так и сделали в итоге, если я ничего не путаю.
Они более быстрые
Это заблуждение основанное на тиражируемых стереотипах двадцатилетней давности являющихся следствием непонимания архитектур и принципов работы процессора
Рекомендую поинтересоваться, когда студия стала 64-битной)
Была такая штука - Kilix. Это была версия Delphi для линукса. Прожила, правда, недолго. Борланд ее закопал (оказалась убыточной).
Интересно, пробовал ли кто современный Дельфи с кросскомпиляторами под вайном запустить?
модная кроссплатформенность
Наверное, единственное, что меня расстраивало после перехода на линух, так это то, что там нет The Bat! Как по мне, так это огромная ошибка Ритлабс за всё это время так и не сделать свой отличный мейл клиент кроссплатформенным.
Качественный скачок в развитии .Net произошел из-за разрыва Microsoft и SUN на почве Visual J++, тогда C# и стал для Microsoft языком #1, а .Net Framework - своей средой выполнения managed code вместо JVM,
Мнение простого юзера о Net. Бывает, найдёшь чудесную и нужную тебе программку, причём и с размером на 5-10 мегабайт.. Радостный, бежишь её устанавливать.. И тут для установки требуется последний Framework . И тут сначала осознаёшь, что эти фреймворки весят размером с ОС 2000-х годов, а во вторых , создают несколько процессов в диспетчере задачи и тысячи взаимосвязи в реестре.. И впоследствии думаешь: бойтесь данайцев, дары приносящих
Это мнение 50+ деда, который еще помнит сколько весили оси четверть века назад. Обычному "юзеру", у которого 512 гигов места в телефоне и пара терабайт на винте, абсолютно плевать на плюс минус 100 мегабайт, которые ставятся однократно.
Ну да, конечно, особенно когда этот самый фреймворк вдруг понадобился для запуска новой версии простой, но незаменимой (ибо сертифицированной) программки под Винду, которая только ради этого живет в виртуалке с ограниченным файловым пространством, которое расширить теперь можно только с переустановкой всего этого зоопарка.
Ибо написано как раз вот этими, у кого плюс-минус пара терабайт вообще не вопрос, у них игруха половину этого места занимает ))
А вы уверены в этом? По моим наблюдениям, у обычного юзера SSD на 256-512Гб, и дешевый китайский телефон (ещё и устаревший как правило), где хорошо если 128Гб встроенной памяти...
128 ГБ на телефоне вот вообще не жмёт, хорошая цифра для флагманов лет 4 назад.
Неделю назад купил последний пиксель со 128 ГБ, на предыдущем телефоне, которым пользовался 4 года, занято 80, именно поэтому решил за 256 не переплачивать. И это я старовер, там много музыки и аудиокниг в виде mp3 файлов. Куда его девать место это, зачем на телефоне больше?
И этот SSD забит какой-то хренью типа фильмов скачанных с торрентов и игрухами по 20 гигов которые лень удалить. 100 мегабайт это же так много, прямо принципиально, на этом фоне.
Тут нужно уточнение. Какой год, на момент которого описывается флешбек? :) Фреймворк давно в составе винды, а новые Core распространяются часто без необходимости что-то ставить.
А то что для запуска любой чудесной программки требуется операционная система весом несколько десятков гигабайт вас не смущает?
Delphi - тёплые воспоминания. В 90-x тоже переходил с ассемблера и С на него. Писал всякие утилиты под виндовс. Помню до сих пор одну программку. Была такая игра в тех же 90-x Братья пилоты. И там был холодильник-сейф с головоломкой. Головоломка представляла из себя ручки-переключатели. 5 рядов по пять ручек. Переключение одной ручки - переключала все ручки по диагонали и по вертикале от этой ручки на противоположную позицию. Что бы открыть сейф - все ручки должны быть вертикальными.
Просто переключая ручки - было практически невозможно решить эту головоломку. И тут мне на помощь пришёл Delphi. Набросав интерфейс в виде этого холодильника я сделал программу которая брутфорсом перебирала все варианты для получения результата - все ручки горизонтальны. Для старта нужно было только перенести стартовое положение всех ручек из игры в программу. Результат выводился в виде последовательности какую ручку надо переключить.
Показав программу однокласснику - мой "хакерский" имидж взлетел до небес! Кстати приятель мне показал какой то алгоритм - там нужно было как то хитро переключать ручки и чудесным образом в последствии все они выстраивались по горизонтале. Додуматься до такого алгоритма было невозможно. Где то был прочитан в журнале.
Уже многие годы спустя, когда я обучал своих детей программированию, а я знаю что простое обучение это ужасно нудно и неэффективно, а когда решаешь конкретную задачу - то интересно. В общем тоже дал задание своим детям взломать этот холодильник программой. Только уже использовался C#.
Додуматься до такого алгоритма было невозможно
Не соглашусь. Помню что промучавшись какое-то время, всё-таки получается дойти до решения. Если правильно понмю, нужно было просто прокликать все ручки, которые в исходном состоянии были в "неправильном" положении (именно в исходном состоянии, то есть надо запомнить нужные ручки).
Да там нужно было кликать по таким ручкам. В несколько итераций. Но как до такого можно был додуматься? Ведь пока кликаешь - каша из ручек становилась всё более хаотичной. А то что идёшь по правильному пути было видно только за 1-2 оконечных клика.
Да это и не важно. Школьнику было не интересно (да и не возможно) применять какой то математический аппарат - и найти какие то математические зависимости в такой задаче (хотя математику может и интересно).
Можно наверно было просто наугад найти потратив пару часов - просто кликая всё подряд.
Мне задача показалось очень подходящей для изучения Delphi. Не было бы этой задачи - нашёл бы что другое.
Просто переключая ручки — было практически невозможно решить эту головоломку.
Ну, это если не думать. А если подумать, то, насколько я помню, нужно было повернуть все рукоятки в том же ряду и в том же столбце, в котором была «неправильная», в результае чего все рукоятки поворачивались чётное число раз, а «неправильная» — нечётное.
Я не хочу, да и не могу, вспоминать что там было 30 лет назад. Что я помню сейчас - загадка была не простая. Простое тырканье ручек не приводило к решению. И повторяю - это совершенно не важно. Мне тогда был интересно решить с помощью Delphi любую интересную задачу.
P.S. А по поводу думать - мне было интересно "думать" и изучать Delphi. Я вас не минусил.
По-моему, автор поторопился и выложил черновик с заготовкой статьи. Обратите внимание на заголовки без содержания "Основные релизы Delphi:", "Основные версии .NET Framework". Или это опять помощь ИИ?
Ходили устойчивые слухи, что упадок Delphi был вызван финансово успешными конкурентами, которые скупили акции, вошли в совет и полностью блокировали развитие платформы, одновременно переманивая разработчиков. Называли Майкрософт как главного актора.
Если без слухов, то упадок Delphi - следствие упадка Borland. А этот упадок с Delphi не связан. Под конец существования Borland основные деньги ей приносил JBuilder - среда разработки на Java. Пока конкуренция шла с другими коммерчискими средами для Java, типа IBM WebSphere - продажи шли и деньги были. Но потом вырос Eclipse (это - opensource) и продажи идти перестали. Т.е. можно сказать, что Delphi погубило "свободное ПО" ;-)
Но компании JetBrains свободное ПО не помешало, значит причины были еще какие-то.
Так они просто сделали лучше, чем было в Eclipse. Поэтому и не помешало.
так мелкая компания которая делает только это и компания с большим наследством кучи продуктов и менеджмента и затрат - в неравных условиях в части эффективности. Офис из 3 человек в праге, и здания в долине с сотнями людей - немного разные расходы.
Значит опенсорсный Eclipse успешно задавил крупную точку монополизации, годами прибивавшей гвоздями к и без того занимавшей чрезмерно большую долю рынка платформе-монополисту не только разрабов, но и пользователей их софта (даже тех, кто в гробу ее видал и белых тапочках). И это замечательно!
Это приколько, как причитают по Delphi. Хотя он живее всех живых.
На рутракере скачиваний всех RAD с Delphi раза в два больше чем всех Visual Studio.
Если поискать слово Embarcadero среди пследних версий популярнейших инженерных программ, то на удивление будет много находок.
Просто Embarcadero ужесточил контроль за лицензированием, и с ним стало гораздо легче обжечься чем с Visual Studio.
Так Community версия MSVS покрывает уже примерно все что нужно в большинстве случаев. Кровавый энтерпрайз все равно заплатит. Зачем его качать с трекеров?
VS многих версий качаются с сайта MS.
А зачем вообще качать Visual Studio на рутрекере? :)
Cummunity Edition давным давно бесплатна и покрывает 99% потребностей и задач.
Ещё есть VS Code с расширениями и Rider с лицухой для обучения за копейки, и Community редакция появилась недавно.
Delphi применяю до сих пор. Первый раз это было в 1999, когда создал в связке с. SQL SERVER систему с CRM и много еще чего. Снабжение, сбыт, интерфейс с 1С бухгалтерией. Все это прожило 10 лет и умерло просто потому что захотелось конторе перейти на 1с, да и мне поддержка уже надоела старой системы, так как перешел от разработки программ к разработке электроники. Сейчас это вернулось, так как разработка электроники требует разработки программ тестирования и т п. Ничего лучше и удобней Delphi с такими задачами просто нет. Интерфейс делается быстро, все зависимости в БД.
Delphi — IDE (а позднее и ЯП) для создания нативных приложений¹. А .Net — платформа, построенная вокруг виртуальной машины (CLR). Сравнивать их, извините, столько же смысла, как во́рона и письменный стол.
¹ По иронии, позже Delphi стал одним из инструментов .Net.
Сравнивать их вполне можно, так как есть большой спектр задач, которые решаются в обоих платформах.
Это не ворона и письменный стол. Это два письменных стола разного устройства и вида.
И вам немного не хватает знаний для сравнения. .NET давно имеет режим компиляции Native AOT, создающий полностью нативное приложение, не требуя предустановленных VM в системе. И до Native AOT был давно режим сборки вместе с VM, который также ничего не требовал для работы.
И вам немного не хватает знаний для сравнения. .NET давно имеет режим компиляции Native AOT
А вам не хватает чувства контекста. В период, описываемый в статье (когда Майкрософт задушил Delphi), какой был Native AOT?
Ладно, хоть никто не триггернулся на слова о том, что CLR это виртуальная машина. Поскольку в реальности (а не в статье) Майкрософт победил Борланд задолго до (рекомендую автору почитать о том, как Майкрософт всех побеждал, в книжке In Search of Stupidity) и реальная война шла с Java, а не с Delphi, МС-маркетологи долго всем говорили, что JVM это VM, а CLR это никакой не VM, а НЁХ под названием LR. Понятно почему: тогда компьютеры были медленными и словами «виртуальная машина» можно было отпугнуть программиста. Многие и до сих пор верят, что LR это нечто концептуально новое. А потом на одной из конференций вышел кто-то из технобогов МСа и сказал: «Вы что, реально поверили в эту мульку про “LR не VM”? А-ха-ха!». Было смешно.
Долго я этот аот искал и так и не нашёл тогда. В какой версии он хоть полноценно начал работать?
Чтобы не только статья была, что есть аот, но... А галочка в опциях компилятора
Я аж слезу пустил. Я как раз в 2002м ушел из Делфи, которую самостоятельно освоил для пары работ по термодинамике (не своих, что характерно) и затем около года ковырял, просиживая штаны в одном нии. И свичнулся как раз в дотнет. Мне один приятель тогда сказал, что существуют так называемые айти конторы, в них люди сидят и кроме программирования ничего не делают, а зарплату получают в десять раз выше. Я подумал он шутит, но оказалось он даже знает одну такую контору, несколько гиков а каком-то там подвале. Пошел туда, ожидая что розыгрыш закончится и надо мной поржут, но внезапно вляпался в свое первое собеседование в жизни. Это мне и 20 не было, выходит. Реально сидели ребята в подвале и программировали, на дядю из-за бугра. Спросили меня, хорошо ли я знаю дотнет, я ответил что я в нем эксперт. Надо отметить, что это слово я слышал впервые. Впрочем, реальных экспертов в то время и в природе не было, только-только версия 1.1 релизнулась, после беты. Это я потом узнал. А процессе собеседования выяснилось, что эксперт я пока только потенциальный. Не став меня мучать незнакомыми словами, чувак дал тестовое для отвода глаз и собирался про меня збыть. Но не тут-то было. При помощи шести сидиромов с MSDN и студией, купленных на балке, приобретенной там же какой-то брошюры по дотнету и скрипучего диал-апа на работе, я справился. Правда сел я его делать в пятницу вечером, а закончил в понедельник утром. Без перерывов. Но подумаешь, две ночи не спать, дело молодое. Спрятался в офисе (дома даже диал-апа не было) от вахты, запасся бутербродами с колбасой и в понедельник пошел сдаваться. Не знаю, чему чувак больше удивился: тому что я вообще пришел, моему состоянию зомби, или тому что программа моя работала. Но взял меня джуном. Выходит, я пошел на поводу у корпорации зла и предал родной паскаль. Борланд пытались сесть в уходящий поезд и докрутили в Делфи компилятор из обжект паскаля в дотнет мсил, но это их не спасло. И это при том, что у них был даже собственный си, не такой как у всех, причем раньше майкрософта. Да, статья определенно навеяла на меня ностальгию...
Стать шикарная.
Я так понял, что да, причиной стало хитросплетение событий:
1 получается Oracle со своей Java и главное ВМ стали триггером для Майкрасофт
2 Borland занял хитрую позицию не входя в рынок IDE на основе ВМ
3 не потому что Майки плохие, но так вышло, что рынок порешал и в итоге Майки выкупили Borland, но так как у них в портфеле был уже и С и куча других ЯП, Pascal/Delphi совершенно случайно оказались нишевыми.
Получается Borland воевал с новой технологией Виртуалных Машин Интерпретаров, а с ними не воевать надо было, а принимать.
В Delphi 7 в Windows 10 пропадают визуальные компоненты и в design и в runtime.
Надо задвинуть за экран и выдвинуть, тогда появляются. Лет 20 назад такого не было.
Поэтому перешёл на трофейную Delphi 11. В ней ничего не пропадает,
но exe в 5-10 раз больше, чем в Delphi 7. И чего они туда суют?
Достоинство Delphi быстрый запуск программы из IDE - мои программы практически мгновенно.
Какой язык быстрее?
Еще огромное число встроенных компонентов и наличие посторонних на все случаи.
В каком языке их больше?
В каком ещё языке есть такой встроенный визуальный редактор UI?
Обычно язык отдельно, IDE отдельно, что сложно для начинающих.
И, несмотря на древний возраст, в интернете всё ещё можно найти ответы на все вопросы.
И Pascal, возможно, самый простой язык, хотя и не самый краткий из-за begin end then.
Но зато в нём нет замороченных, неочевидных конструкций, вызывающих лишнее напряжение ума
и любой программист в основном всё поймёт, даже если впервые видит Pascal.
Какой язык проще? И при этом максимально близок к железу:
можно использовать ASM и видеть как операторы Pascal выглядят в ASM.
И для меня большое достоинство создание exe, не требующего установки netframework, JVM, Python, PHP.
А что ещё нужно?
На всякий случай, в .NET уже очень давно есть режимы сборки со встроенной VM, а также Native AOT, создающий нативный бинарник, который запускается сразу. А ещё отличнейшая поддержка работы в docker-контейнерах, которых целая куча на любой вкус с разными линуксами, и в целом для серверных приложений он топ.
Еще огромное число встроенных компонентов и наличие посторонних на все случаи.
Что с версиями? Если в проекте 500 сторонних компонентов - есть ли шанс, что он соберётся ещё у кого-то?
Если есть сторонние компоненты, то в другом месте их придётся устанавливать,
причём каждый по разному: где-то bpl, где-то dpk, добавлять пути, compile, install,
где-то нужно даже переписывать bpl в папку delphi/bin.
Обычно этот порядок установки описывается в описании компонента.
Это большой недостаток Delphi.
Для разных версий Delphi есть разные файлы, так что шанс что всё соберётся есть,
хотя, возможно, другие программы на этой Delphi перестанут компилироваться,
но это очень маловероятно.
Возможно, можно сохранить все папки со сторонними компонентами и ветвь реестра,
где Delphi хранит сведения о них и в другом месте восстановить не устанавливая.
Возможно, даже есть программа для этого, но не встречал и стараюсь поменьше
использовать сторонние компоненты, предпочитая библиотеки, которые не нужно устанавливать.
стараюсь поменьшеиспользовать сторонние компоненты
Вот такое вот преимущество, которое лучше не использовать ;)
Меня это когда то тоже огорчало. Находишь в интернете какой то кусок кода. А в нем ссылки на какой то компонент. И начинаешь искать, что это, откуда оно взялось (самая прелесть если оно платное), и какую версию курил автор.
но exe в 5-10 раз больше, чем в Delphi 7. И чего они туда суют?
EXE-файл сейчас выходит больше, чем в старых Delphi, из-за раздувшейся RTL. Но кое-что можно подкрутить, например:
выкинуть отладочную информацию (Project Options - Building - Delphi Compiler - Linking - Debug Information и Include remote debug symbols).
убрать RTTI, добавив в каждый юнит
{$WEAKLINKRTTI ON}
{$IF DECLARED(TVisibilityClasses)}
{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}
{$IFEND}
Достоинство Delphi быстрый запуск программы из IDE - мои программы практически мгновенно.
Какой язык быстрее?
Python с Qt не хуже
Конструировать в qt Creator форму само по себе ужасно. А вручную ее привязывать к коду на python это пц.
Или я их как то не так готовлю? ;)
Не могу сказать, не видел, как вы их готовите. Один из моих вариантов здесь - https://habr.com/ru/articles/336478/ + соседние статьи.
Я согласен с тем, что в делфи было очень удобно, когда дабл-клик на событии автоматически создавал его обработчик. Или переходил в код уже связанного обработчика.
Но, к чести PyQt, у них реализовано связывание слотов и событий по имени. То есть ничего связывать самостоятельно не надо - достаточно создать метод с правильным именем и объявить его слотом - он сам привяжется к событию.
Хуже. Питон медлительный, а быстрых компиляторов С++ нет.
Или имеется в виду кадавр PyQt?
Это не кадавр, а нормальная обертка к Qt. Подозреваю, что вы не пробовали - я прав?
Кадавр именно потому что обертка/биндинг (вероятно правильней было сказать - франкенштейн, собранный из лоскутов) . Все это двуязычие ведёт к усложнению разработки и сопровождения, за что в частности данной темы ругают сибилдер.
Была же кстати и версия дельфи на базе кьют, Kylix.
А проблема Кьюта та же, что и у дельфи - ценник.
У Delphi 7 есть еще один недостаток: там нет Юникода. Либо извращаешься сам, либо ставишь дополнительные компоненты, чтобы он был. Без Юникода нынче тяжело. :-(
У Delphi 7 есть еще один недостаток
2002 год, однако. Стюардессу можно уже отпустить на пенсию.
Сам по себе 2002 год ничего плохого с собой не несет. Все работает и собирается. Даже плюсы есть. Например, VCL в D7 добавляет к exe килобайт 400 – 500, а новомодные FMX в «Афинах» сколько? Мегабайт 30 – 40 – 50? Единственная проблема D7 — это полная неюникодность. Увы, проблема неустранимая.
Ну не надо сравнивать VCL - нативный фреймворк, где все идёт из системы и FMX - кроссплатформенный фреймворк, который от системы берет только то, где рисовать.
Единственная проблема D7 — это полная неюникодность. Увы, проблема неустранимая
Просто не используйте VCL, а подходящие сторонние визуальные библиотеки. Сам язык уникодность не ограничивает.
Можно, конечно, и сторонние использовать. Бонусом можно словить баги этих библиотек. Ну и сама юникодность будет неполной. Помнится, TNT делал сами компоненты юникодным, а TApplication — нет.
Я в Delphi 7 использую KOL - там почти прямое использование Winapi для визуальных компонент (уникодность на уровне ОС).
Помню такое, смотрел. Но мне как-то не зашло — одни компоненты для дизайна и дебага, другие — для релиза, надо как-то переключать. Захотел какой-нибудь график нарисовать — компонент для него поставишь, потому что все они наследники TCanvas или еще чего-нибудть из VCL, поэтому рисуй сам... В общем, идея интересная, но не для всех. :-(
А они (KOL) еще живы? Или заброшены?
По тому, как сложно ставить сторонние библиотеки: популярный питон в "голом" виде тоже умеет немного, но при этом его хвалят за кучу готовых библиотек, которые нужно доустанавливать.
может, пора уже на Лазарус переходить?
Перешёл с Delphi на .NET во времена NET 2.0. Причиной не было какого-то хайпа, никто к этому не принуждал, не принуждали обстоятельства, в компании где я работал, имел значения результат, а не способ его достижения. И перешёл именно потому, что C#, философия .NET, вектор развития понравились, а застой делфей с фокусом на десктопе, неудобный избыточный язык паскаль не нравились.
И ничуть не прогадал. Сегодня ведём разработку на dotnet в полный рост, я не встречал задач, которые бы прекрасно на нём не решались. Он самодостаточен, в нём есть всё, развитие идёт большими темпами, нет ощущения тяжести, что какие-то легаси тянут на дно. Он работает прекрасно в k8s, на всех платформах, окружение для разработки поднимается легчайше.
В общем, автор мог бы также рассказывать про советскую колбасу, зелёную траву и пломбир. Ничего по сути.
Притянуто за уши, ИМХО.
Был Турбо-С/С++, потом Borland-C/C++, потом MS VisualStudio и MFC - и ничего не "громоздко", всё довольно просто (если не придираться к деталям, но речь не о них).
А с другой стороны плоской Земли был Pascal и Delphi.
Которые почему-то попали в обучающие программы (чтобы учить детей тому как не надо программировать? )
И были битвы "пасквилянтов" с "сионистами" в fido7.*
В конце концов Паскаль был забыт.
По Tiobe Delphi каждый год ростет, и входит в 10 популярных языков, а вы тут его хороните.
Был крупный десктоп проект, который пережил несколько реинкарнаций. Брал он начало в Delphi 2.0 и закончил боевой путь в Delphi 7.
В один момент, случилось так, что надо было систему "легализовать", много экземпляров установлено было в компаниях требовавших лицензионной чистоты.
И пошли мы искать лицензию на семерку. И нашли в недрах компании Embarcadero. Нам много не надо было, просто лицензию на Delphi 7, на три рабочих места. По всем нашим необходимостям этого хватало.
Связались с отделом продаж, и оказалось, что на тот момент лицензия на семерку входит в пакет РадСтудио. И что для нашей компании ценник 40 000+$ за одно рабочее место. Как сейчас не знаю, но на 2011 год ценник был такой.
Прайс лег на стол начальству, а с понедельника был утвержден пилот проект перехода (на тот момент) на net 3.5
По состоянию на сегодняшний день проект уже давно живет на net-8, приобрел не только десктоп версии, но и вэб, широкую серверную инфраструктуру и много еще чем прирос.
Embarcadero не пожадничай, остались бы на Delphi и проект бы умер. Было слияние компаний, и у поглощающей компании на серверах все крутилось на .net , и благодаря тому что наша система уже была переписана все интегрировалось почти без потрясений.
Джентльмены, так что - за 20+ лет ничего не придумали удобного в плане рисования интерфейса? BC++Builder - накидал компонентов, описал объекты и связи между ними и всё готово. Тут написали про QT Creator и сразу же раскритиковали.
Не гоже так, слишком просто, а нужна экспертность закрепленная слезами.
BC++ Builder был комбайном. Помню в нем было минимум три типа строк: std::string, winapi и строки из Delphi. Где нужны формы приходилось писать как на делфи, только используя в два раза больше слов из-за особенностей языка. В удобстве программирования на winapi он проигрывал Visual Studio. При этом весил и тормозил как чугунный мост.
К слову, заходите к нам на Delphi-огонек.
Основной чат: @Delphi_Lazarus
Список бесплатного Delphi/Lazarus стаффа: https://github.com/Fr0sT-Brutal/awesome-pascal
Delphi проиграл потому что не предоставлял Community версии, спохватились в последний момент, может эксСССР всем все равно, то в капиталистических странах вопрос легальности софта очень важна. Сделали Community + Удачная идея с интеграции на мобильные платформы = рост пользователей.
Delphi был человечным, понятным, продуктивным. Его можно было выучить в колледже и сразу писать серьёзные программы.
C# тоже можно "выучить в колледже" и сразу писать серьёзные программы. Такие же эпитеты "человечный, понятный, продуктивный" могу дать про C#.
Ни одного внятного аргумента что мы такого потеряли (кроме мусора бесконечных begin-end) в статье не т.
Простоту разработки маленьких дектопных приложений потеряли.
Как язык, Шарп конечно лучше, но фреймворки сложнее, хоть и функциональные.
Функциональнее из фреймворков в C# это только ASP, остальные фреймворки далеко не на голову выше Дельфовых. В частности:
VCL богаче WinForms
FMX удобнее и функциональнее WPF/Avalonia/MAUI
Про fmx не буду говорить, уже не использовал. Он сильно опоздал, как и веб фреймворк для Д, Sencha.
Полистал книгу А. Магни про Firemonkey (внимательно потом дочитаю, про Андроид интересно) .
Не вижу аналога гибкости Хамл. Куда смотреть?
Какой гибкости, например?
Вот как в этом комменте про многоуровневость. Когда условный TPictureButton собирается в хамл из картинки и обычной кнопки и чего ещё угодно, когда любые свойства биндятся с любыми другими свойствами других визуальных элементов через описанные тут же конверторы итп
И это все корректно рисуется при ресайзе, разных dpi, размерах экранов итп
Начинал свой айти примерно в 1986. Когда появился - я delphi обожал. После создания интерфейса под windows на winapi (свят -свят-свят) - это был даже не глоток, а цистерна свежего воздуха. Скорость компиляции, размер exe , язык, сторонние компоненты и т.д. - все отлично и великолепно. Но оценивая его сейчас - вспоминаю пару недостатков (закончил на delphi 7) -
Главное - он поощряет неопытных (и даже мидлов) разработчиков писать неправильно и небрежно. Это же так просто натыркать кнопок на форму, даблкликом создать обработчики и вуаля. В итоге все что сложнее хелловорлд превращается в кашу. Зачем создавать какие-то "домены", "провайдеры", "конверторы" если можно ткнуть в кнопку и написать обработчик прямо там...
Ну и второе - цирк с компиляцией на не своей машине. Отслеживание необходимых установленных компонентов, цирки с их установкой, лицензированием итп - напрягал. Просто взял из архива старый проект, установил delphi и собрал его - почти нереально. Веселье на несколько, как минимум, дней - гарантирован.
А так - прям ностальгия попала в глаз - столько было всего написано на нем... Сколько приятных воспоминаний. Какие удачные решения реализовывались... И как удобно это было... Кстати некоторые написанные мной на нем программы отлично работают до сих пор. Люблю дельфи как любимую "бабушку". Его нельзя не любить (до 7 версии включительно, имхо). Не скажу что delphi умер, поживет еще. Но сказать что он жив и здоров не могу.
Сейчас я просто счастлив в .нет. Для моих задач (!) - идеально.
Вообще, сторонние пакеты работают так же как и в любых других языках. Для сборки программы не обязательно ставить пакет в среду разработки. Достаточно чтобы проект видел файлы пакеты (pas/dcu). Т.е. равно так же как и везде.
Ставить пакет в среду разработки нужно только тогда, когда ты хочешь редактировать окна визуально.
Например, я всегда использовал сабмодули в git как библиотеки для программы. И следовательно, если даже сейчас взять старый проект, он вытянет все нужные библиотеки и позволит собрать проект (если не открывать дизайнер) вообще без каких-либо манипуляций.
C#' это тот же java в другой обертке. Выпущен как его альтернатива из за лицензионных трений с владельцами java. Ничего общего с Delphi не имеет, абсолютно другая среда разработки, тут даже сравнивать нечего. И всем "страдальцам" из 90 , сейчас подход в программировании поменялся, другие технологии, другие framework.
Для себя я решил, что с Delphi всё, после Borland Developer Day 2003, когда со сцены прямым текстом было сказано "Borland всегда идет по пути, намеченному Microsoft", а в D8 отказались от нативной компиляции.
Обсуждение и ссылка на отчет https://www.rsdn.org/forum/delphi/445857.flat
Embarcadero подняли флаг, но поздно, поезд ушел.
Borland\Inprise сами виноваты. После появления .net менеджмент решил конкурировать с MS на этом поле, но зачем. Потеряли время и динамику развития, закопали кучу ресурсов, при этом масштаб компаний не сравнимый. Могли бы развивать поддержку 64 битных приложений, поддержку новых API, но ударило ALM в голову и разработка продукта для программистов окончательно развалилась.
в общем - неверно
тот же VS Express это где то 2005 год. совсем бесплатные версии поздней.
К тому моменту борланд давно помер. Уже в конце 90х борланд был тупик и мертв и выбор его как платформы для корпоративного, был неоправданн.
В корпорациях иные приоритеты в софте и железе в плане поддержки и долговременности.
Так же, MS имел инфраструктуру и связную систему продуктов и глубокую интеграцию и общий интерфейс c API. Чего не было у борланда,
Или суперпродукта на котором можно жить вечно - как у оракла.
Он пытался влезть в это нишу, офисного и прочего, с quattro pro, wordperfect, paradox, dbase и еще чем то - но . не потянул, и помер. Собственно dbase (ashton tate) его добила как и смена менеджмента и прочие кидания. И куча купленных разнородных продуктов которые не взлетели, в той же конкуренции с MS и неудачном менеджменте.
Средства разработки - фигня, на этом фоне.
К моменту выпуска дельфи ~95г борланд был практически мертв, просто лапки остаточно подергивались. Все кому надо - уже знали.
Майкрософт вкладывался в поддержку продуктов едвали не больше чем в разработку. Натурально - десяток другой, тыщ людей только в редмонде, занимались только этим. И те же багфиксы информирование, удобная документация.
Собственно MSDN было прорывом и на какой то момент MS cайт с инфой - самым большим и сложным сайтом планеты, и востребованным.
Борланд близко не стоял.
Единая среда с редактором и прочим - ее все начали делать когда осознали необходимость. Но не для "душения" и просто потому что это путь развития. Как и фреймворки и визуальные интерфейсы и объекты..Для DOS это середина 80х.
В корпорациях иные приоритеты в софте и железе в плане поддержки и долговременности.
Да, и некоторые из факторов, очень важных для корпоратов, где Делфи принципально не могло предложить преимущества - возможность централизованного обновления ПО, тонкий клиент, трехзвенка вместо клиент-серверной архитектуры.
Т.е. исключительно веб?
Ну, существуют решения помимо Web, где вендор реализовал собственный тонкий клиент. Но массово сейчас только Web.
Самая быстрая JVM была от Microsoft. Но потом MS добавила поддержку OCX(ActiveX) как импорт пакетов, что сломала совместимость Java кода. За это Sun отобрали лицензию у Microsoft. В итоге пришлось делать свой язык.
Но если я правильно помню у Microsoft был инструмент прямого конвертирования Java в С#. Для первых версий языков. Т.е. С# создавался в противовес Java, а не Delphi. То что взяли грамотного архитектора языка, это большой плюс.
История жизни и развала Borland гораздо интереснее.
Взлет пришелся на линейку компиляторов Turbo: Pascal, C++, Basic. Библиотеки TurboVision и ObjectWindowsLibrary, потом VCL.
Потом неудачный выпуск Kylix и попытка выпустить Linux PowerHouse с Corel. От Borland было Quattro Pro, Paradox, Word Wizard и куча IDE.
Но насколько я помню из журнальной статьи того времени, Microsoft купила акций Corel и Borland и всё затихло.
Также была среда разработки JBuilder, лучшее что было до появления JB Idea. В ней были компоненты dbSwing, аналог DB компонент от VCL. Но развитие Java пошло по другому пути. В итоге продали Oracle как JDeveloper.
чувствуется наследие WinForms
А что он всем так не нравится? Я вот в любой день выберу лучше его, чем любой другой новомодный (или не очень) тулкит и буду чертыхаться на непредсказуемый лейаут.
Ещё со времён VCL намного проще, когда всё гвоздями прибито, а если уже очень надо можно и кодом написать ресайз.
Turbo Pascal был, конечно, мощью.
Borland против Microsoft это TurboVision/OWL против MFC. А не паскаль потив С++,C#... тут главное в стиле программирования и написании библиотек, а не языки. Как началось размывание стиля борландистов так они и сдали позиции. А размывать его стали чтобы перетянуть больше программистов с MFC, которых затягивали в .NET. Сейчас я считаю wxWidgets последним оплотом борландистов., ну и freepascal.
wxWidgets последним оплотом борландистов
Поясните .
ну я как писавший на turbovision паскале и owl на с++ считаю что wxwidgets наиболее близок к борландовскому стилю библиотек. еще я драйвера писал на NuMega DriverStudio кучу лет - там тоже правильный стиль был. А псоледний драйвера уже пришлось писать переписывать на WDF это ближе к MFC по мне... но я старался сгладить свой дискомфорт.
Нет, даже близко нет. Близко был только Winforms, который забросили.
это к какой части коммент? у меня все на чисто интуитивном уровне - когда я выбираю инструмент для работы я опираюсь на прошлый опыт. и если новый инструмент логично и легко ложится в руки, то это годнота. иначе фуфуфу. сейчас правда тяжелей стало - все новые инструменты делают специально сильно непохожими на старые чтобы сформировать новую свою экосистему, придать ей уникальность и значимость.
А, OWL... возможно, я OWL почти не пользовался (только книжку прочёл). Я думал, что вы о VCL говорите: у VCL с wxWidgets общего, имхо, весьма мало.
... использую wxWidgets совместно с современным VC, не знал, что там что-то от OWL.
Трава была зеленее, Delphi был хорош, .net - кусок г
В Tiobe за апрель 2025 Delphi/Object Pascal на 9 ом с 11 го в апреле 2024. Не сдаётся.
как говорится: умер дед Максим, да и * с ним. C# уже тоже, как я понимаю, давно лапки к верху, что теперь по этому поводу переживать? ASP.Net с этим тяжелееным IIS вообще хоть кому-то нужен был? Сдели бы норм веб сервер, может и не стало это анахронизмом бы и не нужны были фреймворки, которые там сейчас пока на плаву (на пару тройку лет)
Кстати, компонент Delphi после установки можно попробовать преобразовать
в библиотеку без установки, чтобы не устанавливать каждый раз на новом месте:
Удалить значёк компонента с формы и востановить его в объявлении типа формы как было.
Добавить в FormCreate:
имя из объявления:=тип из объявления.Create(form1);
операторы присвоения свойств и событий компонента из dfm формы.
Удалить компонент в Component\Install Packages.
При первом запуске на запрос Delphi - ignore.
Попробовал для ComPort - работает.
Фирма Microsoft, конечно, много к чему приложила свою руку. Смотрите, даже Скайп уже доживает свои последние дни. Но в случае с Delphi виновата сама Borland.
Но есть и другая сторона вопроса. В то время стали очень активно развиваться WEB-приложения. А настольная IDE нужна для настольных приложений. Например, лично мне было бы крайне удобно работать с тем же Хабром посредством полноценного нативного клиента через web-сокеты и, возможно, RSS (где-нибудь ещё используется эта технология?). И это было бы гораздо удобнее нынешней работы через web-браузер.
И ещё. Когда пришло Embatcadero, то можно было бы, действительно, создать по мотивам VCL хорошую кросс-платформенную библиотеку. Но что-то тут застопорилось. Была бы альтернатива существующим подходам и, возможно, какая-то обобщённая архитектура.
С Pascal/Delphi у меня не сложилось. Нет они не были сложными языками - просто не нравились. В C/C++ было интереснее. Когда попался в руки C++ Builder, она мне понравилась - прост, как и Visual Basic (создал форму, добавил элементы и всё), но код на C++. Но лицензия у них стоила сильно много для начинающего разработчика.
Если бы в Delphi, C++ Builder в своё время добавили кросс-платформенность и поддержку мобильных устройств, они точно были бы востребованными и сейчас. Ведь, что лучше системы, где пишешь на хорошо знакомо языке, в знакомой среде, приложения, которые можно запускать на разных устройствах.
.NET помимо универсальности лишил некоторых возможностей. Например, программы, которые писал в VS6 не получается полностью портировать на VS.NET.
>> Мы потеряли не просто инструмент. Мы потеряли целую культуру разработки.
Целую культуру разработки потеряли со смертью Clarion, а не с забвением Delphi.
Когда работал с rad студией, клепал формочки, мечтал найти работу в вебе с c#. Даже несмотря на то, что в школе был паскаль, c# куда приятнее.
Delphi - сила! Половина молодости прошло на Delphi 7. Что то серьезное писал уже лет 15 назад. Но где-то с пару лет назад обратился один медцентр, попросили написать небольшое приложение для планшетов под Android и iOS. Опыта писания под эти ОС и устройства небыло вообще, и пока изучал на чем можно сообразить наткнулся что на Delphi можно делать приложения 8-о !!! Установил её родную и Firemonkey, и руки сами вспомнили torry.net, которые оказывается еще работает. За несколько дней сделал приложение под требуемые ОС и серверную часть, сетевое все сделал на старом добром Indy. В общем вот пару лет все работает и проблем не наблюдается. Ну и был сильно впечатлен новыми возможностями, начиная от сборки под разные ОС (там и Linux и MacOS) и заканчивая всеми последними веяниями с сахаром и вебом.
Мне кажется автор немного не договаривает.
На мой взгляд, главный просчет Borland это попытка пересесть на Net. Версии Delphi 1-7 имели собственный компилятор. Генерили нативный x86 код. Что делало среду и программы на ней быстрыми, с минимум ошибок. А вот Delphi 8, она же Delphi 2006 это среда которая генерит код Net. То есть все работает через прокладку Net. И программа, и среда. Естественно все тормозило, глючило и т.п. Тоже можно сказать о следующих версия 2007, 2009. Встречал работающий проеты на Delphi XE, но это уже был продукт Embarcadero, не Borland.
А время было было упущено. Net от МС избавился от детских ошибок. Железо стало быстрее. И естественно в конкурсе на лучший Net победил Net от МС, а не Delphi.
И вся эта история мне очень напоминает случай с Nokia. Почему-то кажется, что в борланде тоже были были добрые дяди от МС, которые "помогли" выбрать такое направление.
Только Delphi 8 являлась .Net-only версией, последующие версии позволяли и нативную компиляцию, а ещё позже .Net вовсе был удалён.
Вполне возможно, некоторые тонкости уже забыты. Лично пытался что-то писать на D2006. Но, все настолько тормозило и глючило, по сравнению с D7, что просто ужас. D2007 был чуть стабильнее, но ужасно медленнее. Но, главное решение - играть на поле своего конкурента создавая вторичный продукт, это по моему полный маразм.
Net от МС избавился от детских ошибок. Железо стало быстрее. И естественно в конкурсе на лучший Net победил Net от МС, а не Delphi.
Дотнет не бывает "от мс" и "не от мс" (моно не в счет), он всегда был один и общий для всех. Дельфи компилировался в точно такие же IL сборки для рантайма от МС. Просто язык на котором человеком код пишется другой, вот и вся разница, их можно обратно декомпилировать в C# например.
А как еще назвать продукт, который полный конкурент Net, но написан поверх Net? Только Net от Борланда. Естественно победил оригинал.
Вы путаете платформу и язык программирования. Примерно как яваскрипт это конкурент гугл хрому.
А как еще назвать продукт, который полный конкурент Net, но написан поверх Net?
Он не написан поверх .Net он написан для .Net. И конкурентами были фактически среды разработки от Борланда и Visual Studio. Даже не языки потому что сишарп у Борланда тоже был.
Только Net от Борланда.
Не было никакого Net от Борланда, дельфи можно было скомпилировать в IL-сборки для запуска на Microsoft .Net Framework.
Естественно победил оригинал.
Скорее проиграл провальный менеджмент. Они умудрились сесть с ним в лужу дважды - первый когда ввязались в дотнет слишком рано когда тот был еще не слишком интересной технологией, и вряд ли отбили затраченные на это ресурсы, и второй раз - когда соскочили с него ровно когда туда завезли всяких киллер-фич вроде LinQ и EF. Возможно с дотнетом сейчас бы дельфи был не маргинальным изолированным загончиком либо для олдов с легаси либо для маленьких десктопных проектов, а куда популярнее, потому что мог бы взаимодействовать со всем остальным дотнет миром - нугетами и прочим, был бы спрос в энтерпрайзе итп.
Возможно с дотнетом сейчас бы дельфи был не маргинальным изолированным загончиком либо для олдов с легаси либо для маленьких десктопных проектов, а куда популярнее,
Рассмешили :)
Вы видели хотя бы 1 язык, успешный, который сделан поверх Net? А таких было очень много! Если есть Net, то "скрипач не нужен"(С).
Мне не совсем понятно что вы вкладываете в словосочетание "язык поверх Net". Как язык может быть поверх чего то? А так C# который "поверх Net" вполне себе успешен например. Net это платформа, на языке пишут для платформы, на выходе из ide бинарники, платформе глубоко наплевать на каком языке они были написаны. Потому формально код писать без разницы на каком языке, лишь бы компилятор был. Спецификации IL открыты и хорошо стандартизированы. Какие то энтузиасты даже пхп туда натянули. При этом вашу библиотеку смогут as is использовать в любом проекте независимо от того на каком языке вы ее написали, на C#, на бейсике или вообще напрямую байткодом в hex-редакторе.
Главный просчёт Borland был гораздо раньше, чем Net вообще был явлен миру -- когда в угоду хоть и популярному в те годы, но всё ж таки сугубо учебному языку Pascal был похоронен действительно серьёзный системный язык Modula-2.
Delphi 8 — это не Delphi 2006. D8 вышла в 2004 году и была .NET-only, в D2006 вернулись к нормальному нативному коду с возможностью компиляции в .NET (в том числе для Windows Mobile .NET). D2009 была, в общем-то, безглючной — все отладили.
То есть люди потратили деньги на выпуск глючных D8, D2006, D2007. А главное лет 5 времени. За которые конкурент развился и забрал рынок?! Так об этом я и говорю.
D8 мало кто покупал. Тогда такой хай поднялся, что нельзя нативный код получить, что мама не горюй. Потому, собственно, и отказались.
Вот. Борланд явно свернул не туда. И в попытках исправить ситуацию, потерял время, деньги, рынок. И тут собственно другой вопрос, сами такое придумали, или кто-то подсказал(проплатил)?
И тут собственно другой вопрос, сами такое придумали, или кто-то подсказал(проплатил)?
Скорее, поддались на моду. В моем окружении были те, кто очень сильно стал топить за .NET. Типа твоя программа весит 2 мегабайта, а будет весить 200 килобайт. Фрэймворк в 22 мегабайта, который пользователю нужно тянуть через диал-ап или канал с нехилой помегабайтной оплатой, — это уже за пределами сознания тех людей... Потом некоторые из них начали точно так же топить за Silverlight...
Я и сейчас, если вдруг надо будет собрать по-быстрому какую-то небольшую информационную систему с БД, табличками и графиками, возьму какую-нибудь СУБД реляционную и delphi, прости господи, версии типа 7. С использованием компонент типа DevExpress и ODAC всё за несколько часов-суток соберется в приложение. Понятно, что это я такой олдфаг и просто возьму удобный инструмент - наверняка это всё устарело и современное поколение за 500 наносек соберёт гораздо быстрее и удобнее. Или нет?
Как Microsoft задушил Delphi, создав .NET: история одного программиста и одного чемодана