Comments 119
Спасибо, ценная подборка.
Skiminog: Weaver — первые впечатленияМог бы и одним и тем же ником подписать, между прочим. Знаешь ведь, что это я :)
Обзор механизма естественного ввода в RAD Studio 2010 от Skiminok.
Ну это так, к слову. А подборка действительно отличная.
о боже, оно еще живо?
И даже еще где-то применяется =)
И правильно, ибо у разработчика всегда должен быть выбор. На Delphi удобно делать маленький, простенький софт, имхо.
И правильно, ибо у разработчика всегда должен быть выбор. На Delphi удобно делать маленький, простенький софт, имхо.
Skype/FruityLoops на Delphi написаны.
Вот ещё BlogJet, оказывается, на Delphi написан.
UFO just landed and posted this here
если с него перешли на что-то другое — это не значит что язык должен умереть
как визуальный разработчик виндовс приложений — дельфи еще не переплюнули в удобстве
да и глюков там поменьше будет чем во всем остальном — уж очень удобно когда надо быстро что-нибудь сваять
как визуальный разработчик виндовс приложений — дельфи еще не переплюнули в удобстве
да и глюков там поменьше будет чем во всем остальном — уж очень удобно когда надо быстро что-нибудь сваять
>>дельфи еще не переплюнули в удобстве
+
>>уж очень удобно когда надо быстро что-нибудь сваять
Согласен.
>>и глюков там поменьше будет чем во всем остальном
А вот тут не согласен, вот прямо сейчас на одном форуме обсуждают то, что проги на делфи не запускаются на некоторых XP.
+
>>уж очень удобно когда надо быстро что-нибудь сваять
Согласен.
>>и глюков там поменьше будет чем во всем остальном
А вот тут не согласен, вот прямо сейчас на одном форуме обсуждают то, что проги на делфи не запускаются на некоторых XP.
Можно ссылку? Ни разу подобного не встречал, за все время использования Delphi.
Классный пример! В программе используется база с форматом .adb. Вот что дает Яндекс: «ADBEngine может использоваться в любом языке программирования так, как представляет собой ActiveX DLL»… Т.е. если нет нужной dll, а в программе это не проверяет — что будет? Верно — runtime error. Но виновата Delphi, верно? =))))
Если этот и правда, то это глюки в RTL — можно обойти, ежели умеючи. Ну или патча какого-нибудь дождаться.
это ошибка одного конкретного продукта ;) такой можно сделать на любом языке:)
UFO just landed and posted this here
первая мысль после прочтения заголовка. как оказывается к всеобщей печали еще живо
Некрафилы)
Как-то проходил собеседование в www.3shape.com, в киевский офис разработчиков. На тот момент у них ВСЕ было на Delphi. Из-за чего, собственно, к ним и не пошел.
Скажу больше — знаю товарищей (далеко не одного), которые умышленно идут на Delphi.
А по-подробнее можно, почему?
Можно и подробнее.
Главый довод — лёгкий старт. Все в школе учили Pascal, а Delphi лишь хорошее ему расширение, которое совсем не трудно освоить.
Далее сетуют на «легкочитаемость кода». Мол лучше написать несколько строк в стиле паскаля, когда видно все begin'ы и end'ы, чем решить ту же задачу одной длинной строкой, которую через месяц никто «вновь прочитать» не сможет. (Буквально эту фразу мне выдал один такой «делфи-сотрудник»).
Еще стоит добавить, что Pascal держится в десятке самых быстрых языков (Free Pascal, если быть точным).
Главый довод — лёгкий старт. Все в школе учили Pascal, а Delphi лишь хорошее ему расширение, которое совсем не трудно освоить.
Далее сетуют на «легкочитаемость кода». Мол лучше написать несколько строк в стиле паскаля, когда видно все begin'ы и end'ы, чем решить ту же задачу одной длинной строкой, которую через месяц никто «вновь прочитать» не сможет. (Буквально эту фразу мне выдал один такой «делфи-сотрудник»).
Еще стоит добавить, что Pascal держится в десятке самых быстрых языков (Free Pascal, если быть точным).
Знаете, я писал на делфи 2 года, и щас иногда пишу, и на счет begin-ов и end-ов это фишка для лохов-новичков, т.к. в дальнейшем это очень раздражает и только мешает, а особенно типа этого:
— end else begin
— Дастиш фантастиш одним словом.
— end else begin
— Дастиш фантастиш одним словом.
Знаете, я пишу на делфи 6 лет, и сейчас пишу, и до сих пор ни разу не раздражало. И да, на языках с сиподобным синтаксисом (а конкретно C# и C) я тоже пишу регулярно.
Как сказали бы на ЛОРе, ЧЯДНТ? :)
Как сказали бы на ЛОРе, ЧЯДНТ? :)
ты нашел в нем хвостовую рекурсию(tail recursion) или там есть замыкания(closure)? Настоящие, как в моем любимом Scheme :)
«Настоящие»? Покажите мне фальшивые замыкания, я хочу посмотреть, что это такое =)
Я знаю только про одни замыкания на свете — вот такие. (По ссылке исходник на Делфи, не поленитесь, сходите.)
По поводу хвостовой рекурсии — да, увы. Но это вы все-таки загнули, я не знаю мэйнстримного императивного языка, в котором она бы присутствовала, все-таки концепция немножко из другой области :)
Я знаю только про одни замыкания на свете — вот такие. (По ссылке исходник на Делфи, не поленитесь, сходите.)
По поводу хвостовой рекурсии — да, увы. Но это вы все-таки загнули, я не знаю мэйнстримного императивного языка, в котором она бы присутствовала, все-таки концепция немножко из другой области :)
> «Настоящие»? Покажите мне фальшивые замыкания, я хочу посмотреть, что это такое =)
PHP версий до 5.3
> Я знаю только про одни замыкания на свете — вот такие. (По ссылке исходник на Делфи, не поленитесь, сходите.)
Я все равно не пойму загромождение из кучи символов. Можно эквивалент этого на более удобном Ruby или Python?
> По поводу хвостовой рекурсии — да, увы. Но это вы все-таки загнули, я не знаю мэйнстримного императивного языка, в котором она бы присутствовала, все-таки концепция немножко из другой области :)
Из какой же?
PHP версий до 5.3
> Я знаю только про одни замыкания на свете — вот такие. (По ссылке исходник на Делфи, не поленитесь, сходите.)
Я все равно не пойму загромождение из кучи символов. Можно эквивалент этого на более удобном Ruby или Python?
> По поводу хвостовой рекурсии — да, увы. Но это вы все-таки загнули, я не знаю мэйнстримного императивного языка, в котором она бы присутствовала, все-таки концепция немножко из другой области :)
Из какой же?
> Ruby
Не владею.
> Python
Не владею.
> PHP
Не владею, и слава Богу.
Могу попробовать переписать на Scheme, но:
а) это потребует некоторое время, давно не брал его в руки;
б) получится совершенно ординарный для Scheme код, использующий лямбды и замыкания, как обычно в функциональных языках и принято.
Цель исходника была — продемонстрировать closure в Делфи как обычное средство языка. Если я продемонстрирую closure в Scheme как обычное средство языка, то Америку этим не открою: все и так знаю, что в Scheme есть замыкания.
Отсюда вопрос: какого лешего вам сдалось на что-то его переписывать?
> Из какой же?
Из функционального программирования и λ-исчисления Черча.
Всегда ваш, К.О.
Не владею.
> Python
Не владею.
> PHP
Не владею, и слава Богу.
Могу попробовать переписать на Scheme, но:
а) это потребует некоторое время, давно не брал его в руки;
б) получится совершенно ординарный для Scheme код, использующий лямбды и замыкания, как обычно в функциональных языках и принято.
Цель исходника была — продемонстрировать closure в Делфи как обычное средство языка. Если я продемонстрирую closure в Scheme как обычное средство языка, то Америку этим не открою: все и так знаю, что в Scheme есть замыкания.
Отсюда вопрос: какого лешего вам сдалось на что-то его переписывать?
> Из какой же?
Из функционального программирования и λ-исчисления Черча.
Всегда ваш, К.О.
Тьфу. Вторая ветвь разговора же про хвостовую рекурсию, а не про замыкание. А к ней λ-исчисление отношения особо не имеет. Простите, увлекся. Только функциональное программирование.
> Могу попробовать переписать на Scheme
Давай, жду.
> Отсюда вопрос: какого лешего вам сдалось на что-то его переписывать?
Давать исходник на Дельфи было как минимум глупо. Последний раз я это видел лет 5 назад, когда получил бумажку о том, что я какой-то там круто программист Дельфи :)
Т.е. функциональное программирование не мэйнстрим? Erlang уже довольно много где используется, да и Scala тоже.
З.Ы. за сим жду последнего ответа, т.к. меня скоро хомячки с говном съедят :)
Давай, жду.
> Отсюда вопрос: какого лешего вам сдалось на что-то его переписывать?
Давать исходник на Дельфи было как минимум глупо. Последний раз я это видел лет 5 назад, когда получил бумажку о том, что я какой-то там круто программист Дельфи :)
Т.е. функциональное программирование не мэйнстрим? Erlang уже довольно много где используется, да и Scala тоже.
З.Ы. за сим жду последнего ответа, т.к. меня скоро хомячки с говном съедят :)
> Давать исходник на Дельфи было как минимум глупо.
О да. Обсуждая тему «замыкания в Делфи», давать исходник, демонстрирующий замыкания в Делфи, однозначно глупо. Поистине, надо давать исходник с замыканиями на Python, он же так прекрасно иллюстрирует замыкания в Делфи!
Я хренею, дорогая редакция.
> Т.е. функциональное программирование не мэйнстрим?
Как показывает хотя бы TIOBE — ни на грамм.
Проекты на Scala можно пересчитать на пальцах. Серверы на Erlang чуть более популярны и удобны, но все же это не мейнстрим. Про Великий и Могучий Haskell вообще молчу.
В мейнстрим MS может протолкнуть F#, если будет активно работать, но это еще вилами по воде писано.
Исходник на Scheme будет вам через энное время отдельным комментом. Раз уж так просите.
О да. Обсуждая тему «замыкания в Делфи», давать исходник, демонстрирующий замыкания в Делфи, однозначно глупо. Поистине, надо давать исходник с замыканиями на Python, он же так прекрасно иллюстрирует замыкания в Делфи!
Я хренею, дорогая редакция.
> Т.е. функциональное программирование не мэйнстрим?
Как показывает хотя бы TIOBE — ни на грамм.
Проекты на Scala можно пересчитать на пальцах. Серверы на Erlang чуть более популярны и удобны, но все же это не мейнстрим. Про Великий и Могучий Haskell вообще молчу.
В мейнстрим MS может протолкнуть F#, если будет активно работать, но это еще вилами по воде писано.
Исходник на Scheme будет вам через энное время отдельным комментом. Раз уж так просите.
> Как показывает хотя бы TIOBE — ни на грамм.
Он ничего не показывает, ибо не имеет такого охвата, что бы хотя бы частично показать действительное положение дел :)
> Проекты на Scala можно пересчитать на пальцах. Серверы на Erlang чуть более популярны и удобны, но все же это не мейнстрим. Про Великий и Могучий Haskell вообще молчу.
Наверно, Вы пользователь Windows и пишите только GUI приложения. Ни одного многопоточного парсера не писали?
> В мейнстрим MS может протолкнуть F#, если будет активно работать, но это еще вилами по воде писано.
Про .Net и вообще все разработки MS можно даже не начинать разговор. Все это не больше чем маркетойдный высер :)
Он ничего не показывает, ибо не имеет такого охвата, что бы хотя бы частично показать действительное положение дел :)
> Проекты на Scala можно пересчитать на пальцах. Серверы на Erlang чуть более популярны и удобны, но все же это не мейнстрим. Про Великий и Могучий Haskell вообще молчу.
Наверно, Вы пользователь Windows и пишите только GUI приложения. Ни одного многопоточного парсера не писали?
> В мейнстрим MS может протолкнуть F#, если будет активно работать, но это еще вилами по воде писано.
Про .Net и вообще все разработки MS можно даже не начинать разговор. Все это не больше чем маркетойдный высер :)
> Ни одного многопоточного парсера не писали?
Когда у меня возникнет такая нужда — я возьму в руки F# и TPL с PLINQ, а никак не Delphi, C#, Scheme или Python.
> Про .Net и вообще все разработки MS можно даже не начинать разговор. Все это не больше чем маркетойдный высер :)
Черт, даже не знаю, что ответить. Никогда не умел адекватно спорить с фанатиками, простите :)
Когда у меня возникнет такая нужда — я возьму в руки F# и TPL с PLINQ, а никак не Delphi, C#, Scheme или Python.
> Про .Net и вообще все разработки MS можно даже не начинать разговор. Все это не больше чем маркетойдный высер :)
Черт, даже не знаю, что ответить. Никогда не умел адекватно спорить с фанатиками, простите :)
Ну вот такой жуткий исходник получился (на DrScheme). Лучше не просите, все-таки не основной мой язык.
Итоговой вывод:
(define (entrypoint)
(begin
(let ((_foo
(let ((i 3))
(let ((proc (lambda (newValue)
(begin
(print (format "Old: ~a, new: ~a" i newValue))
(newline)
(set! i newValue)
(void)))))
(begin
(proc 5)
(print (format "Current: ~a" i))
(newline)
(set! i 8)
(proc 13)
proc)))))
(_foo 21))))Итоговой вывод:
> (entrypoint) "Old: 3, new: 5" "Current: 5" "Old: 8, new: 13" "Old: 13, new: 21"
Я писал на delphi очень долго, никогда не раздражали begin..end. Сейчас чаще пишу на php — сильно раздражают {}. Честно.
P.S.: «end else begin» — впервые вижу, чтобы кто-то написал это в одну строку…
P.S.: «end else begin» — впервые вижу, чтобы кто-то написал это в одну строку…
В школе нужно начинать с алгоритмов и никаких языков. На первом курсе — SICP и никаких Pascal/Delphi/Basic. Тогда уровень образования повыситься.
У нас в школе жалкие основы Pascal'я шли как-раз после Кенгурёнка и Пылесосика.
То что «надо», это конечно понятно. Я это понимаю так-же как и вы. Это «им» нужно объснить )
То что «надо», это конечно понятно. Я это понимаю так-же как и вы. Это «им» нужно объснить )
На Delphi много где пишут. Но самый существенный недостаток, это цена студии.
кстати чем оно лучше Qt с его Qt Creator?
отличная подборка! Даешь больше информации о Delphi!
А компилятор под x64 и нормальная поддержка UNICODE имеются? На дворе 2010 уже.
Unicode — вполне.
http://ru.wikipedia.org/wiki/Delphi_(среда_разработки)
http://ru.wikipedia.org/wiki/Delphi_(среда_разработки)
Новое в Delphi 2009:
Полная поддержка Unicode. Все функции Windows API заменены на их unicode аналоги (к примеру, ранее MessageBox определялась как MessageBoxA, теперь — MessageBoxW), тип String теперь на самом деле является UnicodeString, а char — WideChar, PChar теперь объявлен как PWideChar. Старые типы и описания ANSI-вариантов системных функций сохранились, однако теперь потребуется прямое их указание (к примеру, Set of char в Delphi 2009 будет Set of AnsiChar, а MessageBox — MessageBoxA). Delphi 2009 — первая из версий Delphi для Win32, требующая серьезной переработки проектов при переходе на новую версию, что особенно критично для системных программистов, широко использовавших прямую обработку типов данных.
Т.е. если мне надо написать xml парсер для UTF8, то делфи будет хранить его как WideChar (на что потребуется в два раза больше памяти, хотя это не так страшно при современных объёмах) и будет давать overhead на приведениях типа UTF8 <-> WideChar?
Нет. Если вам надо хранить в UTF8, вы используете тип UTF8String (который является старым AnsiString с установленной кодовой страницей 65001).
Т.е. мне надо писать отдельно парсер для UTF8 и UTF16?
Я к тому, что в любом из современных языков я могу использовать возможности обобщённого программирования. А в Delphi?
Я к тому, что в любом из современных языков я могу использовать возможности обобщённого программирования. А в Delphi?
Да с удовольствием. Дженерики уже два года как в действии.
Когда-то слышал, что дженерики там обрезанные. Как они реализованы?
Можете показать пример парсера, где бы я мог написать XmlParser и юзать его без малейшего оверхеда? Или пример ассоциативного контейнера для любого типа?
Можете показать пример парсера, где бы я мог написать XmlParser и юзать его без малейшего оверхеда? Или пример ассоциативного контейнера для любого типа?
XmlParser < AnyStringType >
В качестве примера ассоциативного контейнера (и не только его) можете взять DeHL. Этот проект, кроме набора контейнеров, реализует для Делфи расширения в стиле LINQ. И еще несколько полезных примочек а-ля nullable.
Обрезанные — смотря с чем сравнивать. По сравнению с C#/Java — ничуть, они реализованы (почти) идентично (с поправкой на тему различий нативного кода и IL/bytecode). В сабжевом посте есть сравнение. Если сравнивать с темплейтами С++, то ежу понятно, что перевес будет явно не в сторону Делфи.
Пример парсера, к сожалению, прямо с ходу так не выдам.
Обрезанные — смотря с чем сравнивать. По сравнению с C#/Java — ничуть, они реализованы (почти) идентично (с поправкой на тему различий нативного кода и IL/bytecode). В сабжевом посте есть сравнение. Если сравнивать с темплейтами С++, то ежу понятно, что перевес будет явно не в сторону Делфи.
Пример парсера, к сожалению, прямо с ходу так не выдам.
У этой библиотеки даже документации нормальной нет. Хотя по краткому описанию выглядит неплохо. Но сколько в ней ещё багов? Её пишет один человек и завтра может бросить. В общем, в production code не включишь. То, что в С++ и C# уже давно отлажено и весь функционал отработан, в делфи только только зарождается на добровольных началах.
Ну относительно xml парсера и вовсе получается разочарование. Что, нет их чтоли?
Я ушёл с делфи 4 года назад. За это время вроде что-то и изменилось. Ну вот те же дженерики. Вроде и есть и в тоже время как-то всё хреново или просто со стороны так кажется.
Ну относительно xml парсера и вовсе получается разочарование. Что, нет их чтоли?
Я ушёл с делфи 4 года назад. За это время вроде что-то и изменилось. Ну вот те же дженерики. Вроде и есть и в тоже время как-то всё хреново или просто со стороны так кажется.
Если вам нужен чисто ассоциативный контейнер с гарантированным качеством, то
То, что я не могу вам предложить хороший XML-парсер на Делфи с дженериками, не значит, что их не существует — и тем более не значит, что его невозможно написать!
Это просто значит, что мне лично он доселе не понадобился, и не более) Я точно знаю: если что,
Я сейчас использую в основном Делфи и C# — в зависимости от потребностей. Могу сказать, что они прекрасно друг другу соответствуют по функционалу и возможностям. Единственное, чего не хватает Делфи — доделанной библиотеки, во что-то человеческое превратить их VCL и RTL. Приходится использовать либы третьих лиц, вроде JCL или того же DeHL.
Впрочем, я на это уже жаловался в первой части поста.
TDictionary<TKey, TValue> имеется в поставке Делфи =) DeHL я предложил, потому что это хорошая демонстрация возможностей дженериков Делфи для различных целей.То, что я не могу вам предложить хороший XML-парсер на Делфи с дженериками, не значит, что их не существует — и тем более не значит, что его невозможно написать!
Это просто значит, что мне лично он доселе не понадобился, и не более) Я точно знаю: если что,
TXMLDocument в поставке поддерживает Unicode, любую из существующих кодировок после тотального переписывания в Делфи 2009, так как выдает мне UnicodeString. Но вот внутренностями (есть ли там оверхед) или альтернативными реализациями (с дженериками) не интересовался. Извиняюсь.Я сейчас использую в основном Делфи и C# — в зависимости от потребностей. Могу сказать, что они прекрасно друг другу соответствуют по функционалу и возможностям. Единственное, чего не хватает Делфи — доделанной библиотеки, во что-то человеческое превратить их VCL и RTL. Приходится использовать либы третьих лиц, вроде JCL или того же DeHL.
Впрочем, я на это уже жаловался в первой части поста.
> Я сейчас использую в основном Делфи и C# — в зависимости от потребностей. Могу сказать, что они прекрасно друг другу соответствуют по функционалу и возможностям.
Я думаю это не совсем правда. :) По возможностям языка Delphi находится на уровне C# 2.0, а на дворе C# 4.0.
По самой библиотеке ситуация та же. NET Framework побогаче будет, мягко говоря.
Я думаю это не совсем правда. :) По возможностям языка Delphi находится на уровне C# 2.0, а на дворе C# 4.0.
По самой библиотеке ситуация та же. NET Framework побогаче будет, мягко говоря.
Если говорить откровенно, C# 3, совместимый по CLR с C# 2, не принес кардинально нового.
Лямбда-выражения и замыкание — серебряная пуля в функциональном программировании. Реально реализуется анонимными методами, которые были и в C# 2. И присутствуют в Делфи 2009.
LINQ я вам показал.
Параметры по умолчанию из C# 4 в Делфи еще с первых версий были. Равно как и работа с COM — здесь уже C# проигрывает вчистую.
Неименованные кортежи в С# 3 были, равно как и var, введены чисто для полномасштабной реализации LINQ. На деле этими кортежами мало кто пользуется — тем более с 2010 студией F# принес в .NET Framework человеческие тупли.
Против dynamic выставить нечего, пасую. Останемся на уровне C# 3.
Ну а о проблемах стандартной библиотеки я уже говорил, добавить нечего — .NET Framework сильнее. С другой стороны, если взять стандартного Делфи-разработчика, который обычно использует 2-3 открытых библиотеки третьих лиц, еще неизвестно, кто выиграет.
Лямбда-выражения и замыкание — серебряная пуля в функциональном программировании. Реально реализуется анонимными методами, которые были и в C# 2. И присутствуют в Делфи 2009.
LINQ я вам показал.
Параметры по умолчанию из C# 4 в Делфи еще с первых версий были. Равно как и работа с COM — здесь уже C# проигрывает вчистую.
Неименованные кортежи в С# 3 были, равно как и var, введены чисто для полномасштабной реализации LINQ. На деле этими кортежами мало кто пользуется — тем более с 2010 студией F# принес в .NET Framework человеческие тупли.
Против dynamic выставить нечего, пасую. Останемся на уровне C# 3.
Ну а о проблемах стандартной библиотеки я уже говорил, добавить нечего — .NET Framework сильнее. С другой стороны, если взять стандартного Делфи-разработчика, который обычно использует 2-3 открытых библиотеки третьих лиц, еще неизвестно, кто выиграет.
> Реально реализуется анонимными методами, которые были и в C# 2. И присутствуют в Делфи 2009.
Это вы про TProc<>? Замыкания и лямбды как минимум более лаконичны по сравнению с анонимными методами. Но я согласен, что функциональные фичи в императивных языках смотрятся иногда коряво. Поэтому теперь есть F#.
> LINQ я вам показал.
Это несравнимые вещи. Во-первых, я уже говорил, linq-like extension (как автор его называет) написанное человеком в свободное время и часть коммерческого фремйворка разные вещи. Я пока не могу даже документацию и примеры посмотреть, что это вообще такое, а LINQ уже несколько лет используется в production code. Вы сами то им пользовались?
> 2010 студией F# принес в .NET Framework человеческие тупли.
F# можно поставить и на олее ранние студии. К тому же F# это скорее плюс к C#, чем к Delphi. Потому как мы получили мощный инструмент в рамках одного фреймворка. Прикрутить либу на F# к C# минутное дело.
А что насчёт type inference? Generators (yield)? А в Delphi вообще итераторы есть?
Остаёмся где-то на уровне C# 2.5 :) В общем-то глупо отрицать отставание Delphi, это объективный факт. Вы не согласны?
> С другой стороны, если взять стандартного Делфи-разработчика, который обычно использует 2-3 открытых библиотеки третьих лиц, еще неизвестно, кто выиграет.
Я сомневаюсь всё-таки. Что там у делфи с средствами для создания и деплоймента web-services? Когда я пересел с Делфи был голяк, а в .NET (равно как и в Java) всё очень хорошо, за пару дней можно создать простейший сервис и масштабировать его до уровня крупной компании. В области RIA тоже проигрыш.
Delphi нечего противопоставить новому WPF.
В области 3D визуализации тоже голяк какой-то. DirectX SDK под C++, есть куча библиотек для C#. Есть OpenGL скажете вы, ну хорошо. попробуйте найдите под Delphi библиотеку уровня OpenInventor (есть порты под .NET и Java) или хотя бы Coin3D, в них используется OpenGL.
Что насчёт вычислений на GPU? Опять облом. В итоге всё, с чем лично я работаю, оказывает нереализуемо на практике. Вот так чтобы взял и начал разработку. И всё это очень смачно подкрепляется отсутствием поддержки x64 (хотя бы x64).
Это вы про TProc<>? Замыкания и лямбды как минимум более лаконичны по сравнению с анонимными методами. Но я согласен, что функциональные фичи в императивных языках смотрятся иногда коряво. Поэтому теперь есть F#.
> LINQ я вам показал.
Это несравнимые вещи. Во-первых, я уже говорил, linq-like extension (как автор его называет) написанное человеком в свободное время и часть коммерческого фремйворка разные вещи. Я пока не могу даже документацию и примеры посмотреть, что это вообще такое, а LINQ уже несколько лет используется в production code. Вы сами то им пользовались?
> 2010 студией F# принес в .NET Framework человеческие тупли.
F# можно поставить и на олее ранние студии. К тому же F# это скорее плюс к C#, чем к Delphi. Потому как мы получили мощный инструмент в рамках одного фреймворка. Прикрутить либу на F# к C# минутное дело.
А что насчёт type inference? Generators (yield)? А в Delphi вообще итераторы есть?
Остаёмся где-то на уровне C# 2.5 :) В общем-то глупо отрицать отставание Delphi, это объективный факт. Вы не согласны?
> С другой стороны, если взять стандартного Делфи-разработчика, который обычно использует 2-3 открытых библиотеки третьих лиц, еще неизвестно, кто выиграет.
Я сомневаюсь всё-таки. Что там у делфи с средствами для создания и деплоймента web-services? Когда я пересел с Делфи был голяк, а в .NET (равно как и в Java) всё очень хорошо, за пару дней можно создать простейший сервис и масштабировать его до уровня крупной компании. В области RIA тоже проигрыш.
Delphi нечего противопоставить новому WPF.
В области 3D визуализации тоже голяк какой-то. DirectX SDK под C++, есть куча библиотек для C#. Есть OpenGL скажете вы, ну хорошо. попробуйте найдите под Delphi библиотеку уровня OpenInventor (есть порты под .NET и Java) или хотя бы Coin3D, в них используется OpenGL.
Что насчёт вычислений на GPU? Опять облом. В итоге всё, с чем лично я работаю, оказывает нереализуемо на практике. Вот так чтобы взял и начал разработку. И всё это очень смачно подкрепляется отсутствием поддержки x64 (хотя бы x64).
> Вы сами то им пользовались?
Естественно. Я не кидаю ссылки на то, о чем не имею представления. Именно поэтому я не ответил вам по поводу XML-парсера, хотя мог бы заглянуть на torry.net: там 100% нашлась бы парочка-другая многообещающих либ.
Зато за DeHL и его контейнеры могу ручаться: это надежно работающая альтернативная реализация LINQ в полной мере, и отсутствие у нее документации (в конце концов, мы что, не люди, мы исходники читать разучились?) не является поводов поносить проект с ног до головы.
> F# можно поставить и на олее ранние студии. К тому же F# это скорее плюс к C#, чем к Delphi. Потому как мы получили мощный инструмент в рамках одного фреймворка. Прикрутить либу на F# к C# минутное дело.
Я говорил в этом абзаце про одну конкретную мелочь: тупли, а не про F#. С мощью F# я даже и не заикаюсь спорить, сам поддержу любой холивар в его защиту.
А речь шла вообще о System.Tuple<>.
> type inference
Отсутствует за ненадобностью: все переменные явно типизируются при объявлении в разделе var. Разговор о том, какая система объявления лучше, породит новый холивар, коему черт знает сколько лет. Я придерживаюсь мнения, что объявление в отдельном разделе приучает к дисциплине и большей продуманности кода, зато объявление в любой точке на порядок удобнее и быстрее для написания)
> Generators (yield)
Нет.
> А в Delphi вообще итераторы есть?
Здрасте вам с бубликом)
IEnumerator<T> есть, утиная типизация есть, готовые контейнеры есть… что-то вы действительно отстали от жизни =)
> В общем-то глупо отрицать отставание Delphi, это объективный факт. Вы не согласны?
Если бы я был с этим согласен, я бы уже три поста тут кричал во всю Ивановскую, что C# 4 — унылое индусское поделие и Делфи давно поработил мир)
Нет, если серьезно: я сам спокойно приведу вам ряд мест, в которых Делфи как язык проигрывает многим другим языкам. Но я, как и комментаторы ниже, заявляю следующее: ни одно из этих мест не является критичным. Ничто не привносит в разработку кардинального упрощения.
С одной стороны баррикад
С одной
И так далее.
Заметьте, речь сейчас идет о языке, а не о библиотеке.
А на каждую библиотеку надо искать конкретные аналоги.
К примеру, известные практически всем Делфи-разработчикам:
— DelphiX для DirectX.
— OmniThreadLibrary, очень похожий по идеологии на TPL.
С CUDA и им подобными я не работал, поэтому ничего не приведу. Но вообще я не вижу проблемы в том, чтобы скомпилировать на С DLL или объектный файл и спокойно написать на Делфи модуль-обертку для него, как обычно и делаются С++ хедеры.
Естественно. Я не кидаю ссылки на то, о чем не имею представления. Именно поэтому я не ответил вам по поводу XML-парсера, хотя мог бы заглянуть на torry.net: там 100% нашлась бы парочка-другая многообещающих либ.
Зато за DeHL и его контейнеры могу ручаться: это надежно работающая альтернативная реализация LINQ в полной мере, и отсутствие у нее документации (в конце концов, мы что, не люди, мы исходники читать разучились?) не является поводов поносить проект с ног до головы.
> F# можно поставить и на олее ранние студии. К тому же F# это скорее плюс к C#, чем к Delphi. Потому как мы получили мощный инструмент в рамках одного фреймворка. Прикрутить либу на F# к C# минутное дело.
Я говорил в этом абзаце про одну конкретную мелочь: тупли, а не про F#. С мощью F# я даже и не заикаюсь спорить, сам поддержу любой холивар в его защиту.
А речь шла вообще о System.Tuple<>.
> type inference
Отсутствует за ненадобностью: все переменные явно типизируются при объявлении в разделе var. Разговор о том, какая система объявления лучше, породит новый холивар, коему черт знает сколько лет. Я придерживаюсь мнения, что объявление в отдельном разделе приучает к дисциплине и большей продуманности кода, зато объявление в любой точке на порядок удобнее и быстрее для написания)
> Generators (yield)
Нет.
> А в Delphi вообще итераторы есть?
Здрасте вам с бубликом)
const
Fibonacci: array of Integer = (1, 1, 2, 3, 5, 8, 13);
var
I: Integer;
// ...
for I in Fibonacci do
WriteLn(I);IEnumerator<T> есть, утиная типизация есть, готовые контейнеры есть… что-то вы действительно отстали от жизни =)
> В общем-то глупо отрицать отставание Delphi, это объективный факт. Вы не согласны?
Если бы я был с этим согласен, я бы уже три поста тут кричал во всю Ивановскую, что C# 4 — унылое индусское поделие и Делфи давно поработил мир)
Нет, если серьезно: я сам спокойно приведу вам ряд мест, в которых Делфи как язык проигрывает многим другим языкам. Но я, как и комментаторы ниже, заявляю следующее: ни одно из этих мест не является критичным. Ничто не привносит в разработку кардинального упрощения.
С одной стороны баррикад
x => x * 2, с другой function (x: Integer) begin Exit(x * 2) end.С одной
yield return x, с другой — реализация метода IEnumerator<T>.GetCurrent().И так далее.
Заметьте, речь сейчас идет о языке, а не о библиотеке.
А на каждую библиотеку надо искать конкретные аналоги.
К примеру, известные практически всем Делфи-разработчикам:
— DelphiX для DirectX.
— OmniThreadLibrary, очень похожий по идеологии на TPL.
С CUDA и им подобными я не работал, поэтому ничего не приведу. Но вообще я не вижу проблемы в том, чтобы скомпилировать на С DLL или объектный файл и спокойно написать на Делфи модуль-обертку для него, как обычно и делаются С++ хедеры.
Ох посмотрели бы вы сейчас на свой WPF и полностью кроссплатформенный FMX в Delphi))
А что вообще в Delphi с параллельными вычислениями? Почему они не могут реализовать хотя бы OpenMP? В .NET есть ParallelExtension, я уж не говорю про F#.
Покажите, что можно реализовать на C#4.0, чего нельзя на Delphi и я вам поверю. В противном случае — вы лукавите, выдавая желаемое за действительное ;).
var source = Enumerable.Range(100, 20000);
// Result sequence might be out of order.
var parallelQuery = from num in source.AsParallel()
where num % 10 == 0
select num;
Вот вам простейший Parallel LINQ запрос. Повторите.
// Result sequence might be out of order.
var parallelQuery = from num in source.AsParallel()
where num % 10 == 0
select num;
Вот вам простейший Parallel LINQ запрос. Повторите.
Тогда уж объясните, что он делает и когда такое необходимо?
Я просил задачу, а не код ;). Объясните, что делает данный код — сделаю тоже самое на Delphi.
var parallelQuery = from num in source.AsParallel() where num % 10 == 0 select num;
Данная строчка кода обходит массив и выбирает значения кратные 10. Причём делает это параллельно. Т.е. распределяет все ресурсы на все процессоры.
То, что можно придумать аналог на Delphi я не сомневаюсь (хотя мне интересно как вы параллелизм сделаете). Мы обсуждаем языки.
Данная строчка кода обходит массив и выбирает значения кратные 10. Причём делает это параллельно. Т.е. распределяет все ресурсы на все процессоры.
То, что можно придумать аналог на Delphi я не сомневаюсь (хотя мне интересно как вы параллелизм сделаете). Мы обсуждаем языки.
Всего-то… Ну тогда обходим массив с помощью потоков. Код конечно получится значительно больше и менее красив, но вполне рабочий. Что-то подобное решалось тут: forum.vingrad.ru/topic-231619.html в рамках конкурса между Delphi-программистами.
>То, что можно придумать аналог на Delphi я не сомневаюсь (хотя мне интересно как вы параллелизм сделаете). Мы обсуждаем языки.
Я про это и говорю. Не знаю, пока еще, ни одной задачи, которую можно решить с помощью одного языка программирования и нельзя решить с помощью другого. Да, код будет разный, объем работы, объем занимаемого времени и места, время получения результата тоже. Но результат будет одинаков. Поэтому, нет смысла говорить, что какой-то язык сильнее/слабее другого — разница в степени и качестве использования… Хотя я и сам не так давно грешил подобным — очень рьянно защищал Delphi, доказывая всем и вся его «крутость» =)
>То, что можно придумать аналог на Delphi я не сомневаюсь (хотя мне интересно как вы параллелизм сделаете). Мы обсуждаем языки.
Я про это и говорю. Не знаю, пока еще, ни одной задачи, которую можно решить с помощью одного языка программирования и нельзя решить с помощью другого. Да, код будет разный, объем работы, объем занимаемого времени и места, время получения результата тоже. Но результат будет одинаков. Поэтому, нет смысла говорить, что какой-то язык сильнее/слабее другого — разница в степени и качестве использования… Хотя я и сам не так давно грешил подобным — очень рьянно защищал Delphi, доказывая всем и вся его «крутость» =)
Да, всего-то то, что записывается одной строчкой в C# требует 50 на Delphi. Ассемблер и brainfuck обладают Тьюринг полнотой, следовательно на них тоже можно реализовать всё. Только для меня язык прогрммирование — это средство решения задач, а не клавиатурный тренажёр.
Фанатизм… Ок, в вашем же ключе — покажите аналог VirtualTreeView на C#. А потом потестим, кому сколько кода понадобится, чтобы реализовать одно и то же =)
C выходом WPF .NET ушёл далеко вперёд по части программирования продвинутых интерфейсов. Тут глупо тягаться.
Что особенного в VirtualTreeView? Всё это есть в .NET и всё расширяется в WPF.
Есть даже экзотика типа: www.devcomponents.com/treegx/img/TreeGXComp.png
Что особенного в VirtualTreeView? Всё это есть в .NET и всё расширяется в WPF.
Есть даже экзотика типа: www.devcomponents.com/treegx/img/TreeGXComp.png
И снова фанатизм… Вы знаете возможности VT? Нет? тогда почему утверждаете, что «тягаться глупо»?
>Всё это есть в .NET и всё расширяется в WPF.
Серьезно? Видимо я очень давно не трогал .Net. Подскажите, сколько строк надо будет написать, чтобы каждой ячейке дерева, в любой ветке которой неограниченное количество столбцов, назначить свой редактор (текст, дата, время, выпадающий список, чекбокс и т.д… вплоть до экзотики, наподобии эквалайзера)? В Delphi — 2-3 строки, не считая самого редактора. Реализация редактора зависит только от фантазии…
>Всё это есть в .NET и всё расширяется в WPF.
Серьезно? Видимо я очень давно не трогал .Net. Подскажите, сколько строк надо будет написать, чтобы каждой ячейке дерева, в любой ветке которой неограниченное количество столбцов, назначить свой редактор (текст, дата, время, выпадающий список, чекбокс и т.д… вплоть до экзотики, наподобии эквалайзера)? В Delphi — 2-3 строки, не считая самого редактора. Реализация редактора зависит только от фантазии…
Не совсем — собственно дженерики в Delphi куда лучше плюсовых ввиду нетипизированности последних.
Другое дело, что средств метапрограммирования общего назначения в Delphi нет.
Но и тут у плюсов особых дивидендов нет: там, где кровь из носу требуется метапрограммирование — будут использовать LISP, Nemmerle и т.п.
Другое дело, что средств метапрограммирования общего назначения в Delphi нет.
Но и тут у плюсов особых дивидендов нет: там, где кровь из носу требуется метапрограммирование — будут использовать LISP, Nemmerle и т.п.
Как будет хранить программа — это уже ваша проблема. Хоть в AnsiString, хоть в UTF8String, хоть в виде байтов…
>>Новое в Delphi 2009: Полная поддержка Unicode.
Молодцы! И главное- как вовремя!!!
Молодцы! И главное- как вовремя!!!
Недавно был на семинаре от Embarcadero, обещали сделать компилятор в следующей, или через одну версию делфей.
Поддержка юникода с 2006й студии, кажется.
Поддержка юникода с 2006й студии, кажется.
К сожалению то, что на Delphi до сих пор пишут, ещё не говорит о том, что оно не устарело…
На мой взгляд, главная беда в в том, что его до сих пор преподают в некоторых ВУЗах.
На мой взгляд, главная беда в в том, что его до сих пор преподают в некоторых ВУЗах.
Delphi — отличный инструмент для создания windows-приложений, запускающихся на всех версиях Windows и не требующих скачки-установки фреймворков на сотню мегабайт. Плюс к этому огромная база готового кода, библиотек и компонентов, а также сильное русскоязычное делфи-сообщество.
спасибо, ценный пост. Многое уже читал, но нашлось кое-что новое.
К сожалению, заметил, что последние версии среды какие-то перегруженные, кучу всяких пакетов и фремворков хотят при установке…
но вот для создания программок для построения простых графиков вполне годится, а, главное, умение, инструмент уже есть, ничего придумывать не надо.
Всему своё место.
Для меня дельфи — дверь в мир программирования, позволившая потом научиться базису и на php и программированию на asm для микроконтроллеров, и это все было проще понимать к тому моменту.
но вот для создания программок для построения простых графиков вполне годится, а, главное, умение, инструмент уже есть, ничего придумывать не надо.
Всему своё место.
Для меня дельфи — дверь в мир программирования, позволившая потом научиться базису и на php и программированию на asm для микроконтроллеров, и это все было проще понимать к тому моменту.
Если вам нравился Delphi, то вам понравится FreePascal и IDE Lazarus для него. Очень интересный инструментарий для разработки высокопроизводительных кроссплатформенных приложений.
Не всегда. Мне нравится Delphi, но вот FreePascal не понравился.
Правда, я очееень давно смотрел, может уже многое поменялось. Надо будет еще раз потестить.
Правда, я очееень давно смотрел, может уже многое поменялось. Надо будет еще раз потестить.
Нормальные билды FreePascal не так давно появились. А раньше его использовать нереально было. Сейчас вполне можно собирать приложения с переносимостью на другие платформы. И да, в IDE Lazarus на данный момент повторили почти весь Delphi 7.
thx, посмотрю. жаль только, что нет аналога virtualtreeview для лазаруса =(
Одна из старых версий была портирована: wiki.lazarus.freepascal.org/VirtualTreeview
Бесспорно интересный. Но я пока что предпочитаю удобство в работе высокопроизводительности.
детский сад, ей богу!
может хватит уже пиписьками мериться? пусть каждый пользуется тем что ему больше нравится, главное чтоб был результат, обязательно надо в кого-нибудь или чего-нибудь грязью кинуть…
может хватит уже пиписьками мериться? пусть каждый пользуется тем что ему больше нравится, главное чтоб был результат, обязательно надо в кого-нибудь или чего-нибудь грязью кинуть…
Мерятся инструментами полезно для общего развития. =) Иногда что-то новое узнаешь.
Не знаю как с другими языками, но когда на Хабре речь заходит о Delphi — появляется масса людей, которые в своём стремлении доказать, что Delphi умер, или отстал в развитии, сравнивают его сразу со всеми существующими языками программирования. Это, конечно, очень познавательно, но едва ли такой разговор можно назвать конструктивным.
большое спасибо!
Sign up to leave a comment.
Самые интересные публикации 2009 года о Delphi