Комментарии 57
Статья не более чем толстенный пиар подыхающего языка и платной (очень недешёвой) инфраструктуры, завязанной на него, преимуществ у которой по сравнению с альтернативными решениями просто нет.
Я так понимаю, аргументация типа Skype и Total Commander написанный на Delphi уже мало кого вставляет? Автор статьи решил тяжёлую артилерию в бой кинуть?
На том же С и C++, который хоронят не меньше, вот вам пачка довольно свежих и на порядок более сложных по сравненнию с какой-то там CAD-системой проектов, которые на слуху у общественности: Chromium, Chrome OS, Firefox OS, а ещё всякие другие менее известные мобильные операционные системы, всякие Node.js, Nginx и пр. — по сути до его распространённости он впереди планеты всей… Хотелось бы что-то подобное, что у всех на слуху услышать, а то из спора в спор всё одни и те же Skype и Total Commander перетекают, вот ещё какая-то CAD система появилась — теперь её приводить будут :)
Если зомби всё ещё шевелится, это не значит, что он на самом деле живой.
P.S. «c какой-то там CAD-системой» — не зря сказано — я в теме и сам работал над промышленной коммерческой CAD системой (первая работа), поэтому понимаю, что практически любая CAD гораздо проще по своей реализации, чем например браузер. В CAD меньше внешних неизвестных или плавающих факторов, хотя математика и физика (например конечно-элементный анализ какой-нибудь) там может быть гораздо сложнее. Но это уже математика и физика, имеющая к языку программирования очень опосредованное отношение.
Сколько бы он не был бы полным по Тьюрингу (как и ассемблер прям :) ), для коммерческой разработки, на которую вы так напирали выше, необходимы и другие преимущества: распространённость и популярность сегодня (чтобы легко можно было найти специалистов), распространённость под различные платформы, наличие широкого комьюнити и широкого набора инструментов. Тот же C# на голову обгоняет Delphi по всем параметрам. Я уже не говорю про всякие С++ и Java.
Кроме отсутствия необходимости переписать говнокод, наработанный за годы, других преимуществ у Delphi просто нет. В лучшем случае он где-то не хуже. Но это «где-то» исчезающе мало.
Привет из 2018 года :) Delphi продолжает жить. Появилась кросс-компиляция в Win32/64, MacOS и Linux (последний правда без GUI), также можно клепать iOS и Android приложения. Хотя все по-прежнему уверены, что язык мертв.
Привет из 2021 =). Уже несколько лет есть Community версия. Улучшают среду. Запилили Python4Delphi. Запилили LSP для анализатора. Одни из первых добавили поддержку компиляции под Apple M1. GUI для Linux тоже запилили и всё это может работать и в WSL. Из коробки есть возможность строить 3D сцену. Имеются два коммерческих фреймворка для написания веб-приложений на Делфи (TMS, uniGUI).
Хотя все по-прежнему уверены, что язык мертв.
:-)
Мы его по-прежнему используем, в паре больших проектов (по 1.5 млн строк каждый, частично правда пересекаются по общим модулям). Сейчас живем на версии 10.4.1, но думаю мигрируем на 11, как только она устаканится и компоненты подтянутся. Переписывать эти проекты целиком на новом языке слишком накладно, поэтому развиваем их на Delphi.
Касательно мёртвости, к сожалению ПОКА ЕЩЕ Delphi все-таки скорее мёртв, чем жив, потому что во-первых, сложно искать разработчиков — их практически нет (кроме старых, которые еще с Delphi 7 никак не перейдут), а во-вторых, потому что начинать новый проект, особенно если он Web или Mobile все хотят на популярных Open-Source решениях, а не на непонятных фреймворках от Embarcadero, в которых постоянно будут сложности и баги, для которых даже на StackOverflow решений не найдешь, слишком уж они мало распространены.
Т.е. всё-таки сейчас проблема Delphi — это почти полное отсутствие нормального IT-Community вокруг этой среды разработки. А сам язык и IDE достаточно хороши и современны.
Ничего не знаю. У меня 4 чата в телеге по Delphi/Lazarus/Pascal. В которых состоят и MVP Embarcadero, известные люди и разработчики крупных проектов (например, FastReport). А с разработчиками FMX можем решить или обсудить проблему фреймворка без проблем. Да, молодежь сейчас не особо смотрит в сторону Delphi, потому что не понимает на что он способен и видят Делфи - как просто какой-то Паскаль, в котором они ничего путного не делали при обучении.
В то время как расцветает демонстрация "простоты разработки" на питоне с красивым монтажем и современными IDE. Там всё красиво да ладно. Но сути ни кто не видит. Любой "простой" код на питоне - это библиотека, написанная уже кем-то, а в её недрах DLL/SO/A, написанная на другом языке.
Так или иначе, пусть и молодежи нет, мы собираем сообщество в кучу. Публикуем информацию, примеры. Все собственные проекты я вывожу в опенсорс на гит. Комьюнити восстанавливается потихоньку. Но конечно, та яма в 2005-2013 без следа не прошла.
Но Вас, как одного из представителей я хочу спросить:
Откуда у вас (холиварщиков) эта психологическая травма? Вам в детстве делфи жизнь сломал? Когда и при каких обстоятельствах Вы почувствовали что делфи это мировое зло? Вы пробовали говорить на эту тему с психологами?
Вы реально пишете на нём потому что видите какие-то преимущества (блин, ну вот какие?) по сравнению с другими технологиями или у приверженцев Delphi просто мозгов не хватает изучить что-то другое? А может просто нравится?
Изначально я просто упомянул не менее крупные, но более известные (и что называется «на слуху») проекты, написанные на других технологиях. Просто для создания баланса тяжести маркетингового вброса, созданной этой статьёй.
Для делфистов же просто мнение о смерти как виагра для старпёра: «Нет язык не мёртв — это вы его постоянно закапываете!»
готовый костьми лечь, чтобы доказать что делфи это наше всёЯ ничего никому не доказываю. Я спрашиваю почему вы приходите на хаб Delphi, и всем доказываете. Это вроде не хаб C\C++, и что делфи круче, а остальное мастдай — я не говорил. Так что в данный момент вы готовы лечь костьми, чтобы наставить читателей хаба Delphi на путь истинный.
Ну а мне всего лишь интересно, почему вы это делаете с таким упорством, как будто вам на мозоль жизни наступили. Выглядит как психологическая травма с детства, ей богу.
А если серьёзно, я просто очень сильно интересуюсь IT, у меня есть определённое представлени и критическое отношение к тому, что я знаю, поэтому я всегда готов узнать что-то новое или изменить в своём понимании что-то старое. Да, с моей точки зрения Delphi постепенно должен уйти на антесоли истории, потому что это просто ещё одна сущность, которая не даёт преимуществ, а только вносит сумятицу и без того огромный стек технологий. Но это я так считаю и нашёл для себя вполне нормальные обоснования этому.
Но может я неправ? И я прихожу в блог Delphi, где надеюсь встретить профессионалов, которые мне объяснят, в чём я неправ. Но всё развивается всегда по одному и тому же сценарию (лучший сценарий): я спрашиваю, мне отвечают, я уточняю, мне отвечают, я уточняю моменты, в которых я вижу проблему в надежде, что я просто что-то не знаю или не понимаю, человек видно не может ничего ответить по существу и максисмум что делает — отвечает пространными фразами (ну типа «это решаемо», «язык обладает полнотой по Тьюрингу» и пр. теоретические выкладки), кидается приколами типа «забанили в Google» и пр. Результат: ответа на вопрос я не получил, меня объявили тролем :)
Это что касается общего…
В данном случае не так. Статья просто кишит маркетинговым посылом какая Delphi классная и смотрите какой проект на ней можно забабахать. При этом это не преимущества Delphi, это просто ещё один проект, который мог быть сделан на чём угодно. Я просто компенсировал тяжесть маркетингового вброса, приведя примеры других проектов, «случайно» написав, что язык скорее мёртв, чем жив.
А делфисты возбудились не на то, что есть другие более масштабные продукты (ну а как же критическое мышление? не, не слышали?), а то что я (акстись!) опять похоронил любимый генератор началов и концов.
И да, я не могу считать живым язык, на котором пишут скорее по привычке и инерции, на котором не было ни одного нового большого проекта за последние 5-6 лет (при том, что в IT 2 года — считай новая эра) и который подходит разве что для поддержания накопленного говнокода.
Готов изменить своё мнение, но пока фактов и аргументов нет, кроме как доставания с антресолей проектов в лучшем случае из первой половины 2000-х с криками: «Мы ещё живы!»
А ещё можно попросить назвать реально крупный и реально новый проект на, не знаю, php. И если не назовут — то говорить, что php умер. А если назовут, то говорить, что он не крупный, или что программист кроме php ничего не знает.
Интересно прочесть подобный пост от разработчиков FL Studio.
Целью данной статьи ни в кой мере не является продвижение или рекламирование Altium Designer
…
Мы проведем своего рода экскурсию вглубь проекта и познакомимся с особенностями его реализации в контексте сложности задачи и масштаба реализации.
По факту получилась стандартная маркетинговая жвачка чуть приправленная вымученными «сколько у вас пунктов меню? а окошек?
Где же обещанные «вглубь» и «особенности реализации»?
И да, тоже интересует какой же язык выбрали в качестве «быстрого».
да?? то есть если например написать браузер целиком на плюсах, а потом на руби при одинаковых временных рамках, то его скорость будет одинакова? то есть ты вот так утверждаешь??
Согласен. Правда шибко большим умом я не отличаюсь. поэтому взял дельфийский код из эпичного треда forums.embarcadero.com/thread.jspa?threadID=74930 и перевел на java script gist.github.com/jack128/7983236
в результате на моей машине delphi xe4 (32bit релиз) 1,8sec
node v0.10.23 — 1,069sec
Я согласен, в Делфи есть свои узкие места, я их обычно обхожу написанием библиотеки на C/C++ с нужным мне функционалом, но в целом язык не на столько медленный, чтобы вот так взять и переписывать гигантские проекты на другой.
Я сам бывал в подобной ситуации: есть в программе функционал, смотрю на него и понимаю, что быстрее уже не сделаешь, а тут мне один из пользователей говорит, что у конкурентов такой же функционал работает в 2 раза быстрее (программа на C#). Смотрю — действительно так. Начинаю оптимизировать свой код и знаете что? — всегда мне удавалось оптимизировать его до аналогичной либо большей скорости выполнения. А вот такого, что из-за Делфи все очень медленно работает и ничего с этим не поделать на моей практике еще не было.
Так что если будут переписывать те же люди, что делали изначальный продукт, то ожидать значительного ускорения работы программ не стоит.
А теперь почему то начинаешь сравнивать свой код и код каких то программистов на C#.
Я вообще не знаю, как можно не понимать простой вещи. Если пишут ПО люди равной квалификации, то как раз наоборот, единственное от чего зависит скорость результирующего продукта — это язык/компилятор.
Если пишут ПО люди равной квалификации, то как раз наоборот, единственное от чего зависит скорость результирующего продукта — это язык/компилятор.
Это да, но если код изначально плохо оптимизирован, то смена языка программирования не даст значительного прироста в скорости. Потому я и написал «ожидать значительного ускорения работы программ не стоит». А причина так плохо о программистах думать у меня та, что они решили полностью переписать все программы (если это действительно правда), а не только узкие места. Знаю я таких горе программистов, у них все виноваты: тугие компьютеры, криворукие пользователи, тормозная Делфи, но только не они.
смена языка программирования при плохом исходном коде даст ровно тоже ускорение, что и имена оного при хорошем коде. Если язык/компилятор дает хреновый маш. код для пузырьковой сортировки, то и для quicksort он выдаст хреновый маш. код.
Ну вот например, классический пример в холиварах C vs C++ ideone.com/E5JDWq.
ВНЕЗАПНО разница от смены языка программирования в три с гаком раза. Хотя конечно можно сказать, что «три раза» — это не значительная разница. Причем тут компилятор даже один и тот же, прирост обусловлен только языком.
Вроде и на плюсах, и на джаве скрипте приводил примеры — и все равно не помогает. Да уж. Оптимизируют алгоритмы не потому что смена ЯП помогает или не помогает, а потому что сама по себе смена ЯП стоит времени и денег, больших чем оптимизация алго.
Вроде простая мысль же. Если на выходе компилятора быстрый код, значит вероятность что тебе придется этот код оптимизировать меньше. А оптимизация — это очень часто скатывание в говнокод, повышенная вероятность ошибок и тд.
Вроде простая мысль же. Если на выходе компилятора быстрый код, значит вероятность что тебе придется этот код оптимизировать меньше.
Два слова: «единичные случаи». Можете привести больше примеров доминирование одного языка программирования по скорости над другим, хотя бы десяток? А если я приведу диаметрально противоположные примеры для тех же языков, то что это значит?
К решению проблемы нужно подходить с умом. Пример: машина однозначно быстрее за велосипед, но в то же время велосипед легко обойдёт автомобиль в плотном трафике, потому есть смысл использовать как один, так и другой вид транспорта в зависимости от ситуации.
Вы думаете, что я не понимаю простых вещей, но это вы не понимаете меня и то, что я пытаюсь вам сказать. Если выкидывать слова из контекста, то конечно же я не прав, но что именно в моём первом сообщении не правда? Вы хотите сказать, что:
1. Смена языка однозначно значительно ускорит программу? Вы на 100% уверены?
2. Скорость работы программы не зависит от программиста? Да это даже смешно обсуждать.
А оптимизация — это очень часто скатывание в говнокод, повышенная вероятность ошибок и тд.
А это уже однозначно зависит от программиста и больше не от чего другого. У одних и с первого раза нормальный код не получается, а другие внеся десятки изменений умудряются получить чистый и читаемый код.
Да любой код на плюсах с шаблонами _всегда_ быстрее по сравнению с кодом на дельфи с виртуальными методами/указателями на функцию. Как частный случай — это лямбды.
Смена языка однозначно значительно ускорит программу?
смотря как это язык выбирать.
Скорость работы программы не зависит от программиста?
Я вроде с этим и не спорил. Я со вторым утверждением спорил. Что скорость программы при прочих равных не зависит от ЯП. Зависит. И очень сильно зависит.
А оптимизация — это очень часто скатывание в говнокод, повышенная вероятность ошибок и тд.
А это уже однозначно зависит от программиста и больше не от чего другого. У одних и с первого раза нормальный код не получается, а другие внеся десятки изменений умудряются получить чистый и читаемый код.
Угу, только проблема в том, что таких идеальных программистов нету в реальной жизни. А если вспомнить, что обычно чем быстрее алгоритм, тем он сложнее…
Да любой код на плюсах с шаблонами _всегда_ быстрее по сравнению с кодом на дельфи с виртуальными методами/указателями на функцию. Как частный случай — это лямбды.
В Делфи тоже есть подобие шаблонов, называется оно только по другому — дженерики. Провел эксперимент: написал 2 похожие по функционалу операции работы с шаблонными объектами, а именно запись в ассоциативный массив и чтение из ассоциативного массива. Одна программа на Делфи ( pastebin.com/Y9CGvmJ7 ), вторая на С++ ( pastebin.com/AeQmL3ux ). Обе программы скомпилированы со стандартными настройками Release конфигурации проекта. Использовались Delphi 2010 и VS 2012.
Запускаем тест.
Делфи:
Reading file speed: 63 ms.
Adding to the dictionary: 156 ms.
Dictionary reading: 109 ms.
C++:
Reading file speed: 516 ms.
Adding to the dictionary: 797 ms.
Dictionary reading: 500 ms.
И _ВНЕЗАПНО_ «всегда быстрее С++» проиграл с умопомрачительным разрывом, что доказывает, что программист в большей мере влияет на скорость работы программы чем компилятор, потому что в данном случая я просто перевел код с одного языка на другой.
Я не спорю, что можно оптимизировать С++ код и значительно его ускорить, но я очень сильно сомневаюсь, что вам удастся добиться значительно лучших результатов чем в исходном (под значительно лучшими я имею ввиду прирост в скорости хотя бы на 25%).
смотря как это язык выбирать.
Так как мы обсуждение ведем в ветке о Делфи, то давайте отталкиваться именно от Делфи. Назовите любой, который побьёт в любых тестах по скорости работы делфи код и при этом будет сопоставим с удобством разработки.
Я вроде с этим и не спорил. Я со вторым утверждением спорил. Что скорость программы при прочих равных не зависит от ЯП. Зависит. И очень сильно зависит.
А я и не говорил, что не зависит, более того она по любому зависит, по другому и быть не может.
Угу, только проблема в том, что таких идеальных программистов нету в реальной жизни. А если вспомнить, что обычно чем быстрее алгоритм, тем он сложнее…
Я никогда не видел больных раком, но это не значит, что их нету.
Ну да, в таких тестах дельфя конечно выигрывает. Рецепт прост:
вместо тестирования работы компилятора — тестируем систему ввода вывода компа. При этом в дельфи — грузим файл в память целиком за одну операцию чтения, а в плюсах — построчно. Ну всякие мелочи, типа использования в дельфе хеш-таблицы, а в плюсах — деревьев, даже и говорить стыдно.
БРАВО!!! Эмбаркодеровцы, прошу обратить внимание на xpert13, он явно достойный евангелист Дельфи.
Назовите любой, который побьёт в любых тестах по скорости работы делфи код и при этом будет сопоставим с удобством разработки.
Оригинальная постановка. Ты понимаешь, что например скорость считывания с диска гигового файла практически не зависит от ЯП и компилятора?
Я вроде с этим и не спорил. Я со вторым утверждением спорил. Что скорость программы при прочих равных не зависит от ЯП. Зависит. И очень сильно зависит.
А я и не говорил, что не зависит, более того она по любому зависит, по другому и быть не может.
Еще раз процитирую
Так что если будут переписывать те же люди, что делали изначальный продукт, то ожидать значительного ускорения работы программ не стоит.
вместо тестирования работы компилятора — тестируем систему ввода вывода компа. При этом в дельфи — грузим файл в память целиком за одну операцию чтения, а в плюсах — построчно. Ну всякие мелочи, типа использования в дельфе хеш-таблицы, а в плюсах — деревьев, даже и говорить стыдно.
не по существу?? Ну тогда гудбай.
Чтение файла можно опустить и посмотреть на замеры работы со словарём
То что код говно я знаю, потому и написал, что уверен, что его можно оптимизировать до разумных пределов. К сожалению других ассоциативных масивов на плюсах я не знаю, а то, что map не использует хеш-таблицы я честно не знал и для меня на самом деле не понятно такое решение.
Ну да ладно, предоставьте решение лучше. Вот человек заявляет, что С++ даёт ощутимые преимущества в скорости выполнения кода абсолютно во всех операциях в которых слабым звеном является сам код, но почему то рабочего примера не предоставил, а занимается только пустозвонством и оскорблениями выставляя это неопровержимыми фактами.
Кстати на Delphi в свое время многие энтузиасты писали свои проги-полезняшки, не будучи глубоко знакомыми с программированием как таковым. Как пример — всякие мониторы ИБП, мониторы температуры, вентиляторов ПК и прочее. Порог вхождения ниже, и соответственно результат получался быстрее.
Altium Designer: самое большое приложение (about 15 000 000 codelines), сделанное в Delphi