Форум StopLinux

DonDublon3, я, конечно, полный ламер во всех программерских делах, но мне серьёзно интересно, почему Delphi мёртв. По-моему, на втором курсе университета как раз на нём мы изучали основы программирования (Delphi 6), и тогда он мне казался удобным и понятным, да ещё и GUI приложения хорошие получались

Разве?
https://www.embarcadero.com/ru/products/delphi
Может все таки только Borland Dephi ?

Под .NET запилили отдельный продукт - Prism. А в Delphi вроде как просто кроссплатформенную библиотеку для GUI сделали.

2 Белая Рысь, правильно.
А теперь пошли обоснования (сорри, но следующий текст был написан мною же для другого источника, поэтому копипаста, думаю, простительна).
-------------------------------------
Для тех, кто не любит читать и хочет сразу получить ответ, на вопрос "жив или мертв Delphi" - отвечу прямо сейчас. Да, он жив, но лучше бы сдох без мучений. То, чем занимается компания Embarcadero (и, по-своему, успешно) - от этого программистам только проблемы, т.к. иначе бы был неизбежный переход на что-то поприличнее.

Итак, что ты имеем? На долгие годы язык был просто заморожен и не развивался. Я не буду уточнять временные границы этого периода, это неважно. Он капитально отстал от приличных языков, но с версии Delphi 2010 круто приподнялся по сравнению с Delphi 7.

Итак, посмотрим - что же он достиг и сравним с аналогичными достижениями других языков. В сентябре 2011 года вышла версия с поддержкой x64 (ну надо же, и 10 лет не прошло).

1. Сам язык (синтаксис).

1.1. Генерики. Наконец-то. То, что в С++, Java и C# появилось черт-те когда, теперь и у нас. В том числе - генериковские интерфейсы, типа IList. Правда, без GUID вы не сможете сделать кастинг интерфейса. А с гуидом сможете, но он все равно будет работать неправильно, потому что гуид идентифицирует только ту часть, которая IList, и у вас всегда будет IList <tmytype1> = IList<tmytype2> как бы не были различны TMyType1 и TMyType2.

1.2. Лямбда-функции. Ура, теперь и у нас. Но синтаксис лямбд таков, что вызывает лютое отвращение и убивает идею на корню.

Взгляните:
switch_something2(
     function (anfo: TMyInfo): boolean
     begin
         result := info.squareground = avalue;
     end);

Это при том, что сигнатура switch_something2 уже строго описана.
Аналог на C#:

switch_something2((info) => { return info.squareground == avalue; });

Почувствуйте разницу.
И это еще банальный C#, т.е. язык кагбэ не функциональный.
Это первое. Второе.
Просто функция и лямбда такой же сигнатуры - это очень разные вещи. Из первого легко делается второе, но не наоборот. Наоборот тоже можно, но через пляски с бубном.

Т.е. поставить на обработку Button1.OnClick лямбду вида procedure(Sender: TObject) я могу только через бубен. В C# - пожалуйста, легко и просто. (Не говоря уж о том, что там можно ставить несколько обработчиков на событие.)

1.3. Объявление переменных там, где они используются. Как принято в Паскале, сначала надо все объявить. Вы знаете, сколько времени программист проводит, прыгая между секцией var и самим кодом? Лучше вам этого не знать.

1.4. Вывод типов из объявления. Даже ни намёка. По-моему, даже в С++ нового стандарта это уже предусмотрено.

1.5. Объявление функций в одном месте, в реализация - в другом. Java и C#, не говоря о более "легких" языках, распрощались с этим, как со страшным сном. Вы знаете, сколько раз за рабочий день delphi-программист нажимает Ctrl+Shift+Up и Ctrl+Shift+Down? Лучше вам этого не знать.

1.6. Куча других косяков.

2. IDE.

2.1. Поддержка синтаксиса. Вы будете смеяться, но Delphi IDE не поддерживает свой же документированый синтаксис! Так и живем - IDE показывает ошибки (в project explorer и красным подчеркиванием кода), но код правилен и компилируется.
Детский сад, да и только.
Отдельные конструкции (типа внутренних типов с генериками) вообще вырубают набор текста в IDE.

2.2. Утечки памяти. У нас в организации имеется решение (в терминологии Visual Studio) с большим количеством проектов (около 80). При попытке compile-all IDE вырубается где-то после 30-го с Out-of-memory.

2.3. На больших файлах auto-completion стабильно отваливается. Здравствуй, notepad++.

2.4 C большим и сложным кодом Ctrl+Click иногда отваливается, и вместо объявления элемента переносит вас черт-те куда.

2.5 В документации Delphi XE заявлены namespaces. Мне заставить их работать не удалось.

2.6. Куча других мелких багов.

