Думаю, немного потроллить на тему.
Кто не согласен - выходи, подерёмся.
"Фу бля, крохобор вонючий" (с) Svart Testare
Неактивен
DonDublon3, я, конечно, полный ламер во всех программерских делах, но мне серьёзно интересно, почему Delphi мёртв. По-моему, на втором курсе университета как раз на нём мы изучали основы программирования (Delphi 6), и тогда он мне казался удобным и понятным, да ещё и GUI приложения хорошие получались
https://nolinux.w2c.ru - море баттхерта и деаонимизации
Неактивен
Может просто из-за того, что Borland'а нет, а так Delphi живёт в Embarcadero® Delphi® XE2. Сам недавно узнал, что уже и CodeGear нету. То есть язык обновляется, как и среда разработки. Поддерживается разработка софта под различные платформы, включая Android и облачные сервисы.
Редактировался Тайный хранитель (18-01-12 19:52:51)
Кто на человека говорит или учит говорить антоним слова умный, тому от Христа Врача и Бога в ответ: ”сам такой”.
Неактивен
Delphi метрв!
Разве?
https://www.embarcadero.com/ru/products/delphi
Может все таки только Borland Dephi ?
Нет, так мы целей гнусных не достигнем... / В.П. Вишневский
Неактивен
А я согласен с топикстартером. Delphi умер:
Borland Delphi. И не умер а лишь был продан.
Нет, так мы целей гнусных не достигнем... / В.П. Вишневский
Неактивен
Я вот одного не могу понять, на кой хер и потребовался велоcипед, если Delphi 8 уже работал с .Net?
Под .NET запилили отдельный продукт - Prism. А в Delphi вроде как просто кроссплатформенную библиотеку для GUI сделали.
Windows == УМВР
Неактивен
Думаю, немного потроллить на тему.
Кто не согласен - выходи, подерёмся.
"Дорогой самодержец, мы пропали" "Как пропали?"
В одной из соседних веток Saturn абсолютно аналогично утверждает, что Linux готов для домашнего использования и рабочих ПК большинства предприятий. Обоснованиями троллить надо, а не безосновательными вбросами.
Для Director-cemetery: Пока не почешетесь извиниться, Ваши комментарии буду игнорировать.
Для Rector: В дальнейшем буду Вас просто игнорировать.
Неактивен
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 ). Оставшаяся треть - видимо, состоит из идейных фанатов и мазохистов.
"Фу бля, крохобор вонючий" (с) Svart Testare
Неактивен
Я считаю, что Delphi - какашка и он достоин смерти. Я ненавижу Delphi. Я не понимаю, как будучи трезвым человеком можно выбирать Delphi для программирования.
Почему Delphi не умрет в ближайшие 20 лет:
1) куча legacy-кода
2) низкий порог вхождения
3) инерционность
И это еще банальный C#, т.е. язык кагбэ не функциональный.
Исходя из каких свойств языка программирования его можно считать функциональным?
Неактивен
1.2 ... 1.6
Другими словами: "мне так не нравиться, значит это неправильно", так?
IDE показывает ошибки (в project explorer и красным подчеркиванием кода), но код правилен и компилируется.
Есть такой косяк , но там дело в криво работающем автоматическом добавлении модулей в uses, а это совсем не "не поддерживает свой же документированый синтаксис".
Сторонние библиотеки. Большинство API заточены по С\С++.
А что с ними за проблема?
Можно, например, вызвать метод несуществующего объекта
Ну так хорошо же! Это ж почти как делить на ноль, и Delphi это может!
Сборка мусора
Никогда не понимал зачем она нужна в Delphi.
Windows == УМВР
Неактивен
DonDublon3 пишет:
1.2 ... 1.6
Другими словами: "мне так не нравиться, значит это неправильно", так?
Конечно. Я же знаешь, кто? Я - программист! То есть пользователь для языка программирования. Мое мнение - и есть правильное.
Есть определенные стандарты юзабилити, которые все нормальные люди (microsoft, sun, digiral mars и т.д.) соблюдают. Потому что так захотели программисты. Эти стандарты тоже появились не просто так, они базируются на том, что компьютер должен делать то, с чем нормально справляется (автоматический вывод переменных и сигнатуры лямбд).
Есть такой косяк, но там дело в криво работающем автоматическом добавлении модулей в uses, а это совсем не "не поддерживает свой же документированый синтаксис".
Ну а как это назвать-то? Если он криво читает модули со своим синтаксисом - это и значит, что не поддерживает свой синтаксис.
А что с ними за проблема?
Как в чем? Хочу из дельфей использовать функционал, а он под С. Только не надо мне про автоматические конвертеры h в pas, ничего хоть немного сложного они не могут конвертировать.
Ну так хорошо же! Это ж почти как делить на ноль, и Delphi это может!
Ага. А потом дооооолго будешь искать, как ты туда попал ))
Никогда не понимал зачем она нужна в Delphi.
Ну видимо, затем же, зачем и в любом другом языке.
"Фу бля, крохобор вонючий" (с) Svart Testare
Неактивен
Сборка мусора это вообще к языку не относится.
Неактивен
Я - программист! То есть пользователь для языка программирования. Мое мнение - и есть правильное
Но ведь не единственный пользователь. У других могут быть другие мнения.
Если он криво читает модули со своим синтаксисом
Читает то хорошо, когда видит, проблема как раз в том что видит не сразу.
Только не надо мне про автоматические конвертеры h в pas
И не собираюсь, все эти конвертеры - та ещё хуйня. Но ничто не мешает переписать .h в .pas самому. С самими то библиотеками проблем нет.
затем же, зачем и в любом другом языке.
Не знаю как в любых_других, но Delphi предоставляет достаточно возможностей для написания кода, который вообще не будет создавать никакого мусора.
Редактировался shell32 (19-01-12 14:48:34)
Windows == УМВР
Неактивен
Но ведь не единственный пользователь. У других могут быть другие мнения.
Резонно. Но почему-то солидные производители языков и программисты думают, как я, а не по другому. А от delphi-style все плюются.
И не собираюсь, все эти конвертеры - та ещё хуйня. Но ничто не мешает переписать .h в .pas самому. С самими то библиотеками проблем нет.
Ну во-первых, есть такая штука, как просто программа на С в исходниках, полно такого. Ну и опять же, время, которое мне никто не даст. Ну и ваще КАКОГО ХРЕНА БЕДНЫЙ Я ЧТО-ТО ДОЛЖЕН ПИСАТЬ САМ КОГДА У ДРУГИХ УЖЕ ВСЕ ЕСТЬ ГОТОВОЕ БЕРИ И ПОДРУБАЙ? Ковырять внутренности dll-ок, или сами исходники. Ну песец ведь.
Не знаю как в любых_других, но Delphi предоставляет достаточно возможностей для написания кода, который вообще не будет создавать никакого мусора.
Ога. Это ВСЁ оборачивать в интерфейсы? Та еще гора писанины, спасибо.
Кроме того, в этом случае нужно уделять внимание тому, чтобы не пытаться объект убить дважды. Лишняя головная боль.
Добавлено спустя 06 мин 47 с:
Сборка мусора это вообще к языку не относится.
Вы часом не преподаватель? Придираетесь ко всякой хрени.
Не относится, если понимать язык как один только синтаксис, сборка мусора относится к стандартной библиотеке, которая обычно рассматривается вместе с языком.
Добавлено спустя 08 мин 06 с:
Я не понимаю, как будучи трезвым человеком можно выбирать Delphi для программирования.
У нас в конторе реально очень много на delphi. Так и мучаюсь.
Редактировался DonDublon3 (19-01-12 16:11:44)
"Фу бля, крохобор вонючий" (с) Svart Testare
Неактивен
Кроме того, в этом случае нужно уделять внимание тому, чтобы не пытаться объект убить дважды. Лишняя головная боль.
Что это значит - "не пытаться объект убить дважды"?
Windows == УМВР
Неактивен
Delphi будет жить, причём Borland так же как и живы Office 2003, Mathlab 2001 и прочий софт, который использует в преподавательской среде.
Embarcadero только продлит агонию, но мне кажется, что это среда нормально поставится на 7, в отличии от Borland'а и тем она выручит.
Редактировался Тайный хранитель (19-01-12 18:43:45)
Кто на человека говорит или учит говорить антоним слова умный, тому от Христа Врача и Бога в ответ: ”сам такой”.
Неактивен
Сборка мусора это вообще к языку не относится.
X не относится к языку программирования, если структура и алгоритмы программы без Х не меняются. Убери сборщик мусора и программы на Java с C# будут выглядеть по-другому. К тому же сборщик мусора приподносится как фича языка программирования самими создателями.
Вот среда разработки - хороший пример того, без чего язык может существовать.
Неактивен
С каких это пор, дельфи - функциональный, а шарп - менее функциональный?С каких это пор, в дельфи вообще есть функциональное программироване?
Неактивен
Что это значит - "не пытаться объект убить дважды"?
например, убийство объекта может осуществляться через стандартную сборку мусора (через интерфейс), и на VCL-ное убиение (когда этим заведует Owner). При этом даже толком не получается проверит объект на nil, потому что указатель живет. Получается довольно трудноразрешимый Access Violation.
И это не единственная ситуация.
Добавлено спустя 02 мин 36 с:
С каких это пор, дельфи - функциональный, а шарп - менее функциональный?С каких это пор, в дельфи вообще есть функциональное программироване?
А кто говорил, что Delphi - функциональный?
Насчет шарпа - млин, ну мы что, будем спорить что ли, какой более функциональный - C# или F# ? C# - императивный язык с функциональными плюшками.
"Фу бля, крохобор вонючий" (с) Svart Testare
Неактивен
pavel2403, так всё-таки
после 10 мин работы твоей проги она вылетает с Out of memory
или
любой язык, кроме Java, который поддерживает процедурное программирование это мог еще так лет ...цать назад
???
убийство объекта может осуществляться через стандартную сборку мусора (через интерфейс), и на VCL-ное убиение (когда этим заведует Owner)
А зачем реализовывать убийство объекта через интерфейс, когда он и так будет убит Owner-ом? Может косяк в чьих-то алгоритмах, а не в языке, а?
Редактировался shell32 (20-01-12 08:58:48)
Windows == УМВР
Неактивен
Хех, ну начнем с того, что можно вызвать метод несуществующего объекта в любом языке. Не думаю, что это такая уж большая проблема. Просто я немного не понимаю, как можно вызвать метод несуществующего обьекта, если его экземпляо еще не создан???
Нихрена подобного. В C# нельзя. Уверен, что в Яве тоже (хотя не проверял). А в Дельфях можно, если постараться. Более того, там можно проделать такую фишку, как подмена self внутри метода. Конечно, кто такое сделает - сам себе злобный буратино, но язык позволяет такие небезопасные вещи.
А что обертка интерфейса освобождает программиста от обязанности освобождать память после работы с екземпляром класса в языке где нет сборщика мусора???
Какая-то путаная фраза. В дельфях сборка мусора есть, довольно убогая и через интерфейсы. Т.е. речь о другом языке? Но в других языках и сборка мусора по-другому устроена.
Кстати убивать экземпляр можно сколько угодно раз,
Смотря что считать убиванием. Если вызов Destroy, то нет.
в моем коде сборщику мусора делать практически нечего.
Вы в курсе про паттерн "фабрика"? Для большой сложной системы обычным является, когда объект порождается, передается каким-то обработчикам, и породитель в принципе не может отследить, когда его надо убить.
Добавлено спустя 22 мин 44 с:
А зачем реализовывать убийство объекта через интерфейс, когда он и так будет убит Owner-ом? Может косяк в чьих-то алгоритмах, а не в языке, а?
Это действительно ошибка. Спасибо, кэп.
От ошибок никто не застрахован. Хорошее средство (для всего, не только для программирования) делает так, что человек совершает меньше ошибок, перехватывая более легкие на более ранних этапах, а также помогает определить причину ошибки. В C# и Java вы Access Violation хрен получите. А в Delphi - одна эта ошибка на 100500 ситуаций.
Редактировался DonDublon3 (20-01-12 09:37:24)
"Фу бля, крохобор вонючий" (с) Svart Testare
Неактивен