Почему я перестал писать на Delphi

В этой статье я хочу ответить на один из вопросов, который мне часто задают в том числе при «живом» общении.

Почему я ушёл от разработки на Delphi и почему когда-то основной язык был исключён из стека поддерживаемых мной технологий.

На самом деле это вызвано целым рядом весьма существенных причин.

Причина 1. Ценовая политика вендора

Delphi стоит в разы дороже аналогичных решений многих своих конкурентов.

По состоянию на конец 2018 года за Delphi Professional просили 87 999 руб. (цена на официальном сайте). Для сравнения, Visual Studio Professional тогда же стоила 30 058 руб. (цена в Microsoft Store). Разница почти в 3 раза.

Полноценной бесплатной версии доступной для небольших компаний и индивидуальных разработчиков у Delphi в отличие от той же Visual Studio нет.

Официально в июле 2018 года вышла Community Edition, но у неё есть лицензионное ограничение 5 000$ в год совокупного дохода. То есть если Ваш суммарный доход (не только от Delphi программ) превышает указанную величину, вы обязаны купить коммерческую версию.

Причина 2. Востребованность

К сожалению, при всём уважении к Delphi сфера применения для него и аналогичных технологий в последние годы значительно сократилась.

Даже в Enterprise секторе, который всегда славился своей консервативностью акцент уже давно сместился в сторону мобильной и web разработки. Но, если с первой Delphi ещё может как-то справиться, то к последнему он до сих пор не готов.

Если в 2012-2013 годах Delphi программист ещё чувствовал себя на рынке вполне уверенно, то в 2018 году вакансий по Delphi на том же HeadHunter единицы.

Как это ни прискорбно, в таких условиях вложения в приобретение дорогостоящего программного пакета и поддержание знаний и навыков в актуальном состоянии просто не оправдывают себя.

Причина 3. Общее отставание от современных трендов

Процесс разработки на Delphi не менялся уже очень много лет.

Целый ряд технологий в Delphi доступен в лучшем случае в виде библиотек от сторонних производителей, которые также часто далеко не бесплатные.

Печально. Но в Delphi до сих пор нет полной поддержки ООП (хотя бы вследствие ограничений, связанных с интерфейсами).

Как минимум частично исправить ситуацию должна была библиотека FireMonkey. Только она длительный период времени была довольно «сырой» и по ряду своих возможностей ещё уступает «ветерану» корпоративного ПО – VCL. Поэтому, сделать чтобы выглядело красиво – это FMX, а сделать так чтобы работало эффективно – это пока ещё VCL.

Как следствие всего вышеизложенного снижение производительности у программиста и нередко ухудшение качества ПО. Конечно, если речь не идёт о задачах, которые легко решаются по принципу «накидать компонентов на форму».

Причина 4. Неблагоприятные условия на рынке

В силу ряда причин Delphi программистов пока ещё достаточно много, но, как уже говорилось выше, вакансий для них наоборот крайне мало. Поэтому очень редко кто из Delphi разработчиков сейчас в той или иной степени не сталкивается со всеми «прелестями» так называемого «рынка покупателя».

Конечно, даже в такой ситуации найти вакансию или проект на Delphi вполне возможно. Только каковы будут условия?

Резюме

Как это ни печально, но все вышеизложенные причины привели меня к одному (в прочем вполне закономерному) следствию. Писать на Delphi в настоящее время:

  • Практически бесперспективное занятие в плане опыта и карьеры;
  • Просто не выгодно по деньгам.

Это и заставило меня перейти с Delphi на альтернативные технологии и в 2017 году я полностью прекратил разработку на этом языке программирования.

Ничего личного. Просто работа.

Искренне надеюсь, что эта статья в достаточной степени разъяснит основания для принятия мной такого решения.

4 комментария

  1. Возможно и зря. Пройдет время и delphi опять будет в моде. Как фортран.
    По поводу FireMonkey — я правильно понимаю что из-за кросплатформенности все функции отличаются? В частности программирование под Mak к примеру. Платформы же разную структуру имеют (в частности папок) и т.д. WinAPI уже тоже не заюзать?

    1. Пройдет время и delphi опять будет в моде. Как фортран.

      Дело здесь не в моде, а в сочетании целого ряда факторов, о которых я писал в статье.
      К слову, у Delphi несколько лет назад уже был всплеск популярности после длительного спада. Но, он быстро прошёл и сменился даже ещё большим спадом, т.к. внедрения только технических новшеств (той же кроссплатформы) оказалось недостаточно, чтобы в корне изменить ситуацию.

      Посмотрим, что будет дальше, но пока предпосылок для роста популярности Delphi что-то не заметно.

      я правильно понимаю что из-за кросплатформенности все функции отличаются?

      В любой кроссплатфоменной технологии отличия касаются в основном операций специфичных для той или иной платформы. Например, сохранение файлов в Android имеет свои особенности, а WinAPI будет работать только под Windows. В остальных случаях всё везде одинаково. Только вот обойтись без, так называемых, платформозависимых API получается не всегда.

      P.S. Впервые слышу о популярности Фортрана.

  2. Например, сохранение файлов в Android имеет свои особенности, а WinAPI будет работать только под Windows

    Так я об этом и спрашивал. Как решается такая проблема? Есть какая то универсальная функция? Или фактически мне нужно переписывать под каждую ОС весь код если я много работаю с ОС, папками, записью файлов и т.д.?

    1. Данная проблема решается при помощи условной компиляции, когда в зависимости от платформы в программу включаются те или иные альтернативные наборы операторов.

      С её помощью можно сделать кросплатформенным очень многое (если не всё), но общий объём кода будет увеличиваться пропорционально числу поддерживаемых платформ. Как-то так.

Добавить комментарий для Devvver Отменить ответ

Ваш e-mail не будет опубликован. Обязательные поля помечены *