3. GUI.
Долгое время в Delphi господствовал VCL. Ребята поняли, что "так жить нельзя" и создали библиотеку нового поколения - FireMokney, по общим принципам схожую с микрософтовским WPF. Но до стройности, логичности и продуманности WPF ей - как до Китая раком. Попробуйте создать в FireMonkey в design-time свой TMyListItem, наследник стандартного TListItem. А я посмотрю и посмеюсь.

Кроме того, FM официально не совместима с VCL. Хотя народные умельцы уже сделали свою интеграцию "на коленке", а компания RemObjects, известная своими продуктами для совместимости Delphi с нужными вещами, даже обещает сделать цивильную интеграцию.
Внимание, вопрос: если в старых VCL-программах использовать FM нельзя, а новые проекты стартовать на Delphi будет только идиот, зачем тогда вообще FM? Как мертвому припарки.

4. Подключение сторонних библиотек и компонентов.

4.1. Компоненты Delphi по-прежнему компилируются строго под одну версию. Переходите на новую? Перекомпилируйте компоненты. Нет исходников? Отказывайтесь или от компонентов, или от перехода. Кошмар наяву.

4.2. Сторонние библиотеки. Большинство API заточены по С\С++. Для динамической линковки народ компилирует биндинги для C#\Java\Python. Delphi-сты - умойтесь слезами.

Итог: интероперабельность - ниже плинтуса.

5. Небезопасность и работа с памятью.

5.1. У вас есть одна-единственнная ошибка на практически все случаи жизни - Access Violation. Можно, например, вызвать метод несуществующего объекта. Вы можете возразить: "А в С\С++ тоже небезопасно." Правильно. Именно поэтому С\С++ неизбежно оказался вытесненным в область низкоуровневого\системного\высокопроизводительного программирования. Delphi же претендует на другую область - там, где сейчас господствуют высокоуровневые языки, скрипты, GUI и тонкие клиенты.
5.2. Сборка мусора, которая с помощью костылей реализована даже в С++ и вполне цивильно реализована в C#\Java\D, отсутствует. (Да, я в курсе про интерфейсы и сборку мусора как побочный эффект от их использования.) Итог - пока ваши конкуренты делают нужные пользовалям алгоритмы, вы соображаете, почему ваши компоненты как-то не так (не в том порядке) убиваются.

Итог:
Два их трех программистов на Delphi мечтают сменить язык ( https://www.peeep.us/f310eddb ). Оставшаяся треть - видимо, состоит из идейных фанатов и мазохистов.

Другими словами: "мне так не нравиться, значит это неправильно", так?

Есть такой косяк  , но там дело в криво работающем автоматическом добавлении модулей в uses, а это совсем не "не поддерживает свой же документированый синтаксис".

А что с ними за проблема?

Ну так хорошо же! Это ж почти как делить на ноль, и Delphi это может! 

Никогда не понимал зачем она нужна в Delphi.

Сборка мусора это вообще к языку не относится.

Резонно. Но почему-то солидные производители языков  и программисты думают, как я, а не по другому. А от delphi-style все плюются.

Ну во-первых, есть такая штука, как просто программа на С в исходниках, полно такого. Ну и опять же, время, которое мне никто не даст. Ну и ваще КАКОГО ХРЕНА БЕДНЫЙ Я ЧТО-ТО ДОЛЖЕН ПИСАТЬ САМ КОГДА У ДРУГИХ УЖЕ ВСЕ ЕСТЬ ГОТОВОЕ БЕРИ И ПОДРУБАЙ? Ковырять внутренности dll-ок, или сами исходники. Ну песец ведь.

Ога. Это ВСЁ оборачивать в интерфейсы? Та еще гора писанины, спасибо.
Кроме того, в этом случае нужно уделять внимание тому, чтобы не пытаться объект убить дважды. Лишняя головная боль.

Добавлено спустя 06 мин 47 с:

Вы часом не преподаватель? Придираетесь ко всякой хрени.
Не относится, если понимать язык как один только синтаксис, сборка мусора относится к стандартной библиотеке, которая обычно рассматривается вместе с языком.

Добавлено спустя 08 мин 06 с:

У нас в конторе реально очень много на delphi. Так и мучаюсь.

Редактировался DonDublon3 (19-01-12 16:11:44)

Delphi будет жить, причём Borland так же как и живы Office 2003, Mathlab 2001 и прочий софт, который использует в преподавательской среде.
Embarcadero только продлит агонию, но мне кажется, что это среда нормально поставится на 7, в отличии от Borland'а и тем она  выручит.

Редактировался Тайный хранитель (19-01-12 18:43:45)

С каких это пор, дельфи - функциональный, а шарп - менее функциональный?С каких это пор, в дельфи вообще есть функциональное программироване?

pavel2403, так всё-таки

или

???

А зачем реализовывать убийство объекта через интерфейс, когда он и так будет убит Owner-ом? Может косяк в чьих-то алгоритмах, а не в языке, а?

Редактировался shell32 (20-01-12 08:58:48)