Pull to refresh

Comments 315

Вы меня, конечно, простите. Но!

Я считаю, что Дельфи стоило бы развиваться в могилу. И чем раньше, — тем лучше.
Зашел сюда написать этот коммент. Именно такой же. «в могилу». Но вы меня опередили :)
Друзья, что вы делаете в статье хаба Delphi?
Комментарий про это — ниже.
Многие начинали с Дельфи, но надо же когда-то заканчивать и переходить на нормальные инструменты.

Дельфи себя дискредитировала. Компонентостроением, сообществом, костылями, инфраструктурой, обилием быдлокодеров и отвратительным послевкусием.
Delphi подняла себя за счет компонентостроения, сообщества и обилия быдлокодеров. А сейчас это все можно наблюдать с равной степени в C#/.Net. Это нормальный процесс для их ниш.
MS борется с послевкусием, в отличие от Borland.
Borland уже давно не борется с Delphi…
Потому что владелец продукта — Embarcadero.
Вы думаете, что я об этом не знаю? :)
Пока не прочитал ваши комментарии в конце топика — думал что да, не знаете.
«Говорят, что подавляющее большинство русофобов — из России.»

Теперь то же самое, но «Россия» заменяем на «Дельфи».
Говорят, что подавляющее большинство делфифобов — из Делфи. Жесть.
Ничего не понимаю. Если «поближе к железу» мечтаете, то зачем тогда вообще за делфи уцепились?
Вот именно тенденция их маркетологов провоцировать и поддержать такие мнения меня и огорчает. Они сами в какой-то момент забыли, что Паскаль — весьма низкоуровневый язык с точки зрения уровня абстрагирования от железа. Один перечень целочисленных типов чего стоит! Не говоря о прямом доступе к портам, памяти и регистрам процессора. Давно могли бы добавить упаковщик, и разрешить писать драйвера, ни чем не уступающие C-шным.
Причём тут тенденция маркетологов. Это моё мнение. На паскале я писал много. На Delphi (не очень много) и C++Builder (суть одна, только вроде бы ещё «ближе» должно быть к железу) ещё больше, в том числе полукоммерческий софт. Драйвера всегда можно было писать, и на других языках для этого не предназначенных — тоже, какая разница на чём по сути. Но зачем, если есть более для ЭТОГО удобные языки/инструменты. Делфи/цппбилдер — не самый плохой инструментарий, у него есть своя ниша (наиболее удачная, имхо, это десктопные БД-клиенты итд), но это явно не сколько-нибудь низкоуровневое программирование.
Это мнение у Вас от недостаточной информированности, извините.
С таким-то аргументом сложновато поспорить, дооо…
Недостаточной информированности в чём? В том, какая именно ниша? А кем надо быть, чтобы быть достаточно информированным?
В данном случае надо лишь чуть больше и смелее писать на Delphi. Тогда бы Вы убедились, что это мощный низкоуровневый язык, позволяющий писать отнюдь не только клиенты к БД.
> синтетическим сахаром
не-не, даешь натуральные продукты :)
А вот за эту фразу я добавил пост в избранное.
Простите, вынужден Вас огорчить, это была опечатка, одобренная спеллчекером. Исправил.
Вот я и думаю, как это в здравом уме человек опечатался на четыре буквы с сохранением какой-никакой семантики?
Видели бы Вы, как получается опечатываться используя Swype на андроиде… Тут фигня по сравнению с тем…
Покажите ваши пул-реквесты в лазарус. Почему так много людей которые знаю куда и что нужно развивать, но при этом считают, что это делать должен кто-то другой
Что бы писать грамотные реквесты, нужно пользоваться. Я пользуюсь Delphi старой версии, про которой писать реквесты бестолку. И с недоумением наблюдаю за презентациями новых.
Но вот когда я рыпнулся было что-то в Лазарусе сделать, я сразу же вынужден был написать пару реквестов в багтрекер. Довольно бестолково получилось, потому что в Лазарусе с фрипаскалем с наскоку разобраться невозможно пока.
Хочу высказать свое мнение:

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

Если сразу учился на другом языке, то это не значит, что все остальное гавно.

Лично я впервые увидел компьютер в глаза на втором курсе 2003 года. В конце года начал изучать Turbo Pascal, потому что его у нас преподавали и потому что он оказался простым. Но прост, это не значит УГ. Я изучая понял основные принципы построения языка и программы. Синтаксис, отладка, компиляция. Все азы я выучил на паскале. Затем мы начали изучать С и позже С++. А зная азы и архитектуру языка, я легко освоил сишные языки. Подучил новые операторы и конструктивы. затем в универе мы изучали Cygwin + Assembler + OpenGL. Этого опыта мне хватает и по сей день. Я легко освоил PHP, html, javascript, mysql и firebird.

Самый главный мой проврыв — это знакомство с дельфи. Визуализация в отличии от DOS, я понял, что такое ООП, система сообщений, мьютексы, семафоры, многопоточность, базы данных и пр. На бильдере было сложно учиться, ибо исходники закрыты, а на делфях они открыты — меня никто не учил, я просто ковырял исходники и лазил по диалапу в инет. Я даже ностальгирую по тем временам.

И сегодня, у меня даже не повернется язык сказать, что дельфи сдох. Ибо для меня — он все. Я на нем вырос, учился. Сейчас даже проекты делаю на нем, потому что быстро. А быдлокодство — это неопытность.

Я за пару дней освоил AVR контроллеры, потому что я понимал основы языка, и не важно, ассемблер это или си, хотя я в принципе фанатик делфей.

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

Приобретенный опыт бесценен. Я, например, все еще сижу на 7-х делфях, но тот факт, что студия развивается, не оставляет равнодушным. Найдутся тысячи, кому это по душе, и я за это рад.

Прошу прощения за столь длинный комментарий…
Pascal — учебный язык. Object Pascal + Delphi — попытка быстро пересадить вчерашних школьников и студентов в кьюбиклы на благо энтерпрайза. Логично, что с такими вводными эксперимент провалился.

Ностальгия — страшная штука. Давайте ещё СССР возродим.
«Паскаль — лишь учебный язык» — это ничем не обоснованный стереотип. Но, к сожалению, живучий. Ещё один живучий ничем не обоснованный стереотип — что «Delphi — лишь рисовалка окошков». Эти два стереотипа столь заразны, что сносят крышу даже маркетологам, рулящим направлениями работы команды CodeGear.
Почитайте его историю. Желательно в изложении от самого Вирта.

И давайте не будем про парадигменную целостность (которой там нету, потому что язык сделан на коленке, исходя из желания скрестить low-level и high-level разработку), про маркетинговые ходы (я помню TurboVision, помню) и прочую шелуху.

И да, Delphi и её IDE — рисовалки окошек точно такие же, как VisualFoxPro — СУБД. Хорошие.
Да, на VisualFoxPro можно поднимать встроенный веб-сервер, в котором реализуется REST-модель, которая, в свою очередь, используется из встроенного через ActiveX и связанного с оконными событиями InternetExplorer, в котором запущено JS-приложение, которое посредством кучи хаков интегрируется с нативным UI. Но это извращение той же природы, что и написание на Delphi ответственных сетевых сервисов.

Давайте не будем спорить о тех вещах, которые очевидны всем, но не принимаются головой как аргументы в силу очень субъективных причин. Синдром утёнка — страшная штука.
Как родилось и во что выросло — это разные вещи. По мне — так получилось гениальнейше. Но стряхнуть пелёнки стереотипов не смогло, и это жалко.

Седьмой Турбо-Паскаль был великолепен, и как среда и как язык. TurboVision, кстати, тоже была весьма хорошая библиотека. Не знаю, что Вы там о ней помните…

Сравнивать VisualFoxPro с Delphi — тоже самое, что сравнивать PHP или Flash с С++. Это разного уровня продукты. Именно, что синдром утёнка играет. Типа, раз можно в Delphi формочки к БД мышкой рисовать — значит, это тоже самое, что Visual FoxPro, ага?

Или — Вы сами понимаете разницу, но озвучиваете взгляд со стороны энтерпрайза? Если да — тогда спор ни о чём, я знаю какой оттуда нехороший вид сложился, у них синдром утёнка никогда из обострения не выходил. О том и говорю, что взгляд такой есть. Но я ещё и говорю, что он ошибочен!
«Pascal» — учебный язык.
«Отличный» ярлык, где аргументы подтверждающие данный тезис?

Delphi впал в кому, т.к. его хотели быстро перевести на .NET и забили на развитие win32/x64 — это основная ошибка.
Я, например, все еще сижу на 7-х делфях, но тот факт, что студия развивается, не оставляет равнодушным. Найдутся тысячи, кому это по душе, и я за это рад.


Как на таком убожестве можно сидеть?
Это все равно что сейчас пользоваться IE6 — когда он вышел, он был совсем не плох, но сейчас просто ужас.

Ну и что — я тоже на делфи вырос, но тем не менее делфи не нужен.
Можете обосновать эпитет «убожество»? Что именно Вы в него вкладывате в данном контексте?
Удобство использования и возможности по сравнению с современными IDE, внешний вид + периодические зависания без восстановления не сохраненных изменений и прочие баги, вроде как связанные с ошибками памяти. Уже не помню, давно не пользовался.
«Удобство использования и возможности по сравнению с современными IDE» — можно поконкретнее? Может, я чего-то упустил в жизни?

Зависаний я лично не встречал, потери правок тоже, а основная часть ошибок памяти в среде — из-за одной архитектурной особенности дизайнера, против которой я тут и сам возражаю: работа установленных компонентов непосредственно в адресном пространстве IDE и на её базовых библиотеках. Неудачно написанный собственный компонент может очень многое в среде порушить.

В общем, я бы это убогостью не называл, извините.
Рискую нарваться на минусы, однако… есть ведь пример и хорошего продукта, построенного все же на Delphi! Это горячо мною любимый AIMP2.X-3.X. Да, родился он не за неделю, развивается целым сообществом, имеет известность в соседних государствах. В целом, можно посчитать это за исключение. Однако это исключение показывает, что даже инструмент категории «не очень» способен дать годный продукт… при наличии головы на плечах и прямоты рук (что впрочем относится ко всем языкам программирования, в различной степени разумеется).

P.S. Сам я не люблю Delphi, однако немного уважаю. Всем мир! :)
Эх, цитирую (кто захочет — нагуглит авторов):

«Programmers using Visual C++ have been looking for something like this for years, and it’s right under their noses, they just don’t know it is called Delphi. »

«Delphi is not a visual basic rip off, I’ve yet to see any software applications in C++ that can’t be done in delphi. Maybe VXD drivers for Win32, or an operating system. But you still have FreePascal available if you want to create an operating system.»

«C# is a mixture between Java and Delphi anyway.»

Но суть моего коммента во в чем: по данной ссылке можно глянуть внушительный список приложений, написанных на Delphi
delphi.wikia.com/wiki/Good_Quality_Applications_Built_With_Delphi
Все азы я выучил на паскале. Затем мы начали изучать С и позже С++. А зная азы и архитектуру языка, я легко освоил сишные языки.

затем в универе мы изучали Cygwin + Assembler + OpenGL. Этого опыта мне хватает и по сей день. Я легко освоил PHP, html, javascript, mysql и firebird.

Я за пару дней освоил AVR контроллеры, потому что я понимал основы языка, и не важно, ассемблер это или си

я понял, что такое ООП, система сообщений, мьютексы, семафоры, многопоточность, базы данных и пр.


Ух, круто. А то вон некоторые тратят годы, чтобы стать специалистами по базам данных, встраиваемым системам или фронтенд разработке. А вы, благодаря delphi конечно, легко все освоили. Достойно.
Не холивара ради, но на «все» я «потратил» около 9 лет.
>> Почему все чморят хоронят дельфи? Почему этот продукт не может развиваться? Кому это мешает?
Пусть развивается как хочет.
Вот только когда выход новой версии действительно будет приносить что-то новое и полезное, а не необходимость заново переписать контрол, сомнительные плюшки и лишний вес exe при том же коде, люди вернутся. А то для системы, начатой в 2006 году мы держим Delphi7, для 2008 — другой дистрибутив. Хочу обратной совместимости.
Я прошел похожий на Ваш путь и не сожалею, что легко перестаю пользоваться устаревающими или неудобными инструментами.
Единственный сложный момент, из-за которого многое приходится подправлять — это долгожданный переход на Юникод. Но это вполне резонно, и не удивительно для такого низкоуровнего языка как ObjectPascal. И пенять тут не на что.

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

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

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

Другое дело, что компоненты, поставляемые не в исходниках, приходится брать перекомпилированные под новую версию.

Но это всё ведь тоже вполне естественно, и я не понимаю, как это может вызывать подобное вашему… назовём это огорчением.
Я согласен, что большая часть кода останется совместимой, дело как раз в тех узких моментах, которые можно было бы не менять со стороны разработчиков языка.
Выходит, что вот это «практически без изменений» для d7 и ХЕ будет выглядеть совершенно по-разному, выполнять одно и то же и требовать силы для переписывания от версии к версии.
Уникод сейчас не трогаю, фиг с ним.
UFO just landed and posted this here
Давайте вычленим тезисы из вашей заметки и разумно их обсудим.

1. Разработка прикладного ПО абстрагируется и отдаляется от железа — это плохо;
2. Object Pascal обладает развитыми средствами ООП, богатым синтаксическим сахаром, мощной IDE и однопроходным компилятором, но, при всём при этом, Object Pascal не пользуется — это плохо;
3. Нет «генераторов тонких обёрток» для Delphi в мире толстых прокладок — это плохо;
4. Нет языков, могущих во встроенный ассемблер ­— это плохо;
5. Нет средств для интеграции сторонних компиляторов — это плохо;
6. Нет средств интеропа с платформами — это плохо;
7. Нет нормальной IDE для Delphi, умеющей в интероп, «генерирование тонких обёрток» и кроссплатформенное/кросстулкитовое рисование окошек — это плохо;
8. Нет инфраструктуры для процессинга языковых метаданных — это плохо.

С ещё одним тезисом я оконфужусь. Никак не могу адекватно переписать анекдот про Неуловимого Джо, впихнув при этом в него монетизацию, целевую нишу и Delphi.

Теперь по пунктам.

1. Это хорошо. Вычислительные мощности растут, их стоимость мизерна по сравнению со стоимостью разработки ПО. Причём, если смотреть в перспективе, амортизационный период железа только увеличивается (удельная вычислительная мощность растёт), а требуемые сроки разработки ПО неумолимо сокращаются. Поэтому для разработки прикладного ПО используются максимально удобные и абстрагирующие инструменты, которые: а) предотвращают ошибки программиста ещё до их появления; б) с использованием DSL'ей максимально погружают программиста в предметную область решаемой задачи, а не в проблемы, порождаемые языком и инфраструктурой; в) улучшают показатели переносимости и переиспользования кода; г) позволяют формировать более узкие ниши разработки, соответственно, снижая стоимость разработчиков;
2. Это полуправда. Любой современный язык обладает гораздо более развитыми средствами ООП. Любой современный язык обладает синтаксическим сахаром, который заткнёт классический Object Pascal за пояс одним функтором в составе делегата. Любая современная IDE положит Delphi на обе лопатки как с точки зрения удобства, так и с точки зрения концепции (за исключением, может быть, Xcode; но это тема другой дискуссии). Апеллировать к однопроходности компилятора в наше время полуинтерпретаторов стыдно. Посмотрите на V8; Правильно делают, что ЭТИМ не пользуются — по суперпозиции качеств Object Pascal находится даже не во второй десятке современных и не очень ЯП;
3. Даже комментировать не буду. Отсутствие таких генераторов — это следствие, а не причина;
4. Это очень хорошо. Каждому инструменту — свою нишу. Если быть последовательным и рассматривать Delphi в качестве кроссплатформенного средства, то нельзя говорить об использовании в его синтаксисе конструкций типа asm. А если хочется таких конструкций — то незачем говорить о кроссплатформенности. Это не синтаксический сахар, это костыль для забивания микроскопом гвоздей;
5. Пункт, аналогичный п. 3. Комментировать бесполезно;
6. Согласен. Во многом это следствие убогости реализации. Во многом другом — следствие его происхождения и внутренней организации. Object Pascal умеет либо в нативный интероп только на бинарном уровне. В других случаях нужно либо городить определённый протокол (справедливости ради скажу, что это нужно не только ему — всякие Corba, SOAP, REST-HTTP и т.д.), либо нужно реализовывать ещё один, так вами нелюбимый, слой бинарного проксирования;
7. Пункт, аналогичный п. 3 и п. 5;
8. А вот с этого надо было и начинать. В нашем мире есть две большие движущие силы — энтерпрайз и светлое сияние чистого разума. Когда-то Delphi уже попало в ынтерпрайз, который соблазнился низкой стоимостью разработчиков, богатой компонентной инфраструктурой и отличной интеграцией с различными СУБД. Прошло несколько лет и энтерпрайз, как это часто бывает после удавшейся эйфории, схватил сильнейшее похмелье. Дешёвые разработчики, методом «тяп-ляп» мышкой стаскивающие компоненты и пишущие glue-код без какого-либо контроля за адекватностью всего этого процесса делали абсолютно неподдерживаемые системы. Богатая компонентная инфраструктура наткнулась на бинарную и интерфейсную несовместимость не то что при разработке под разные операционные системы, а даже при разработке под разные версии Delphi. Интеграция с СУБД позволила эйфории длиться чуть больше, чем было бы достаточно для насыщения. В результате индустрия получила аллергию — и, выучив урок, стала делать ставку (не без усилий столпов индустрии типа Oracle и Microsoft) на более адекватные инструменты. Теперь для Delphi в этой нише места нет. Теперь что касается мозговой гимнастики и independent developers. Внезапно, за 10 лет в мире появилось огромное количество инструментов (в том числе ­— и метастазы энтерпрайза в мир свободной разработки в виде C#, Java). Кроме того, ещё более внезапно, появились полузакрытые и закрытые платформы, тоже играющие по правилам энтерпрайза и на похожих платформах. Разработчиков начали волновать проблемы переносимости, скорости разработки, богатства экосистемы;

Ещё раз напомнить тот анекдот про Неуловимого Джо?

Этот инструмент уже занял свою полку в истории разработки ПО, не надо его дальше трогать. Пусть лежит себе дальше с обероном, смолтолком, адой и остальными детьми своей эпохи.
по 1. Для той ниши, на которой Вы акцентировались в этом пункте — на нынешнем этапе развития есть уже HTML5 и JavaScript, не говоря уж о множестве других языков. Node.js — прекрасная платформа того уровня. Вот это — абстрагирование, кроссплатформенность и т.п. CodeGear же зачем-то ломанулся в PHP, а на JavaScript даже не смотрит… Не, оно понятно почему ломанулся — пара энтузастов уже сделала RAD PHP, похожий на Delphi, а маркетологи команды CodeGear его купили, чтобы поставить себе галочку «мы для Вас и веб-разработку поддерживаем!».
> Для той ниши, на которой Вы акцентировались в этом пункте — на нынешнем этапе развития есть уже HTML5 и JavaScript, не говоря уж о множестве других языков.

Интересно, что в первом пункте про веб-технологии не было сказано ни слова.
Да, меня это удивило.
Что вас удивило? Технологии ен ограничиваются вебом. Но вы решили за автора сообщения придумать какой-то тезис и упорно с этим тезисом бороться.
Меня удивило, что автор сообщения говорит о высокой абстракции от платформы и широкой переносимости, но ищет её в языке низкого уровня, а не в веб-технологиях. Веб-технологии уже достаточно развились для того, чтобы нигде больше абстрагированность и переносимость не искать. И разовьются ещё сильнее.
Описанное вами доступно и не в веб-технологиях. Повторю, не надо выдумывать за автора тезисы, которые он не говоил, и не надо с ними бороться :)
по 2. отладчик в Delphi один из лучших, что я видел. Среда — отстаёт по возможностям редактора от VC, но не сильно — и в последних версиях догнала во многом. По синтаксису — они добавили в последних версиях те мелочи, которых не хватало — а то, что функторы в делегатах не поддерживает — так это может быть и хорошо, и так в этот, в целом довольно низкоуровневый язык, уже просочились (ага, усилиями вредных маркетологов ;) невнятные в реализации высокоуровневые фичи, типа неявного раскрытия вариантов в диспач-вызовы и подсчёт ссылок на строки. А функтора, когда надо, я легко изображу компактным классом, в котором явно инкапсулирую нужный контекст и одну функцию. ObjectPascal — низкоуровневый язык, и должен таким оставаться. Иначе он низачем.
по 4 — асемблерные вставки кросплатформенности не помеха, если есть поддержка ассемблеров этих платформ и директивы условной компиляции. Ну вот совсем.
Согласен.
Хотя, с другой стороны, это вероятно для службы поддержки было бы адом выяснять почему что не работает для определённой платформы.
Без них — ад тот же, но не подконтролен ибо скрыт в дебрях компилятора… или фича просто не сделана.
Зачем вам нужны ассемблерные вставки?
Не понял, «зачем вообще ассемблер в коде на Pascal» или «зачем в процедурах на Pascal ассемблерные вставки, и почему б не пользоваться целиком асемблерными процедурами, которые оставили, так и не документировав ассемблер»?

Ассемблер в коде — чтобы пользоваться особенностями платформы, которыми оптимизатор ну никак не воспользуется, а сторонние библиотеки на C и ASM ещё не сделаны. Чтобы писать подобные библиотеки самому. Чтобы писали для меня подобные библиотеки прочие энтузиасты. Чтобы писать драйвера. Мало ли для чего? ObjectPascal — язык, пригодный для низкоуровневого программирования, так он должен быть пригоден полностью.

А зачес именно вставки — это ж очевидно, чтобы не писать на ассемблере вокруг вставки вспомогательный код, который можно писать на паскале…
> тобы пользоваться особенностями платформы, которыми оптимизатор ну никак не воспользуется

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

> А зачес именно вставки — это ж очевидно, чтобы не писать на ассемблере вокруг вставки вспомогательный код, который можно писать на паскале…

Ничего не понял из этого предложения. Ассемблерные вставки нужны для того, чтобы писать код вокруг ассемблерных вставок :-\
Э… А Вы вообще знаете, что такое «асемблерные вставки»?
Я знаю. Я непонимаю, зачем они вам понадобились, и вы так и не смогли внятно объяснить, зачем.
Например, инжектить вызов некоторой функции в чужой процесс. На Delphi эта задача решается в десяток строчек, на том же C# — без привлечения специально подготовленных dll-ок на C++ и ещё десятков килобайтов кода обёрток над ними вы этого не сделаете.
1. Зачем инжектить вызов функции в другой процесс?
2. Насколько часто такая задача встречается, чтобы ради нее реализовывать возможность ассемблерных вставок в код?
Кажется, Вы всё же не понимаете, ассемблер никто не отменял, было два варианта использования, и более удобный из них убрали. Второй остался. Обсуждать здесь имеет смысл то удобство, которое убрали, а не в цели наличие возможности!
1. Когда мне требуется выполнить в другом процессе определённую функцию и чтобы процесс мыл уверен, что он сам этого хотел. Наглядный пример — ingame-боты для MMORPG.
2.1 Если Вам эта задача не нужна — из этого не следует что она никому не нужна.
2.2 Возможность ассемблерных вставок реализуется не только ради данной конкретной задачи. Данная конкретная была приведена в качестве примера.

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

Никто ничего не ограничивает. Есть просто банальное простое правило: если фича нужна 1% разработчиков, то нет смысла эту фичу реализовывать и поддерживать.
Следуя Вашей логике её не реализовали в C# поэтому мы пишем на Delphi, где её реализовали.
И?

30 лет тому назад ассемблер умещался на десятке страниц, сейчас это — мануал страниц под тысячу.
30 лет тому назад компиляторы и компьютеры были тупыми и медленными, а сейчас оптимизирующие компиляторы генерят код, который человеку не под силу (если он только не имеет за пелчами 30-летний опыт программирования под конкретные системы и не знает наизусть все мелкие детали текущей архитектуры).

то есть, ассемблер сейчас вообще никому не нужен? ;)
Ассемблер сейчас вытеснили очень далеко.
Он объективно не нужен при разработке прикладных программ, и практически не требуется даже при разработке системных — модули ядра пишут на С, асма там очень мало.
Даже в эмбеддед его уже остается все меньше, оттуда его тоже С вытеснил, вычислительные мощности и качество компиляторов позволяет.

Так что применение его в современном мире *очень* ограничено.
его применение достаточно, чтобы его хотеть. И будь хорошая документация под рукой в Delphi — его бы хотели чаще и эффективнее.
Ну вам задали конкретный вопрос, зачем вы его хотите при разработке прикладных программ?
А кто сказал, что я его хочу при разработе прикладных программ? Я его хочу в библиотеках и драйверах.
Да он на фиг не сдался никому. Он нужен одному разработчику на 100 000, если не на миллион. Ради десяти с половиной человек никто корячиться не будет.
Он нужен в библиотеках, которые нужны очень многим. Только потому, что эти многие не возьмуться их писать, нельзя делать вывод, что он им не нужен.
Не хотели бы. А насчет «эффективнее» — это миф
Писать вирусы )
Также inline-assembler можно использовать для создания систем защиты кода, в delphi это делалось достаточно просто
> Писать вирусы )

Тогда при чем тут Паскаль? :) Хочется пописать вирусы на ассемблере — для этого есть IDE для ассемблера

> Также inline-assembler можно использовать для создания систем защиты кода, в delphi это делалось достаточно просто

Просто и защита кода в одном предложении говорят только о том, что никакая это не защита кода :)
по 8 — да, вы называете «энтерпрайз», я называю «маркетологи», но по сути — мы про одно. Но Вы говорите о взгляде «снаружи», где зачастую видны именно те «абсолютно неподдерживаемые системы» сделанные «методом тяп-ляп» с привлечением «дешёвых разработчиков». А я говорю со стороны тех разработчиков, которые разобрались, поняли и делают не методом тяп-ляп, а с пониманием дела. И видят потенциал, удобство и силу как языка с компилятором, так и среды разработки. И ужасаются тому, куда носит энтерпрайз веяньями буздумной моды, и как это отражается на Delphi и на том же Microsoft.

Кстати, перевод проекта с версии на версию Delphi далеко не так страшен, как его показывают. Совместимость компонентов поддерживалась на весьма достойном уровне. Единственный шаг, потребовавший хоть какого-то труда — это был переход на Unicode.

Ada, так же кстати, вполне себе реинкарнировала в PL/SQL у Oracle…
1. Нет:
* Стоимость хорошо программиста и маленького сервера меньше стоимости глупца с кластером на 800 процессоров.
* Есть задачи, которые требуют хорошей производительности на любых машинах (игры, торрент клиент, браузер)
* Разработка на низкоуровневых языках (с, с++) немного превышает сложность разработки на высокоуровневых.
* Языки высокого уровня, сейчас популярней, наверное только потому, что имеют более низкий порог вхождения.

Делфи шикарен тем, что все еще пытается оставаться языком более менее низкого уровня, имея минимальный порог вхождения.
А вот как по мне, так «проблема» в том, что Borland/Inprise/Embaracero распыляются. Как появляется новая перспективная технология, за неё хватаются, делают отдельный продукт, который получается сыреньким, а потом забрасывают. Смотрите сами:
1) Kylix — Delphi под Linux — официально заброшен в 2002 году.
2) Потом Delphi потянуло в сторону .NET. Delphi 8 — для Delphi.NET, Delphi 2005 с поддержкой Win32, Delphi.NET и C#. Поддержка C# тянулась аж до 2009 года.
3) JBuilder тот же. Пишем на Java в стиле Delphi. Тоже давно тянулся и тоже видоизменялся. Последняя версия вроде как JBuilder 2008.
4) В 2007 году вышла Delphi for Php. Позже была переименована в RadPhp. C этого года идёт под названием Html5 Builder.
5) TurboRuby и 3dRail — IDE для Ruby и Ruby On Rails. Заброшено в 2009 году.
6) В 2009 году возродилась линейка Delphi.NET. На этот раз в виде Delphi Prism. Без совместимости с предыдущими версиями Delphi.NET. До сих пор живёт.
7) И только в 2009й версии язык Delphi получил наконец долгожданную поддержку юникода, дженериков и анонимных методов.
8) В 2011 году вышла Delphi XE2 в которой появилась поддержка Win 64-битного компилятора. А заодно и MacOs, и iOS и FireMonkey. + наконец появились LiveBindings Казалось бы, вот он прорыв. Но народ что-то не спешит массово мигрировать.
9) Наконец, недавно вышла XE3 с FireMonkey 2, доработанным компилятором под MacOs и многим другим. Пропала поддержка iOS. Вероятно, погорячились ребята с iOS-ом

А были ещё Bold For Delphi, была Corba и Midas, потом был DataSnap, потом был новый Datasnap. Потом был самый новый Datasnap. Который, кстати, хвалят.

Как видно, компания не стоит на месте и двигается в ногу со временем. В смертельном марше камикадзе (отсылка к названию книги). Новые языки, новые IDE то и дело сменяют друг друга. А старый добрый Delphi — тот самый легендарный Delphi для Windows, который и сделал эту компанию знаменитой, потихоньку побирается остатками со стола господ. RTL и VCL не переписывалась со времён Delphi 6. Да, там появилялось что-то новое. Дополнялось старое. Компилятор безусловно стал лучше. Но не то, чтобы VCL сильно двигался вперёд. Зато, теперь есть Firemonkey, Красивый, кроссплатформенный. А также тормозной и без особой поддержки сторонних вендоров. (в отличие от VCL).

Зато в VCL всё, что комиплировалось тогда будет компилироваться и сейчас (иногда после доработки напильником, иногда и без неё). И это очень хорошо, потому что огромнейшая часть открытых библиотек и компонентов для Delphi последний раз обновлялись в начале прошлого тысячелетия. Как раз для версий Delphi 5-6-7.
в начале ПРОШЛОГО тысячелетия??? ого… Вы из будущего чтоли к нам пишите?
Ну конечно, имелось в виду в конце прошлого/в начале этого.
Насчёт RTL — это вы зря. Для меня XE3 — это первая из последних редакций, о которой я могу точно сказать — хочу! Не из-за всяких FireMonkey и иже с ними, для меня это мишура, хотя на обнавлённый live bindings хотса взглянуть. Что для меня важно так это именно обновление в RTL!!!
Всё, теперь никаких Length(someString), IntoToStr, StrToInt… и прочего. Теперь, наконец- то, я смогу писать так:
    SomeString.Length();
    MyInt.ToString();
    SOmeString.ToLower();
    ...

Благодаря возможности написания хелперов к простым типам данных. Теперь можно будет писать так (взято с www.webdelphi.ru/2012/09/delphi-xe3-obnovleniya-v-rtl/, где и можно почитать подробнее):
    type
         TIntegerHelper = record helper for Integer
             function ToString: string;
         end;
//....//
function TIntegerHelper.ToString: string;
begin
  Result:=System.SysUtils.IntToStr(Self)
end;   


А вообще язык развивается, несмотря на выпадки со стороны.
Вот эту штуку я пропустил как-то, пока сегодня не увидел пост:
SomeString.Length(); MyInt.ToString(); SOmeString.ToLower();

А ведь давно не хватало таких штук. И главное, самому можно свои хелперы использовать и добавлять свои методы.
Live Binding предыдущий был с чрезмерно тяжелым оверхедом на мой взгляд. Перенаворотили. Парсинг строк вечный зачем-то…
Вставлю свои пять копеек. Делфи для меня мощный инструмент, которым я могу решить огромную кучу различных задач легко и быстро — за это я его уважаю и держу на своём рабочем компе. Коменты вида «делфи сдох» — были всегда, и я думаю будут ещё долго встречаться в любом посте в котором прямо или косвенно автор затронет этот продукт. Теперь немного статистики: сделал пару проектов на делфи (2D opengl движок и некое подобие объектно-ориентированной СУБД) довёл их до ума, использовал в своих проектах и выложил в свободный доступ (вдруг кому пригодится). За 1,5 года которые они лежат в свободном доступе ко мне обратились 3(!!!) человека, которые использовали эти наработки в своих проектах. Руки опускаются просто…
Похожий случай.
3 год потихоньку пилю свою билд-машину для Delphi. Главная фишка — автоопределение зависимостей.
Количество обращений с вопросами, советами — в среднем 2-3 в год. =)

Хотя, я сам виноват. Вообще забил на какую-либо раскрутку. Ибо пока всё слишком сложно у меня сделано. Слишком много нюансов надо знать, чтобы всё настроить как следует.
Вот за это — спасибо, давно мечтаем о компиляции батником нашей группы проектов. Когда-то пробовали, не сложилось, вашего проекта не нашли.

А информацию о версии в ресурсы проектов оно умеет вносить?
Нет, не умеет. Я не планировал такое реализовывать, и пока не представляю каким образом это можно сделать так, чтобы это было удобно использовать. И совсем не уверен, что это вообще хорошая идея. =)

Имхо, для таких случаев лучше выносить информацию о версии в отдельный .rc файл, подключаемый к проекту (или компилируемый в .res вручную), и изменять информацию о версии именно там.

Вот, например, готовый рецепт.

Вот ещё ссылка по теме: Обсуждение «Delphi .res file changer» на StackOverflow.

Если не сложно, то напишите пожалуйста (на email или в личку), удалось ли разобраться с LazyDB, настроить под себя, и том какие трудности возникли при настройке.

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

Должна быть общая папка Build (т.н. base folder) с подпапками:
* Bin — папка для exe и dll
* Dcu — папка для .dcu (release)
* DebugDcu (опционально) — аналогично для .dcu файлов с отладочной информацией
* Bpl — папка для .bpl
* Dcp — папка для .dcp
* Res — папка для ресурсов (опционально, если включено копирование ресурсов)
Хм… лично я пока даже не понял, что мне с ней надо разбираться. А мне надо?
я её использую для сборки проекта из командной строки. Достаточно один раз настроить и получается отлично. У меня скрипт, который вытягивает свежую версию из svn, собирает res файлы на основе номера версии и потом lazyDB производит окончательную сборку. Осталось только запуск тестов к этому делу прикрутить и подключить к jenkins…
Спасибо, что поделились своей историей.
Приятно слышать о том, что LazyDB реального используется в деле. Я таких случаев знаю очень мало — менее десятка. Число скачиваний велико, а вот с отзывами негусто. =)
Не за что :) Я думал о том, чтобы настроить автоматическую установку компонент, но это только в планах. Самый большой плюс для меня — это возможность импортировать из Delphi все пути к используемым компонентам — это сильно упростило жизнь.

Кстати я даже что-то писал в гугловский багтрекер и получил желаемую фичу, спасибо )

Что хотелось добавить…
Сейчас для сборки .res файла у меня состоит из двух этапов
1) с помощью SubWCRev.exe, которая идёт вместе с TortoiseSVN создаю новый .rc файл
2) с помощью сборщика ресурсов Delphi создаю готовый .res файл

Так вот… автоматизация сборки res файлов вполне сгодилась бы как фича к LazyDB. Только без привязки к SVN, а с возможностью использовать любую систему контроля версий (например через дополнительные параметры в командной строке). Думаю, что это актуально для новых пользователей, старые наверняка уже решили эту проблему своими силами.
> Хм… лично я пока даже не понял, что мне с ней надо разбираться. А мне надо?

Я не уверен что уловил смысл, который вы вложили в эту фразу. Если это что-то важное, то поясните пожалуйста другими словами.

В своём предыдущем комментарии я предположил что вы заинтересованы в том, чтобы попробовать Lazy Delphi Builder для сборки своих проектов. У меня очень мало отзывов об использовании LazyDB (буквально, пара мейлов в год, в основном с вопросами «как настроить») поэтому я попросил рассказать о своём опыте. Зная, что при настройки обычно вызывает сложности я про них рассказал.
Извините, мой глюк. Я не смотрел ещё в подробностях Вашу собиралку, и даже ещё толком не отметил для себя, как она называется (только сейчас допёрло что LazyDB — это она и есть, Lazy Delphi Builder, а не какой-нибудь движок базы данных, как-то с ней связанный!).
В связи с тем, что Embarcadero перевели файлы проектов на MSBuild, потребность в стороннем внешнем сборщике отпала раньше, чем мы до неё добрались.

Спасибо им за это.
Ну если вдруг нахлебаетесь с настройкой путей в каждом проекте — то милости прошу попробовать Lazy Delphi Builder. Впрочем, в Delphi насколько я помню можно указывать внешние профили сборки, и это позволяет упростить настройку путей — так что msbuild это тоже очень хорошо. Для сборки 1-2 проектов идеально (просто).
За билд-машинку — огромное спасибо! К середине 2015 года я её-таки нашел. Может, популярности нет потому, что её найти никто не может? :)
Время Delphi прошло. Пора с этим смирится. И я раньше писал на Delphi, потом на C++ Builder. Да, было круто. Но это прошло. Сейчас другое время!
В Enterprise секторы для разработки Windows приложений есть .NET, для разработки качественных веб-сервисов есть Java. Все!
Уважаемый, а не расскажите ли как Вы собираетесь защищать свои .NET и Java приложения от реверс инженеринга?
Я-то на свои дельфёвые повешу VMProtect или Safengine и буду спать спокойно. А вот вы против deob'а + Reflector'а ничего сделать не сможете.
Надёжная защита — часть кода на сервере, за этим будущее.
У .NET/Java работа с веб-сервисами проще реализовывается.
Если у меня калькулятор не будет открываться без интернета — я найду авторов и…
Зачем защищать калькулятор? Популярный каклькулятор с любой навесной защитой сломают, как ни крутись, а слишком навороченная защита будет доставлять неудобства пользователям.
Прочитал все вышесказанное. Со многим согласен. НО! Проблема ведь не в языке! И не в политике Embarcadero. Дело скорее в отсутствии профессионального комьюнити Delphi-разработчиков. Delphi стал популярен именно благодаря очень низкому порогу вхождения. И из-за этого низкого порога языком стали пользоваться тысячи быдлокодеров (студентов, выпускников непрограммистских специальностей и т.д.). И тот факт, что они были быдлокодерами, не мешал им создавать довольно сложные, работающие системы! Да, системы создавались не по правилам, весь код писался в обработчиках типа ButtonClick(), но тем не менее задачи автоматизации решались. На тот момент разработчики просто не задумывались о том, насколько быстро и масштабно могут изменяться требования к системам, какие усилия придется потратить на сопровождение, поиск ошибок, рефакторинг и реинжиниринг. Конечно, свою ложку дегтя сюда влили и разработчики Delphi, которые в справке к языку размещали как раз таки быдлокодерские примеры кода. Примеры хороших архитектур на основе RTL/VCL найти было сложно. Паттерны проектирования еще не были столь популярны, как сейчас. Тем не менее, профессионалы могут писать на Delphi очень качественный, понятный и простой код. Посмотрите, например, в исходники OmniThreadLibrary (библиотеки многопоточного программирования для Delphi) — там очень красивый и качественный код, использующий в значительной мере именно новые возможности языка. Ну и кстати высоконагруженные программы на Delphi исполняются в разы быстрее (высоконагруженные — это такие, которые утилизируют проц и память на 100%), чем аналогичный код, написанный на C# (до 3-х раз быстрее на примитивном коде, выполняющем математические операции, проверялось профилированием).
Ну утилизировать проц и память — естественно не проблема. А вот написать программу достаточно производительную, при этом не утилизирующую проц — вот где искусство!
Вы, видимо, мало работали с многпоточностью. В многопточных приложениях сбалансировать нагрузку, чтобы утилизировать все ядра проца на 100% — довольно не просто. А при активной работе с памятью в дефолтный менеджер памяти Delphi (FastMM) вообще не позволяет это сделать (т.к. у него по сути стоит критическая секция на операцию выделения памяти), т.е. вся многопоточность упирается в выделение памяти. Приходится искать альтернативные менеджеры памяти, которые лучше масштабируются для многопоточных приложений (TopMM например).
Паскаль близок к железу никогда не был.
Нормальным ООП никогда не обладал.
Все что вы перечисляете есть в C/C++
Так же мы имеем отличный и кроссплатформенный C++ Framwork QT4, который идет в комплекте с отличной IDE.
А Delphi? Развиваться? Ну разве что в небытие! И как можно скорее!
Паскаль был создан для обучения программированию. Пускай останется на первых курсах институтов. (а я бы его и оттуда уволил)
Сижу с Delphi 7. И с ООП там все отлично, даже интерфейсы есть, которых кстати нет в С++.
Интерфейсы это хорошо. Но в С++ можно создать класс с чисто виртуальными функциями — вот вам и интерфейс.
Что касается Delphi, то я как и многие здесь начинал с него и с Pascal, еще в школе. И мне нравилась эта технология, я мог быстро создать то или иное решение. Но, в свое время перешел на С++, сначала Builder, потом Qt. Просто когда начинаешь работать в сторону open source, иного варианта просто нет имхо.
Но это здорово, что Delphi развивается, не вижду ничего плохого в этом. Иногда меня просят сделать ту или иную программу именно в Delphi. Delphi это хороший и удобный инструмент, но иногда не хватало некоторых вещей. Например, множество свободных юиблиотек, которые я использую всвоих проектах написаны на С++ и их крайне тяжело портировать в Delphi, плюс к этому для С++ существуют удобные бесплатные IDE, такие как Qt Creator.
У меня аналогично мнение и история, но какое это отношение имеет к моей критике в сторону утверждения предыдущего комментария «Нормальным ООП никогда не обладал».
Я среагировал на «даже интерфейсы есть, которых кстати нет в С++.»
Ну вот интерфейсы-то в Delphi из COM пришли, и оно почти родное для C++
COM позиционировалась как языково-независимая. IDL, такое понятие есть.
Так что степень «родственности» спорна. То, что «виртуальная таблица» случайно попала на нулевой адрес в С++ — просто особенность реализации абстрактного базового класса в С++.
Они зафиксировали в спецификации бинарную структуру класса C++ и сказали «мы это вот менять не будем, приспосабливайтесь спокойно» — спозиционировались как языково-независимые, ага. И все кто хотел приспособились, ибо не особо сложно…
Да, это действительно так, спасибо за напоминание.
Но сейчас проблема (и в Дельфи отчасти) — избавится от СОМ-а, который в условиях мультиплатформенности (МаОС как минимум) — блин стала тормозом.

И в свое время люди, гордившиеся СОМ-кодированием в Дельфи (или вообще использующие DCOM для модульной структуры), теперь (есть такое) немного впали в уныние. Под FireMonkey прямого порта нет.
Да, а подходящего уровня абстракции в VCL не было предусмотрено, в частности в силу бывших ограничений языка (мне кажется, сейчас примесь интерфейсности можно было б иначе реализовать). Я сильно удивлялся, когда TComponent стал IUnknown поддерживать…

С другой стороны — прямой порт под FireMonkey и не должен быть. Должен быть конвертер, с хорошо документированными решениями и компромисами, заложенными в его основу. И неплохо бы иметь дополнительный уровень абстракции повыше, покрывающий обе технологии, и конвертер, переводящий желающих на него с обеих.
MIDA дает некий (я думаю, не абстрактный, а «брутальный» конвертер), мы даже его до 28 числа бесплатно даём вместе с ХЕ3. Я в него не верю.

>>дополнительный уровень абстракции повыше, покрывающий обе технологии,
Не, ну ты уже в космос полетел :)
Понимаешь, нужно дать FireMonkey устаканиться. Пока он только-только застабилизирована (структурно, рефакторинга много было с ХЕ2, поэтому и назвали FireMonkey 2.0).
А потом — возможно, абстракция не помешает, чтобы людей всё-таки с VCL на FM сдёрнуть.
Это — да, может быть… подхватите и часть стабильной аудитории плюшками кросс-платформенности, за которую они заплатят убогостью интерфейса. Но многие будут смотреть чуть дальше, на современные веб-технологии, и будут правы.

Но все понимающие — ждут пару слоёв обёрток над родными контролами альтернативных OS — тонкую и поверх неё абстрактную.
Мужик, харе. Реально утомил.

Ты стили в FireMonkey видел? Они «с точностью до пискеля» воспроизведут любой нативный контрол, они векторные, с эффектами, т.к. базируются на OpenGL/DirectX.

>>Но все понимающие — ждут пару слоёв обёрток над родными контролами альтернативных OS — тонкую и поверх неё абстрактную.

Ну не в теме ты. Нет такого уже понятия — «родной контрол», забудь ты эти метафоры! FireMonkey есть «надстройка» над OpenGL/Quartz/DirectX. И не будет больше «родного» контрола. И стили FireMonkey дадут тебе любую возможность, хоть 1:1 воспроизвести что МакОС, что Windows 8 Style.
Да ладно, не мешки ворочаете.

Про то, что больше нет понятия «родной контрол» трём другим четвертям целевой аудитории рассказывайте. Авось, поверят на минутку…
Расскажи(те, блин, тут все нежные) мне про «родной» контрол? А?
Только чтобы я не запутался, это будет про WinForms или WPF?
Ну и ссылки на web-технологии создания интерфейса тоже.

Так что же такое — «родная кнопка Windows»? :)
А кстати, в тему — Эмбро не планирует предложить стили, которые точь в точь копируют нативные под различные семейства, хотя бы, того же win (Имею ввиду, что, к примеру, радиобаттоны в XP, 7 и 8 существенно различаются).
Срам-то какой! Нашу ругань читают приличные порядочные адекватные люди. Я уж думал, этот ср@ч никто не видит!

>>Эмбро
Можно до «Э» сократить, сам так делаю :)

Хей, отличный вопрос. По-умолчанию в зависимости от платформы приложение FireMonkey сразу применяет к себе «стиль» (а без стиля компонент FireMokey вообще себя никак не рисуется). Если платформа «винда», то применяетс «виндовый стиль», если «маковский», то маковский стиль.
ХЕ2 стилизовала только Клиентскую часть окна, поэтмому заголовок окна, системные меню и боты генерились самими ОС-ками. Поэтому в не-клиентской части все ок из 7 в ХР.
ХЕ3 стало уметь делать и это, но вопрос про другое.

Про радио-кнопки. Сейчас я проверяю дефолтный стиль, врубающийся автоматом… Не, радио-кнопки не стилизуются. В смысле, они у меня «курасивые» на «сёмке», и на ХР остаются такими же. Ну да пользователи простят.

Для Windows 8 есть специальная штука, называемая Metropolist — стилизация под Metro. Там специально разработанный стиль очень удачно эмулирует look&feel «восьмёрки». В ХЕ3 есть конвертилка даже для VCL-интерфейсов в стиль Windows 8. Но в отличие от FireMonkey процесс необратимый.
Либо перефигачили на Metro и с этим и живём, либо продолжаем использовать предыдущий стиль.
Не, отделного old-style Windows XP стиля не видел. До 28 сентября всем, кто купит XE3, получит в подарок коллекцию офигенистический стилей для FM, разработанных проф. дизайнерами.
(как я себя ненавижу за это! контекстная реклама… попытка продать на тех. конфе… :()
Да, я понимаю механику стилей, но вопрос в другом — FM рисует сама себя. Соответственно, для того что бы сэмулировать нативный внешний вид нужно создавать свой файл стилей.
К примеру можно посмотреть на различия во внешнем виде radiobutton



Вот мне и интерестно, планирует ли Эмбро разработать стили для каждой ОС, или останется так же как сейчас — для Win один общий стиль, для Mac — другой.
А, поспешил с комментом. Спасибо, понял.
Под новые — да, под старые — нет. Я думаю, пользователи ХР не сильно обидятся, если увидят чуть более красивые кнопки.

>>Вот мне и интерестно
Мне тоже интересно. Проверить легко, если в течение полгода кто-нибудь хоть раз спросит о «нативном ХР-интерфейсе», то мы хоть с Вами будем знать степень востребованности этого. Пока сказать сложно.

А вот то, что Яблочники жизеют, когда ты им сполпня генеришь приложение не «мастдайевского типа», и именно их «нативное», то это — факт.
Как экспорт данных из таблицы в Excel. :)
Как это не был близок к железу? Вполне себе был, вспомните времена DOS и VGA 320x200x8bit. Сколько всяких эффектов на паскале писалось, причем большая часть программы состояла из ассемблерных вставок (главные циклы) и лишь рутина — на паскале, типа подготовка таблиц синусов и тд. Очень удобно было.
UFO just landed and posted this here
Они убили Кенни! Ещё когда бросили Kylix и пошли в .NET. На этом фоне очень радует что free pascal и lazarus живы.
ну, не так уж и убили пока… А ведь да, как-раз, как Кенни. Каждый раз убивают, и каждый раз он опять живее живых…

Lazarus и fps да, радуют, но им ещё расти и расти… И кстати, подвижки в том же направлении что я расписал для Delphi — были бы хороши и очень уместны.
Я тоже считаю, что развиваться надо не дельфи, а программистам на дельфи. Развивайтесь и переходите на нормальные платформы. А то этот пост больше похож «куда развиваться памперсам, а то я уже в школу хожу, неудобно, некрасиво, зимой холодно, почему им длинные штанины, мех и черный цвет не делают?»
Недавно написал пост про «Экосистему Delphi», как выяснилось, написал не зря. Собственно, уважаемый автор, Вы явно попадаете в категорию «IT-экспертов», что с одной стороны уважительно, а с другой лишает Вас объективной точки зрения на происходящее. Правда начну с тех «экспертов», которые пишут «Дельфи в могилу». Конечно, мы воспринимаем действительность через призму индивидуальности. А мне, как евангелисту Embarcadero, приходится а) иметь максимально объективную точку зрения б) деперсонифицироваться. Первое достигается за счет понимания «экосистемы» и изрядного опыта работы как «простым кодером» (т.е. я был основной массой прикладников) и видения ситуации изнутри компании. Второе (напоминаю для тех, кто с трудом читает мои мысли — «деперсонификация») — я очень много общаюсь с разрабочтиками разного уровня. Вебинары — по 100 человек в неделю, семинары (в примерно таком же объеме). Но есть и работа на индивидуальном уровне. Буквально вчера я обсуждал с потенциальным приобретателем Delphi проблемы доработки существующих пакетов для обработки изображений с томографов средствами Delphi. Знаете, FireMonkey ему нравится, т.к. соответствует его целям.

Вернемся к «индивидуальности» и «дельфи в могилу». Человек, который пишет так, отвечает за себя и свое отношение к Delphi. Поверьте моему опыту (метрикой которого является личное общение с более чем 1000 программистов + 300 выученных много кодеров, когда я работал Delphi-тренером) — просто конкретный человек «хоронит Дельфи для себя». И, что вполне возможно, не «дельфи», а «средства разработки вообще», и возможно даже «себя-программиста». Это вполне естественно, что устал человек кодить, хочет стать начальником кодеров или продавцом программных продуктов или вообще сменить IT-деятельность. А виновата в этом Delphi? Здесь нужно посмотреть вглубь себя, разобраться со своим желанием что-то похоронить (большинство согласится со мной, что даже на уровне лексики это ненормально).

Ну не вижу я реальных доводов в пользу того, почему вдруг нужно перестать развивать Delphi. А вот факты в пользу того, почему нужно продолжать:
— Delphi — очень востребованная технология, рост продаж 54% в период с 2011 под 2012 г.;
— Delphi продолжает быть практически безальтернативным средством нативной разработки (Qt? не, не слышал);
— Delphi имеет блестящее будущее за счет платформы FireMonkey (кто следит за эволюцией средств разарботки, плиз, вспомните, что .NET 1.0 и VCL в Delphi тоже не были образцом стабильности, вопрос времени и хорошей команды, которая сейчас российская);
— мультиплатформенная нативная разработка практически не имеет проблемных мест, а модульные компиляторы являются приоритетным направлением Embarcadero (и без советов :))

Ну а людям, которые кричат «зачем нам Delphi, когда есть .NET, Java и Qt», хочу посоветовать следующее. Зайдите в салон Volkswagen и покричите — «зачем на Volkswvagen, когда есть BMV, Opel, Mercedes и Daewoo Matiz». Опять же, сходите на футбольный матч «Спартак-Зенит» и расскажите про то, что «зачем ребята бьются, стараются, когда есть Анжи». Такие законы здоровой конкуренции, которая не позволяет монополизированным технологиям впасть в застой. Мужики, с чем воюете? :)

А теперь вернусь к автору статьи (коему я благодарен за абсолютно правдивую и честную исповедь). Вы принадлежите к группе «IT-экспертов», поэтому Ваш взгляд однобок и необъективен. Есть куча доводов в пользу этого. Начиная от «я считаю» и «меня раздражает» — личностный контекст. Заканчивая феерическим:
>>Вопрос только — что тут и как продавать?
>>Какой могла бы быть успешная стратегия монетизации подобного проекта?
Еще раз, Вы принадлежите к одной из четырёх групп, у Вас — свои интересы, оптимизация технологии Delphi не означает её максимальное соответствие потребностям других групп. И не благотворно скажется это на экосистеме в целом.

>>Лазарус с FreePascal вон догоняет, и теоретически тоже может всё это сделать…
Опять, Вы строите гипотезы, а я общаюсь с реальными людьми. Была у меня беседа с участником данного проекта. На семинаре в Краснодаре. Человек честно сказал — да, по стабильности нам до Delphi далеко. И пришёл я на семинар по Delphi, так как на работе использую Delphi. Но у меня и группы единомышленников есть хобби. И мы им занимаемся.
И это создаёт мировую гармонию как внутри человека, так и как части экосистемы Delphi, которая имеет еще компоненты, помимо названных четырёх. Правда для Embarcadero они не так важны.
«Буквально вчера я обсуждал с потенциальным приобретателем Delphi проблемы доработки существующих пакетов для обработки изображений с томографов средствами Delphi. Знаете, FireMonkey ему нравится, т.к. соответствует его целям.»

Не удивлён — там есть довольно качественный 3DCanvas, который давно все хотят, и кто хотел — сделал или обошёлся, там есть кросплатформенность, которая в свете пиратских войн нынче всё критичнее, там есть контролы, которые тормозные, убогие и не родные для платформ — но всё же есть, и можно обойтись. Зато есть 3DCanvas и кросплатформенность. И всё это на фоне Delphi, который и язык, и среда, и дизайнер форм. Бочка мёда в наличии, несомненно! Но без ложки-то дёгтя не обошлось, и позиционируется она как цистерна амброзии, и тянет развитие не туда.
ой, опять человека за язык брать придётся. Как-то на хабре не принято за базар отвечать.
Итак, приступим :)

>>позиционируется она как цистерна амброзии
Ссылку, пожалуйста, или берите слова обратно.

>> убогие и не родные для платформ
зачем программисту Delphi «родные» компоненты? И в чём их смысл? Вот я использовал «шедьюлер» от DevExpress, имитирующий календарь Outlook на Delphi-кодах. Это как? он родной или нет? или я делал неправильно?

>>и тянет развитие не туда.
Ой, а лично Вы (Nashev) знаете, куда правильно? Ну так валяйте, перед Вами представитель Embarcadero, я сейчас прям письмо Крюкову или John Thomas-у напишу и копипаст не постесняюсь сделать.
Куда правильно — я писал в топике.

родные для платформ — чтобы работали в стиле платформы, не выглядели чужеродно, не болели детскими болезнями, которые родные уже преодолели давно, имели все возможности, которые привычны пользователю платформы. Очень жаль, что представитель Embarcadero этого не понимает (или делает вид, в угоду раздувания коммерческой привлекательности цистерны FireMonkey?).

Что касается цистерны — это образ, метафора, её я тут сам придумал, и конечно слогана «FireMonkey — это цистерна амброзии для Вашего бизнеса» я на сайте Embarcadero не найду. Но он отражает мой впечатление от подачи этой библиотеки и её возможностей на сайте и семинарах.

Уважаемый Всеволод, Вы не с тем боретесь! Не надо со мной воевать, я добра вам желаю и люблю Delphi.
>>Куда правильно — я писал в топике.
Ок, примем демократическую модель выбора стратегии развития. Она приблизительно такова, т.к. покупая, люди «голосуют бумажником» (54% рост продаж). Вы думаете, что с «портом Qt» и «моделлером» Вы далеко уедите? Вы думаете, что прямая врубка asm-кода кого то сильно волнует?
Да, я знаю пару-тройку крутых команд. Ну чё, вынесли люди в отдельные блоки и никто не плачет.

>>Очень жаль, что представитель Embarcadero этого не понимает
Что я не понимаю? Что некто Nashev хочет какой-то пирожок для личного удовольствия? А потом пытается этот «пирожок» представить единственно правильным направлением?
Да ну я не против. Давайте! Только чтобы этот пирог нам тоже пришелся по вкусу.

>>в угоду раздувания коммерческой
Мужик, ты напиши открытое письмо Е. Крюкову и команде питерских (в обычном значении этого слова), что де имнужно немного поработать бесплатно, не думая о том, насколько востребованным будет релиз. Ну или сам пару зарплат пропусти на работе, а напиши хороший, но бесплатный учебник по программированию.

>>Но он отражает мой впечатление от подачи этой библиотеки и её возможностей на сайте и семинарах.
Малаца! Придумал за нас метафору, а теперь с ней воюешь.

Это уже моя злость не за Delphi, а за отрасль. Мне и за Windows 8 обидно, когда её смешивают с… короче, метафоры на ней оттачивают.

Хотя могу и своей Вас порадовать. iPad — аппаратная часть игровой приставки «Angry Bird». Смешно? Не думаю, что яблочники смеяться убдут.

>>Не надо со мной воевать, я добра вам желаю и люблю Delphi.
Ну тогда встаньте на сторону добра. Что Вы в порыве «непризнаного критицизма» нормальных «быдлокодеров» (сам таким был) с понтолыку сбиваете? Что Вы кликушествуете «Дельфи умерла, Дельфи умерла»! Направление неправильное! Мы все умрем!
Ничего не умрем, направление правильное.
Я не говорил, что дельфи умерла
Считать fpc не стоящим внимания чьим-то хобби опасно для маркетологов Delphi, но программисты Delphi уже отдали ему должное, использовав для кросс-платформенной компиляции на первых этапах.

Удовлетворение нужд толп быдлокодеров и подверженных моде менеджеров команд программистов (и какая там ещё ода группа?) — наверно, коммерчески верная стратегия. Грустно, когда она отнимает время от реального развития основы этого бизнеса — языка и среды Delphi. Но, возможно, иначе и впрямь никак…
Nashev, отвечайте за базар!

>>Считать fpc не стоящим внимания чьим-то хобби
Я написал, что САМ человек, участник проекта, так рассказал про него. Зарабатывает деньги программированием на Delphi.

>>но программисты Delphi уже отдали ему должное, использовав для кросс-платформенной компиляции на первых этапах.
Ну Вам, конечно, виднее. fpc использовался как временная мера при поддержки iOS.

>>Удовлетворение нужд толп быдлокодеров
Вы обзываете очень большое число людей, чьи коды Вы никогда не видели.

>>наверно, коммерчески верная стратегия.
Продажи Delphi — это ресурс платить R&D для дальнейшего развития продукта.
У Вас есть другая схема в голове?

>>Грустно, когда она отнимает время от реального развития основы этого бизнеса — языка и среды Delphi
Вы много знаете о бизнесе Delphi? Не судите по утечкам.

Еще раз — какая на Ваш взгляд «правильная» стратегия развития продукта Delphi? Ну, поделитесь. Всем же ужасно интересно.
> САМ человек, участник проекта…

И что? Я тоже иногда на тот проект поглядываю, пытаюсь что-то в нём сделать и понимаю, что стоит в нём поучавствовать в режиме хобби… Отношение одного из участников к проекту ни сколько не говорит о перспектиивности этого проекта. Можете мой мнение взять и махать им в противовес тому.
Да-да, у нас пошла уже смесь «Бойцовского клуба» и «панк-молебна». :)

Просто сам чувак грустными глазами смотрел на меня и думал (глазами), типа «мил человек из Эмбаркадеры, мы бы вас реально догнали бы и перегнали, будь у нас такая… ресурсная база».
А я ему глазами тоже семафорил «мужик, ну нет у тебя доводов, чтобы наших дельфистов перегнать на лазарус».
И рад я был, что человек был честный, умный и культурный, стояли мы рядом, базарили базары, ели бутерброды и пили кофе.
Кстати, у Lazarus никогда не было цели перегнать кого-то с Delphi :) Кроме того. Lazarus никогда не рассматривал Delphi как врага или конкурента. Многие были бы рады, если бы команда Delphi нашла бы точки соприкосновения с командами FPC, Lazarus (например, организовать площадка для обсуждения развития языка).

Мы не зарабатываем на этом деньги (поверьте, даже кнопка donate появилась всего 3 года назад по просьбам сообщества пользователей), мы это делаем для души, для самообразования.
Как здорово, что все мы здесь сегодня собрались.
Надеюсь, эту ветку прочитают те, кто кричит — «ой, хороним дельфи, у нас есть лазарус».
Lazarus — технология, абсолютно дружественная Delphi, мы просто не хотим противопоставлений.
Спасибо, что честно написали про проект (не все здесь понимают это).

Александр Алексеев занимается выпуском русской редакции BPM, я некоторое время участвовал в переводе его на русский язык, включая статьи про Lazarus. Если хотите помочь Александру в этом — опять же — гуманитарно-просветитительско проекте — он (и все мы) будем рады.
Наверное, это будет здоров, что статьи про Lazarus на русский будут переводить именно участники проекта. Знаете ли, мы — дельфисты, можем случайно попутать что-нибудь :)

Пишите мне, я с Александром Вас синхронизирую.
Спасибо Всеволод, я уже и так в той бригаде состою. Переводил одну статью, но последнее время его (этого времени) на переводы совсем нет :(
Аналогично.
Помню, попарились мы над статьей «разработка на Pascal для Android». :)
> Вы обзываете очень большое число людей, чьи коды Вы никогда не видели.
Я говорил о том, о чём говорил. Я не говорил о людях, чей код я никогда не видел. Это Вы передёргиваете, почему-то увидев во мне врага…
Ну да. Delphi в опасности. Куда ни кинь, всюду пепелище. Стон и плачь. Панк-панихида.
Только не совсем ясно, человек говорит «я фанат дельфи» и тут же «дельфи кирдык».
Где оптимизм? :)
я не говорил ничего даже отдалённо похожего на «дельфи кирдык»
> Продажи Delphi — это ресурс платить R&D для дальнейшего развития продукта. У Вас есть другая схема в голове?
Нет, именно поэтому в конце топика был тот «феерический пассаж». И — я же не против, я говорю лишьо том, что перегибы вселяют грусть…
Не, перегибов нет.
Просто — да — к коммьюнити тоже есть вопросы. Сообщество должно сказать — мы в одной лодке с Э или нет?
Что-то пока не очень.
Четыре фамилии — Баженов, Божко, Терехов, Чмель, всё, скукожилось до 4 человек. Нет бы поисследовать FireMonkey, написать свой компонент.
Я дык помню, что во времена VCL весело с огоньком и бесплатно (ах, какой я халявщик) люди косяки выправляли и соревновались, кто лучше тупой стандартный DBGrid переделает. А теперь шо?
Я два конкурса объявил на проекты на FM. Но мало кто почесался просто ради интереса попробовать.
да кому нужна эта обёртка-однодневка? 3DCanvas от неё — он да, великолепен, а контролы — увольте.
о, опять занос. Хочу напомнить, что FireMonkey стала развитием (прототипом, предтече) весьма популярной библиотеке компании KSDev. Так что еще не будучи FireMonkey она доказала свою жизнеспособность, популярность и востребованность.

Дальше, именно FireMonkey даёт нам кроссплатформенность, а VCL нет за счет слишком тесной интеграции с WinAPi.

Кроссплатформенность — только набирает обороты.
DiectX и OpenGL — тоже не собираются умирать. Особенно обе две.
Почему вдруг FireMonkey стала однодневкой? (надоело ругаться, но работа такая)
Мои два цента (от технаря, больше всего опасающегося связей с технологиями, которые будут заброшена через пару лет):

> Почему вдруг FireMonkey стала однодневкой?
Потому что наблюдая за метаниями Delphi впечатление именно такое складывается. Я выше писал уже, откуда такое впечатление у меня скложилось. Повторюсь: потому что было время когда был Kylix (прорыв!), Delphi.NET, (вынесу в скобки Delphi4Php, Delphi для Rails, JBuilder), Corba, Bold (и даже FM1 для iOS) и все продукты точно также были очень перспективными. Но, c'est la vie, поддержки больше нет.
Ходят слухи, что часть сообщества до сих пор безуспешно просит отдать Bold в OpenSource. А ещё говорят, что тот же Kylix до сих пор поддерживается энтузиастами в виде проекта CrossKylix имея на 2010 год около 1000 скачиваний в течение первой недели на каждый новый релиз.

А мы… а мы пока ждём, когда какой-нибудь крупный вендор скажет «Добро» и выпустит свой cx Quantum Grid для FM2-а. И тогда все кого это касается выдохнут с облегчением и скажут, раз девки там, значит и мы пойдём и мигрируют свои проекты.

>>Потому что наблюдая за метаниями Delphi впечатление именно такое складывается.
Давайте анализировать с того момента, когда CG приобрела Embarcadero. Ну где-то с 2009-2010.

Kylix ушел, т.к. количество десктопов, для которых на нём можно было писать, упало до критической величины. Нет смысла.

1000 скачиваний — это круто, но инсталляционная база Дельфи — 1.7 миллиона.

Quantum Grid для FM2? Да, тема хорошая. Пока есть TMS Grid. Кто-то из более верящих в нас партнёров отрелизился под FM2 (FastReports, TChart), кто-то ждет. МС-ники, думаю, заняты W'8 по-полной.

>> А ещё говорят, что тот же Kylix
А ещё «киликс» до сих пор продается компанией Embarcadero. В смысле, он «покупается».

>>Delphi.NET
Всегда был уродством.

>>Ходят слухи
Вот я здесь, чтобы слухов было меньше.

Вот ту самую библиотеку компании KSDev лучше вообще не вспоминать. Это было феерическое урочище и большинству своих конкурентов оно всасывало, уж простите за жаргон. Вы напомнили, мне аж не по себе стало. Оттуда, кстати, у многих необоснованная неприязнь (а чаще обоснованная) к FM.
зачем столько злости? У KSDev было много поклонников, они даже писали письма в адрес Эмбаркадеро, типа «как вы посмели купить нашу любимую библиотеку».

Самоё главное, naum, что Вы — очень неплохой человек, просто как-то жизнь сложилась так, что Вас с несомненно большим потенциалом творчества всё время тянет на негатив (разрушение). Вот так прям сейчас, как человек (несомненно) принципиальный и честный, скажите, что Вы хотите? Какой для Вас выход из текущей ситуации приемлем? Чтобы я признал себя (KSDev, Крюкова, Embarcadero, Delphi версии выше 7) полным г… м? Вам будет легче?
Уже времени — за полночь, уже никто не читает эту ветку…
Уже я давно сижу в трениках, я уже не сотрудник Эмбаркадеро… (в смысле, не исполняю обязанности «продавца»). Я просто некий разум, пытающийся до Вас достучаться…

Скажите, какой исход Вам нужен? Похвалить Вас? Сказать, что Вы — большой и принципиальный эксперт по Delphi? Что Вы один знаете направления развития? Или что я — (как уже 100 раз было сказано) не достоин?

Знаете, если Вы сейчас покажете мне своё человеческое лицо, уже этим я не зря живу жизнь.

Бляха-муха, я крайне осторожно заныриваю в этот тред, тут все смешалось в какой-то дикой какофонии: забавный топикстартер, чьи взгляды хорошенько расходятся с знакомой мне частью Delphi-коммунити (lol), но на удивление некоторые моменты бьют в 10точку; евангелист, который сыплет пафосом и пытается что-то кому-то донести; хейтеры и холиварщики, которым просто хочется покричать и еще куча люда, который тем или иным боком пристроился к этому пиру.

Леонид, хватит парить мозг, ей богу, вы занимаетесь словоблудием, находясь на роли местного евангелиста. Мне можно, вам нет :) Я лишь уточнил, что, как по мне, KSDev не был лучшим на момент принятия решения. Более того, родившийся FM меня терзает, я не хочу его, не приемлю, я вижу развитие иным и меня это угнетает. Все было бы хорошо, если бы во всем российском коммунити я был бы одним таким. Нас тоже не нужно хвалить / ругать, мы в силу своей вовлеченности и обиженности можем вести себя вызывающе, навязчиво, ходить из топика в топик и твердить, что вы идете не тем путем / выбрали не тех партнеров / концепцию и прочее.

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

Наверно стоит ввести понятие православного (ортодоксального) евангелиста — это когда все посты евангелиста не принимаются сообществом и при этом «батюшка» периодически побивает своих же «прихожан», чтоб другие боялись :-)
Сын мой! Покайся за маловерие в будущее Delphi! Грядёт царствие небесное, где райские кущи дивного кода перемежаются с 4D визуальными компонентыми! Где компиляторы сами себя создают, а потом компилируют, а пользователи кротце и миролюбче, аки аганцы божьи!
Вот, кстати да, для меня выглядит волшебством, когда в меню Лазаруса пинаешь его перекомпиляцию, и он сам себя перекомпилирует и перезапускает.
Прошу прощения, а где волшебство? Собирается в отдельную папку, запускается exchanger, который глушит запущенный инстанс, подменяет его и запускает заново.
Я так понимаю, что волшебство не в том как это реализовано, а в том что это возможно сделать как «Click one button here, and we'll make u happy!». Ну типо — перекомпилировать программу программой, ага…
Собственно, принципу self-hosting уже десятки лет. Это не волшебство, тем более, в век всяких LLVM'ов.
Волшебство в том, что довольно навороченная среда разработки идёт в исходниках, позволяет всех их править прямо в себе, и ненапряжно перекомпилируется с пол пинка. И свой компилятор может перекомпилировать. Технически не проблема, а организационно и идеологически — волшебно.
>>Более того, родившийся FM меня терзает, я не хочу его, не приемлю, я вижу развитие иным и меня это угнетает.

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

«Более того, родившаяся технология автоматического переключения скоростей (АКПП) меня терзает, я не хочу его, не приемлю, я вижу развитие иным и меня это угнетает. Все было бы хорошо, если бы во всем российском сообществе автолюбителей я был бы одним таким».

или давайте про IT

«Более того, родившаяся технология визуального программирования меня терзает, я не хочу его, не приемлю, я вижу развитие иным и мен

или про Windows 8

»Более того, родившаяся новая операционная система Windows 8 меня терзает, я не хочу его, не приемлю, я вижу развитие иным и меня это угнетает. Все было бы хорошо, если бы во всем российском сообществе автолюбителей я был бы одним таким".я это угнетает. Все было бы хорошо, если бы во всем российском сообществе программистов я был бы одним таким".

//--------------------------------------
>>Нас тоже не нужно хвалить / ругать, мы в силу своей вовлеченности и обиженности
Стоп! На кого «обида»?

//--------------------------------------
>>Мне не нужно признаний, достукиваться до меня тоже не нужно, я более-менее понимаю о чем вы говорите. Просто этот топик пропитан грустью.

Давай, брат, поскорбим вместе. Осень на дворе, кодировать неохота, мой начальник — редкая скотина, не умеющая толком программировать…

Только вопрос: «При чем тут Delphi и FireMonkey?»

(надо, кстати, коллег из МС спросить, там такой же скорбь по-поводу .NET?)
Про коллег из .net я в конец топика вчера ссылку добавил. Такой же скорбь там.
омг, промахнулся, см. чуть ниже.

Кстати, «Леонид» — это кто?
Извините, Всеволод, говорю же все смешалось в этом треде, умудрился смешать ваше имя и фамилию.
> Nashev, отвечайте за базар!

Какой продукт, такие и маркетологи
Продукт нормальный, но понты (не знаю как иначе назвать) русского ембаркадеровского тусняка, действительно, более, чем не уместны.
> Вы много знаете о бизнесе Delphi? Не судите по утечкам.

Я сужу по результатам, со стороны. И вижу, что развитие среды и языка отставали от аналогов на годы, пока активно развивались решения-однодневки. Вот тут, в соседнем комменте, человек хорошо обрисовал ситуацию, я её так же вижу: habrahabr.ru/post/150943/#comment_5114662

И ещё раз повторяю — я признаю, что возможно эти метания действительно были и будут нужны, чтобы сохранять уровень продаж.
все куда-то мечутся. Windows 8, к примеру. А была и Vista.
Для IT поиск вариантов и направлений — нормально (а не «метания»).
Не хочется, что «свежесть» платформы FireMonkey выдают за «неправильное направление2.
да, на микрософт с его вистой и метро тоже очень грустно смотреть. Но больше никто не мечется, кстати. Дельфи да микрософт…
Зато самые динамичные компании :)
Apple — вообще секта, а там чем консервативнее, тем лучше.

Но я бы не стал висту и метро сравнивать. Метро — это реально гениальная ОС. Для планшетов :)
">>Лазарус с FreePascal вон догоняет, и теоретически тоже может всё это сделать…
Опять, Вы строите гипотезы, а я общаюсь с реальными людьми. Была у меня беседа с участником данного проекта."

Всеволод, с участником команды Lazarus или FreePascal? Во первых, не могу я никого припомнить кто бы среди них в Краснодаре жил. Во вторых, про стабильность какого проекта он говорил?

На мой взгляд, FPC — очень стабильный продукт. Lazarus — меньше, но мы потрудились и выпустили стабильную 1.0 версию, которую будем достаточно долго поддерживать.
PaulIsh, я документов не спрашивал. Сказался человек участником Lazarus-а, ну и поверил я. Словесный портрет? 180 см, волосы светло-русые (рыжие), культурный, вежливый, на вид 25-30 (может, 35 — IT-шники хорошо сохраняются :)). По-моему, у него золотая коронка на 4-м зубе, когда улыбается — видно.

Но, пожалуйста, посмотрите выше на мой коммент, думаю, Вам стоит по-помогать Александру Алексееву и всему Pascal-сообществу.
Найдем и попросим больше в глаза Всеволду не заглядывать :)

Про BPM я ответил выше.
Мне кажется, основная проблема Delphi, а в частости языка Object Pascal и рунтайма — это отсутствие эффективных средств контроля времени жизни объектов. Проще говоря, необходимость на каждый Create вручную вызывать Free, каждый раз создавая между этими двумя операторами конструкцию try… finally если могут выбрасываться исключения.
Решением проблемы могли бы стать сборщик мусора или автоматические объекты (идиома RAII), но внедрение подобных фич с сохранением обратной совместимости, при текущих темпах разработки, кажется крайне маловероятным.
Сборщик мусора, байт-код для пущей переносимости (сделаем его совместимым с байткодом JVM, чтобы можно было юзать уже существующие библиотеки и вирт. машины)…
И получим яву с синтаксисом паскаля.
Или компилятор паскаля для дуднетовского MSIL. Кстати, подобные наработки уже были, куда они делись, интересно?
Дык Delphi Prizm разве не оно?
Вот еще что вспомнил. В Дельфи же имеется хитрым образом встроенный в компилятор (и слабодокументированный) механизм работы с COM-объектами через тип Variant и позднее связывание, обеспечивающий автоматический подсчет ссылок (вызов AddRef & Release) при обновлении/обнулении указателей (обернутых в Variant). На базе подобного подхода можно было бы реализовать автоматические объекты или, хотя бы, смарт-поинтеры для родных дельфийских объектов.
>>слабодокументированный) механизм работы с COM-объектами
С чего нам документировать СОМ? Да и документировать там нечего, AddRef, Release, QueryInterface, читайте книгу Хармона.

>>работы с COM-объектами через тип Variant и позднее связывание,
Вас обманули. Variant и COM-объекты — перепендикулярны. Вы с OLE Automation спутали.

>>смарт-поинтеры для родных дельфийских объектов.
Марко Кэнту, Delphi 2009 Handbook. Все уже описано до нас.
>> Вас обманули. Variant и COM-объекты — перепендикулярны. Вы с OLE Automation спутали.
Не совсем. Просто одним из полей объединения (union) типа VARIANT из WINAPI является указатель на IDispatch, через который и происходит работа. А IDispatch это точно такой-же СОМ-интерфейс, как и все остальные, просто позволяющий вызывать методы объектов по именам.

>>смарт-поинтеры для родных дельфийских объектов.
>> Марко Кэнту, Delphi 2009 Handbook. Все уже описано до нас.
Может прекратите переходить на личности и тыкать носом в книжки и свой преподавательский опыт, а опишите метод
именно автоматического вызова деструкторов. О чем еще может идти речь кроме построения деревьев объектов и автоматического подсчета ссылок СОМ-объектов при работе с ними через Variant?
Мужик, извини. Случайно. В смысле, больше не буду :)
Я просто не люблю, когда ругают Delphi. Там одно дело контекст «хорошо бы или правильно или эффективно с точки зрения качества кодов», а другое дело «а давайте Дельфи похороним» и «Эмбаркадеро м… и».

>>IDispatch это точно такой-же СОМ-интерфейс
Согласен! Всякий IDispatch IUnknown, но не всякий IUnkonwn IDispatch :)
Хотя не могу не лягнуть МС — неизменяемость интерфейсов таковой не является (ms office).

>>Может прекратите переходить на личности и тыкать носом в книжки
Всё, всё, усовестился. Приношу извинения.
Я smart-указателями не пользовался никогда, даже в С++. Ну не было слишком сложного кода, который усложнял управление жизнью. Поэтому на память не скажу, но, походу, смарт-указатели на Дельфи уже делались — думаю, если у Вас эта тема актуально, проще найти более достоверный источник, чем я :)
Вот это мне как раз нравится, что все контролируешь ты сам.
Приучает к порядку и пониманию процессов, происходящих внутри программы.
Это подходит для обучения, не для, так сказать, производства.
Чем больше мест, которые исключают ошибку за счет архитектуры языка, или где идет проверка в компайл-тайме, тем инструмент удобнее.
Для энтерпрайз-систем цена ошибки слишком высока, там важнее, чтобы программы реже падали с обращением не по тому адресу и реже «истекали памятью», чем «приучать к порядку» коде-манки.
Create(Owner) + 0% Enterprise-разработчиков, проголосовавших за «сборку мусора» в Delphi, 2010 год.

>>Это подходит для обучения,
Большой опыт? Кого/где учили?
Ну так всяк кулик свое болото хвалит. Кто ж добровольно скажет «да, давайте наконец сделаем так, чтобы наше умение уворачиваться от граблей, выработанное годами, стало ненужным»?
А предприятиям проще использовать инструменты, не требующие многолетнего навыка уклонения от граблей — так дешевле и быстрее.

Какое имеет отношение к вопросу кого и где я учил? В бауманке, случалось.
Я не преподаватель, я инженер — «обучение» это не только когда человек вещает аудитории, сидящей за партами, это еще и процесс передачи опыта коллегам/стажерам, с целью введения их в рабочий процесс.
Брат Вася! Не узнаешь брата Колю? (тоже из Бауманке)

>>Ну так всяк кулик свое болото хвалит. Кто ж добровольно скажет «да, давайте наконец сделаем так, чтобы наше
>>умение уворачиваться от граблей, выработанное годами, стало ненужным»?
Да какое там умение! Просто привыкли все уже не бросать объект на ссылку и try finally ставить.

>>А предприятиям проще использовать инструменты,
Не, тащать за собой коды, которые под Delphi 2 создавались. И народ переучивать, и код перелопачивать.
Привыкли.

>>Какое имеет отношение к вопросу кого и где я учил? В бауманке, случалось.
Извини, брат. Понимаешь, С++ — самый популярный (или близко) в мире. Что-то как-то люди без сборщика обходятся. И херню с _gc МС пытались ввести типа «управляемым кодом С++» на раннем .NET, но вот не пошло.
И также с Delphi, ну такая она, неуправляемая. Ну это как критиковать собаку, что она лает, а кот когтями дерёт при игре с ним. Природа такова, лучше её не улучшать.
Ну так и С++ туда же вытеснили. Только он крепче чем дельфи оказался, поэтому о его смерти пока и не говорят.
Энтерпрайз системы на С++ только очень упоро самонадеянные личности начинают разрабатывать.
Остальные используют Java, .NET

Тащить за собой привыкли. И переучивать привыкли. Плачут, колются, но продолжают жрать кактус, что делать, не всегда можно убедить руководство на полное перестроение архитектуры. Но это же не означает, что такие инструменты — удобнее. Да, некоторых нужда заставляет тащить за собой эти коды. Но этих «некоторых» остается все меньше.

Ну не доберется делфи в сфере энтерпрайз систем до уровня явы. До уровня С++ вашими чаяниями может и доберется — потому что С++ сам там уже сливает.
Ой, мужик, а можно я твою цитату:
>>Энтерпрайз системы на С++ только очень упоро самонадеянные личности начинают разрабатывать.
расскажу Qt-шинкам? Может, тебя послушают?
А то мне сразу скажут «цепной пёс Эмбаркадеро честно отрабатывает свою жратву» :)

>>Но этих «некоторых» остается все меньше.
не-а. У меня статистика.
Давай, ты поможешь мне объяснить, почему DataSnap и многозвенка лучше, чем тупой толстый жирный медленный Клиент/Сервер?

>>Ну не доберется делфи в сфере энтерпрайз систем до уровня явы.
Я вот читал, но забыл. Что типа Java-отстой, а новый язык Ceylon… только забыл, что за компания за этим стоит. :(
Попрошу мне не тыкать.
Я думаю, вам это скажут в любом случае, учитывая ваш подход к общению. И не только это скажут.

Статистика? Это та самая, которая «по опросу на свиноферме статистика показала, что 100 процентов опрошенных работают на свиноферме»?)

Ну так напомните себе и остальным эмбаркадеровцам вот этой занимательной диаграммкой.
Заодно можете сравнить количество вакансий хотя бы по Москве для разработчиков Java, C# и Delphi.
Иногда полезно оперировать не относительными данными (54% роста! ОГО!), а абсолютными :)
Я про абсолютные и говорю сейчас.
Именно. Ваш оппонент до этого красиво оперировал относительными.
Ну попроси (те).

>>И не только это скажут.
Это что — угроза? 12 сентября в Москве, семинар Embarcadero. Обменяемся мнениями. Я капу воткну.

>>Статистика? Это та самая, которая «по опросу на свиноферме статистика показала, что 100 >>процентов опрошенных работают на свиноферме»?)
В смысле? Опросы проводились компанией и лично мной среди пользователей Delphi. Я задавал вопросы людям, приходящим на семинар Embarcadero. «Свиньи», говорите? Вам лучше тогда на семинар 12-го не приходить. Я ж не смогу не представить такого почетного знатока с/х аудитории!

>>Ну так напомните себе и остальным эмбаркадеровцам
Ну да, а то мы интернетом не пользуемся. :)
Тогда, уважаемый, посмотрите на популярность финского языка чисто по статистике на генеральную совокупность. И что? Теперь финнам завтра резко переучиться на китайский? (ну а на какой еще?)

>>Заодно можете сравнить количество вакансий хотя бы по Москве для разработчиков Java, C# и Delphi.
Мужик, тебя трудоустроить? Присылай резюме на мой ящик, 100 т.р. в Москве тебе устрою. Если программировать умеешь.
Я вижу у вас проблемы с пониманием, а разжевывать каждое слово у меня особо желания нет, к тому же общение с откровенным хамом особо удовольствия не доставляет. К счастью, людей, которые упорно продолжают тыкать после прямого указания этого не делать, тут меньшинство.

Занятно, что вам не дался смысл этой простой фразы. Ну давайте в виде исключения поясню для вас: это значит, что выборка не репрезентативная. Задавать вопрос на семинаре по делфи «а не используете ли вы делфи» — безусловно великолепный способ собрать статистику о тенденциях. Полагаю, теперь фраза про свиноферму понятнее? Или вы по-прежнему пытаетесь там найти скрытое оскорбление разработчиков на дельфи, эмбаркадеро или еще кого?

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

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

>Заодно можете сравнить количество вакансий хотя бы по Москве для разработчиков Java, C# и Delphi.

Это будет более показательно, нежели опрос «среди своих».
Ну про «хамство» Вы опять неправы. Дайте мне цитату, где я Вас обхамил?

Ещё раз про свиней.
Здесь поднялась волна нездорового креатива, частью которого безосновательные советы и критика компании Embarcadero. Дескать, не туда товарищи рулите.
Я отвечаю рууууским языком, мы проводим опросы наших пользователей (включая меня лично) и выясняем, какие есть предпочтения. Им и стремимся следовать.

На основании совершенно субъективных взглядов, Вы предложили новый путь развития Delphi. Типа «сборщика мусора» или ORM. Я Вам официально и ответственно заявляю, что это интересно Вам и еще паре-тройке человек, в то время как основной массе программистов Delphi эта фича — небольшая и ненужная рюшечка.
В ответ Вы сравнили эту основную массу честных Delphi-кодеров свиньями и подставили под сомнение полезность умения программировать на Delphi.

Я Вам говорю, что факты — (ненужность сборщика мусора и ORM) — вещь упрямая. Вы отвергаете очевидное.

А огорчение Ваше понятно. Оговорочка насчёт «полмиллиона» выдала Вашу неудовлетворённость текущей компенсацией. Да, пожалуй Вам нужно «похоронить Дельфи в себе» и найти другую работу.
Рекомендую стать главбухом. С Вашей головой и способностями Вы легко сможете быть таким специалистом, а зарплаты главбухов гораздо выше, чем программистов, что бы мы не взял, хоть Java, хоть .NET, хоть PL/SQL.
Ок, последний раз вам отвечаю по пунктам и заканчиваю на этом общение, ибо вы неадекватны.
0) Хамство — это ваш стиль общения вкупе с нежеланием отказаться от «тыканья» несмотря на прямое замечание. Вот только со второго раза вы осилили переход на «вы».
1) Вы меня с кем-то путаете, я вообще не предлагал никакого пути развития делфи. Меня не волнует есть там сборщик мусора или нет.
2) Вы собирали какую-то статистику (причем тут опять сборщик мусора? Откуда вы это взяли?) среди своих пользователей.
А речь шла о том, что количество тех, кто тащит легаси уменьшается. По естественным причинам. На то оно и легаси. Вы на это заявляете «нет, у меня есть статистика!».
Поэтому я вам объясняю — если вы не про какую-то отвлеченную статистику про сборщики мусора, о которой не шла речь, а именно про легаси спрашивали у своих пользователей, то это то же самое, что проводить опрос среди работников свинофермы «где вы работаете?»
3) Видимо, вас что-то беспокоит, если вы упорно считаете, что кого-то сравнили со свиньями да еще и подставил под сомнение полезность умения программировать на Delphi — возможно, это какой-то вид галлюцинаций, не знаю точно. Лично я не могу найти ни одной фразы, где я бы сравнивал кого-то со свиньями. (Хм, может, вы считаете что в той фразе про свиноферму «опрошенные» — это свиньи? Занятно...)
4) Оговорка насчет полмиллиона? Какая оговорка? Я вам прямо сказал «даже за полмиллиона в месяц я не хотел бы работать с таким человеком как вы». Вы у нас еще и доморощенный психолог? Вы хотите об этом поговорить?
«Мою неудовлетворенность», простите, чем? Компенсацией? Я не инвалид, мне не платят компенсации, мне платят заработную плату. Или вы про компенсацию за работу с человеком типа вас? Так это конечно, меня не удовлетворило бы. Но, к счастью, с вами я работать и не должен. Делфи мне хоронить «в себе» не нужно, в моей сфере, к счастью, такие вещи не используются.
Без ваших рекомендаций я как нибудь обойдусь, можете воспользоваться вашим собственным советом.

За сим я откланиваюсь, больше общаться с вами желания нет.
Давай, брат, на прощание помиримся? Знаешь, как-то грустно на душе, вроде «бауманку» вместе заканчивали, вроде на Delphi пишем… можно сказать — одной крови.
Заметь, напишешь мне что-нибудь хорошее, дык настроение поднимется. А то ведь будешь ворочаться в кровати, типа «а я ему сказал...» «а он мне нахамил...».
Сделаем full-reset и ладушки. А?
Всеволод, я задам пару встречных вопросов о ненужности, ок?

1) Есть ли в открытом доступе данные о распределени делфи-разработчиков по типам разработки (энтерпрайз, DB, шароварщики-одиночки и т.д.) и где можно на это дело глянуть? Есть ли в открытом доступе результаты опросов и, так же, где можно их посмотреть?

2) Насколько я помню, в delphi 2010 & XE были большие изменения в DataSnap, они предлагались как одна из основных фич тех версий. Их внедрение было следствием предыдущих опросов?
Гхм… 100 т. р. в Москве — это типа крутая зарплата для дельфиста?
Типа мне за вас hh.ru посмотреть?

Типа 100 т.р. это нормальная для Москвы зарплата, если ты — кодер.
Не архитектор, не начальник отдела, не аналитик (который, бывает, получает меньше). Это — норма. Это просто норма для Москвы и программиста. Корпоративного программиста.
Есть те, кто работает за 60, за 80.
Если знаете C#, то моя жена ищет в отдел программиста. Опять же на 80-100.

Дельфи также хорошо кормит, как и Си-тюрьма, Жаба и пр.пр. Зачем рассказывать сказки, что Дельфи — не прокормит? Вот у меня мужик из банка сказал, подведи мне нормального парня, Delphi-ста. Вот пользуясь случаем помогаю.

Да вообще, все ж понимают, нужны деньги, ну не ходи в программисты. Будешь 10 часов в день кнопки топтать без шансов вырасти. Иди в настройщики 1С бухгалтерии :)
Я намекаю на то, что рынок вменяемых дотнетчиков, гм, несколько выше. Не архитекторов, не нач. отделов, а вполне обычных миддлов и синьоров.
Так что на 80-100 я не пойду, уж простите.
И какие предложения? Переписать 100 тыс. строчек кода (которые у Вас, без сомнения уже есть) на С# только из-за того, что там зарплата выше?
Вы поспрашивайте людей, которые на WPF писали или на Silverlight. Как они сейчас себя чувствуют.

>>Так что на 80-100 я не пойду, уж простите.
Да-да, я понял. Я миллион коплю, раз Вы на поллляма не согласны.
Legacy — это совершенно отдельная проблема.
И, да, у нас действительно есть legacy на Delphi и соотстветствующий отдел, который его поддерживает.

На WPF и Silverlight с удовольствием пишут многие из моих знакомых. За хорошие зарплаты и с кучей перспектив ;)
Расскажете мне про перспективы WPF?
Я был на конференции Microsoft DevConf 2011.
Был слайд «перспективы средств разработки». На слайде WPF не было. А после SilverLight стояла HTML5.
Расскажите это Вашим программистам.
С какого перепугу WPF должен быть на слайде про веб?
Вы бы сначала в тему въехали.
А сильверлайт благополучно переехал на мобильные платформы.
>>Был слайд «перспективы средств разработки»
Зачем Вы выдумали за меня слово web?

Уважаемый, мне так надоело цеплять за язык местное общество…
Слайд был такой (он у меня в блоге даже есть)
C++
WinForms
SilverLight
HTML5

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

А вот зачем писать гадости типа:
>>Вы бы сначала в тему въехали.
Тут я не знаю. Зачем-то нужно Вам держать в голове ментальную конструкцию «Embarcadero — дураки, а Всеволод — один из дураков».
Ссылку дайте, пожалуйста. Желательно на полную презентацию.
Да что Вы никак не успокоитесь! Скажите мысленно — «Всеволод и я одной крови». И будет Вам +100 в карму (только в реальную).

Ищите доклад Михаила Черномордикова (походу запись была) в главном зале Microsoft DevConf'11, я там сидел в 5-м ряду.
Корпорация Microsoft очень аккуратная, всё публикует.

Давайте уже договоримся, золотой мой, ну в теме я, в теме. Работа у меня такая. :)

(подсказка — «Сева мой брат»)
Вы там, в своей Москве, совсем охренели.
Приезжайте! 100 т.р., квартиру снимите за 30, на 70 можно жить. Как программист C# .NET начинающий.
Хорошее начало поста «мне кажется!» Совершенно основательный повод написать свой коммент.

>>это отсутствие эффективных средств контроля времени жизни объектов.
я в 2011 году под релиз Delphi 2010 проводил опрос среди программистов, а также смотрел закрытый Delphi Developer Servey, где был вопрос про сборку мусора.
0% — вы в одиночестве. Никому не нужно. Серьёзно! Используйте myObj := myClass.Create(Owner); плюс правильно написанный деструктор.

>> необходимость на каждый Create вручную вызывать Free, каждый
Вас плохо учили программировать. Приходили бы в мою группу 5 лет назад, когда я тренировал людей, я бы Вам рассказал.

Но не поздно вырасти надо собой! Эрик Хармон, COM в Дельфи. Книга такая.
>> Используйте myObj := myClass.Create(Owner); плюс правильно написанный деструктор.
Построение деревьев объектов один из возможных выходов, но не панацея.

>> Приходили бы в мою группу 5 лет назад, когда я тренировал людей, я бы Вам рассказал.
>> Но не поздно вырасти надо собой! Эрик Хармон, COM в Дельфи. Книга такая.
Так расскажите сейчас, или за 5 лет уже забыли? Реализация каждого объекта как СОМ-объекта и работа с ними через тип Variant, как я писал выше, довольно накладный способ обеспечить универсальный автоматический менеджмент памяти.
Зачем Вам менеджер памяти? Не бросайте созданный объект на ссылку.
>>Так расскажите сейчас, или за 5 лет уже забыли?
Что забыл? Ничего не забыл — делайте Owner-а и всё будет ок.

>> довольно накладный способ обеспечить
Мужик, ты попал.
Расскажи про «накладность». Давай, у меня в программе 100 объектов. Насколько накладным (по мозгам и скорости) будет
«универсальный автоматический менеджмент памяти»?
Сколько сэкономишь?
Ну вот зачем Вы тут в топике хамите всем подряд? Постыдились бы…
>>Ну вот зачем Вы тут в топике хамите всем подряд?
Делаю умышленно. Шоковая терапия.
Ум, честь и совесть IT-сообщества (без сарказма) — активисты Хабра устраивают скулёж на тему «за меня память не чистют». И что? Это как? В перемешку с «Delphi 7 forever».
Вы ж, родимцы, не понимаете? Что это есть «демотиватор»?
Вот, таким электрическим разрядом в мозг вывожу вас всех из этого состояния.

Не девочки, потерпите.
Ну про GC в контексте Delphi был совершенно унылый коммент, действительно. Остальным же читать шоковую терапию не особо приятно, они все больше на вас «агрятся».

Давайте лучше FM коснемся. Вы действительно считаете, что это панацея? Не погружался глубоко, честно, если у вас есть возможность (время и желание) — можете ответить на пару вопросов? Есть взять FM-канву, к примеру, у FM свой растеризатор или он дергает ОС API? Почему такие проблемы с производительностью?
>>Остальным же читать шоковую терапию не особо приятно, они все больше на вас «агрятся».
Это понятно. Жили люди 5 лет с мыслю, что буржуйская борланд-эмбаркадеро убила нашу святую дельфю, а тут раз — вроде нужно как-то отношения налаживать. Но инерция заставляет твердить «г@вно».

FM дергает API, либо DirectX (если на Win-е), либо Quartz (на Мак-е). Зайдите на blogs.embarcadero.com/vsevolodleonov, там дальше есть раздел «Recorded Webinars», и один из первых я брал интервью у Е. Крюкова, архитектора FireMonkey, который сейчас является одним из идеологов. В первом Вебинаре он рассказал о том, как он все делал, как работает FireMonkey, каковы механизмы её работы.
1 час времени — не так много, зато Вы будете знать FireMonkey так, как знает её Крюков (или почти так). :)

Будете её использовать — хорошо, не будете — ну хоть будет ясно, от чего и по каким веским (а не левым) причинам Вам это не подошло.

Проблемы с производительностью? Тут нельзя говорить «огульно». Какие проблемы? На каком примере? Какие задачи решаете?

FireMonkey (FM) — это не «панацея», это просто новый фреймворк (библиотека, альтернатива VCL, если хотите). Она рендеринг делает за счет GPU (считайте, что WPF, который естественно тоже был изучен), но поддерживает кроссплатформенность. Компоненты FM рендерятся в зависимости от платформы, поэтому Win->MacOS переход многовенный за счет перекомпиляции проекта и врубания нового стиля.

Сможет ли FM вытянуть Delphi? На былую высоту определенно нет, т.к. былая высота означает полный вакуум в средствах разработки. Ну и Windows тоже уже не наберет былую высоту. Равно как и Англия, больше не будет царицей всех морей. Это просто цивилизованная вполне зажиточная страна, жить в которой комфортно.
Так и Delphi, ресурса 1.7 миллионов пользователей в мире нам хватает, чтобы развить инструмент до достижения хорошего качества новой платформы. А там, если как планировалось сделаем iOS и Android в одном флаконе, то станем Англией. И английский (дельфийский) язык будет языком межнационального (межплатформенного) общения.
Отлично понимаю, что без сырков мое микро-исследование уныло [выложу завтра обязательно], но я сравнил в рамках 1к итераций отрисовку полигонов (5 вершин) с рандомными координатами, рандомного цвета кисти / линии через классическую (GDI) канву и FM канву. Код 1-в-1, замеры через QueryPerformanceCounter. FM проигрывает на порядок. Наверняка есть что потюнить именно в контексте FM, но изначально был крайне смущен.
С GPU все ли в поряде? У меня старый бук, на нём Dell видеодров не дал по W'7, поэтому перформанс слабый. Вообще-то не должны быть тормоза, Direct2D коллится, там засад быть не должно.
Машина в целом мощная, GPU соответствует. Чую, возможен мой факап, потому уточню у вас, ибо беглый поиск не дал адекватного решения. Как уже говорилось в условиях задачи: полигон рисуется с заливкой и границей, на FM приходится вызывать «пакетом» FillPolygon + DrawPolygon, чтобы получить желаемое (если использовать один из методов, т.е. без заливки / без границы — FM все равно проигрывает GDI, правда с чуть меньшей разницей).
Я Вас искренне поздравляю, Вы — самый большой эксперт по рисованию полигонов средствами FM, а также GDI.

Уже нет никакого сарказма. Мне уже хочется просто подарить Вам лицензию на Delphi XE3 Architect ($2500), чтобы Вы принципиально её отвергли.

Поверьте, что моей целью является некая мировая гармония любителей/ругателей/исследователей Delphi. Я просто не знаю, как поступить в случае с Вами, чтобы Вы наконец почувствовали себя счастливым.

Давайте вместе напишем какой-нибудь компонент к Delphi, а я его в релиз Delphi XE4 вставлю? Или успеем к какому-нибудь update-у?
Уже много лет для этого можно использовать интерфейсы.
Ребята, давайте ещё раз разложим всё по полочкам. Надо было это сделать с самого начала, чтобы толпы хомяков не начали набрасываться на участников дискуссии.

1. «Дельфи» в классическом его понимании (вторая-седьмая версии) надо закопать. И никогда более не выкапывать;
2. По современным инструментам из семейства продуктов Embracadero нужно чётко оговаривать ниши. Насколько я понимаю, евангелисты об этих нишах знают;
3. Автор, при написании статьи специфицируйте, пожалуйста, про что вы пишете.

В комментариях, на самом деле, из-за этого получилась на редкость идиотская дискуссия. Я, например, подразумевал исключительно классические инкарнации Delphi — те, что люди до сих пор (через десять лет после релиза) тянут в продакшен. Это недопустимо, у них нет будущего.

Про хобби-варианты типа Лазаруса и различных fpc можно и не говорить — у них нет внятной политики монетизации, их юзкейсы исключительно субъективны, поэтому в правовое поле объективных оценок их втягивать нельзя.

Про современные продукты Embracadero можно сказать следующее:
1. Хорошо, что компания закрепилась в определённой бизнес-нише;
2. Воевать с нативными инструментами от Microsoft бессмысленно;
3. Незачем призывать что-то с ними делать, не понимая правил игры рынка.

Автор, формулируйте мысли более внятно.
А в какой нише, они, кстати, закрепились?
Аналитические продукты, бизнес-многозвенка, простенькие учётные системы. Мигрировавший легаси, опять же.
А в чем там конкурентное преимущество у них? Я не с целью разжечь холивар, просто хотелось бы услышать ответ по существу, и, желательно, без хамства — но увы, не каждый тут может ответить в таком ключе, поэтому спрашиваю не у пророка эмбаркадеро а у вас)

Имеется в виду конкурентные преимущества перед C#, Java — вышеперечисленное это их поле, в принципе (кроме легаси).
Только нативность кода? Она сейчас играет какую-либо серьезную роль, особенно в энтерпрайз-системах?
Из конкурентных преимуществ — евангелистские показатели синтетических тестов; Легаси; Продуманная инфраструктура для построения приложений (интерфейсы к СУБД, средства генерации отчётов, инструментарий для децентрализации вычислений, CASE-средства для разработки энтерпрайз-приложений, условная кроссплатформенность, развитая система компонентов и связывания данных); Условная низкая стоимость владения инструментарием и решениями; Низкая стоимость программистов.

Нативность серьёзной роли не играет. Особенно на фоне пара-нативности .NET CLR/JVM-решений.
Хм.
Вы уверены, что это именно «конкурентные преимущества перед C#/Java»? Разве в этих языках нет подавляющего большинства из перечисленного вами?
Скажем так — это «элементы стелз-технологий» для того, чтобы можно было пытаться бороться с инструментами стеков .NET/Java Platform.

На самом деле конкурентные преимущества — работающее легаси-ПО, на которое уже затрачены огромные средства, коммерчески поддерживаемая абстрагированность от какой-либо платформы с потенциальным переходом в кроссплатформенность и огромная армия программистов, которых можно задёшево трудоустроить, т.к. больше им деваться некуда.
Ну да, я вот так это и воспринимаю, "чтобы можно было пытаться бороться".
В том смысле что я пока не вижу киллер-фичи, которая бы позволила резко отхватить часть тех, кто сейчас пишет на явах и дотнетах — а судя по ярости защитников, складывается впечатление, что они там сплошь натыканы.
Человек очень редко когда соглашается перейти даже на «почти такое же», только если будет что-то очевидно более выгодное.
Да, рынок решает… Что теперь, и погрустить по этому поводу нельзя?
Грустите на здоровье, только по вечерам и дома.

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

Честно говоря, я на это и отвечал.

Перечитал сейчас развернувшиеся дискуссии — отвечать на комментарии выше, извините, не хочется. Там разговоры обо всём, как в курилке или на кухне под водочку. Без конкретики, без спецификации конкретного продукта или подсемейства в семействе, без экономических обоснований. Да, чёрт возьми, с уходом в аргументы уровня «ты не знаешь, о чём говоришь».

Не делайте больше так, пожалуйста.
Legacy — это что? Честно, не понял мысли.
Это то, что официально не поддерживается и остаётся в наследство. В данном случае — семейство классического Delphi от 2 до 7.
Если так, то содержание топика Вы поняли правильно, но вот что хотели сказать остальной частью комментария тогда становится для меня загадкой.
Тут я оговорился, под «остальной частью комментария» я на самом деле имел ввиду остальную часть того абзаца — «Вы написали провокационный пост, на который повелись люди. Я за других не могу отвечать, но лично мне по содержанию топика показалось, что вы писали про пути развития Legacy Delphi. „

Вы говорите, что вам показалось то, что оно является тем, чем оно является на самом деле. Тогда что тут делает слово “показалось»?
То, что классические дельфи (скажем D7) тянут в продакшен — имхо вполне допустимо. Ибо наверняка я не открою секрет, что до сих пор, в продакшене работает софт, написанный школьником в визуал бейсики совместно с аксессом. Есть такое, сам видел и к сожалению не раз. Если софт на дельфи написан серьезным программистом, то он работает и работает гораздо быстрее чем ваши эти все интерпретируемые си шарпы и явы. Да, работает только под венду и только на x86, но он работает быстро. Но кому-то нужен конечно зоопарк, поэтому пишется на яве чтоб работало везде. Оно везде работает, только вот «как». Далеко ходить не надо, надо лишь взглянуть на такой пример как UTM (биллинг для инет провайдеров). Кто работал, тот поймет.
Потрудитесь изучить вопрос «интерпретируемости» .NET CLR/JVM, пожалуйста.
Да потрудился уже. Если я в дельфи пишу Inc(a,20), у меня генерируется опкод inc [адресъ],20. Если я то же самое пишу в вышеуказанных языках, у меня генерируется штук сорок опкодов: что такое а, могу ли я его увеличить, потом загоняется в какой-либо регистр а, например в eax, он увеличивается на 20, потом регистр eax загоняется в память. Таким образом элементарная операция растягивается на десяток опкодов,. я не говорю про более сложную работу, например с массивами. Вы сами откройте отладчик и посмотрите, что у вас творится при занесении в переменную A како-го либо числа. Разнича с делфи си или с++ и прочими вашеми явами поразительна.
Давайте тогда говорить об оптимальности или неоптимальности кодогенерации, а не об интерпретируемости, хорошо? Это не буквоедство, это принципиальная ошибка в понимании друг друга.
Хорошо. Но тогда давайте говорить о том, что алгоритм написанный на дельфе (классическом) будет работать быстрее, чем такой же алгоритм на C#.
Не будет. Я о таком сравнении и не говорил.
Незачем сравнивать нативный код и JIT-компилированный. Разные подходы к менеджменту памяти, разные подходы к контролю кода. Разные цели.

Вот из-за этих целей и не надо тащить в продакшен код, написанный с использованием инструментов десятилетней давности.
Там внутри скобочек вокруг += у вас тоже десяток вспомогательных опкодов набирается, и это ровно то, о чём tronix286 говорит.

С другой стороны, если обращаться не к локальной переменной а к полю экземпляра класса в памяти — Delphi тоже придётся сначала так или иначе вычислить прямой адрес нужной ячейки…
Лишних опкодов нет (т.е. таких, которые эксперт при ручной оптимизации выкинул бы).

Пролог с формированием стек-фрейма есть и в дельфи, условный с вызов подпрограммы — это инициализация static-полей класса main при первом входе, к инкременту оно отношение не имеет. Та же инициализация есть и в c++ (в дельфи нет, т.к. нет объектов не на стеке)
* нет объектов не в хипе
Вот тут хорошо умный дядька всё расписал по поводу native-кода vs виртуальные машины: habrahabr.ru/post/149866/
О… дочитываю, и вижу как он вторит мне (или я ему?) по поводу правильного направления!
Да потрудился уже. Если я в дельфи пишу Inc(a,20), у меня генерируется опкод inc [адресъ],20. Если я то же самое пишу в вышеуказанных языках, у меня генерируется штук сорок опкодов

а у меня c# почему-то в Release генерит тот же самый add:
habrastorage.org/storage2/3dc/36f/dda/3dc36fdda803b465c8e65daf950b27c9.png
Есть три веселых буквы, JIT. И результаты тестов скорости приложений на C#, Java.
JIT еще не очень веселые, бывает еще AOT. Однако даже эти три веселых буквы (AOT) не дают производительности нативных языков.
Для «софта, написанный школьником в визуал бейсики совместно с аксессом» разница в 10% производительности роли не имеет
Для шарпов и яв, конечно не имееет. А вот грамотное решение на Си ил Дельфи будет в разы отличатся по скорости.
Грамотное решение от неграмотного отличается по скорости в разы, согласен
О, мифическая скорость. Особенно смешно видеть этот аргумент применительно к энтерпрайз системам, где все будет упиратсья в GUI, базы данных и генерацию отчетов, и где рельно пофиш, на чем это написано — на C или на C#, потому что разница в 10% между решениями на этих двух языках в данной области никого не интересует.
* Embarcadero, конечно
Открыл для себя существование Clang и LLVM и GDB 7, вкусно описаный на трёхлетней давности страничке в форуме FPC. Паровоз прогресса опять дельфистам хвостом машет…
Как раз недавно думал, без каких языков программирования моя жизнь прошла бы лучше, эффективней. Делфи/паскаль первым пришел на ум — если бы вместо него в универе преподавали сразу Си, Си++, Питон или Эрланг, там, то в голове было бы меньше мусора и больше полезных навыков и привычек. Нет в нем совершенно никаких конкурентных преимуществ.
> Например, я видел, что Intel делала оптимизирующий компилятор для своих процессоров — было б здорово уметь его использовать для программ на Delphi

Есть идея — нужно компилировать с Дельфи не в бинарный код, а в Си-код, а уже Си прогонять через Intel с оптимизацией.
Думаю, это реально замутить челам-разрабам, знающим толк в извращениях)
UFO just landed and posted this here
> Компилятор Паскаля — однопроходный, С — многопроходный. Ах, зачем же транслировать одно в другое?

А можно попонятнее объяснить, что это значит? Спасибо. =)
В реальном компиляторе Паскаля (или Делфи) максимум парсер однопроходный (как и в Си, между прочим). А любые оптимизации (машинно-зависимые и независимые) всё равно отдельные проходы.
В си когда-то отдельным проходом обрабатывались дефайны, и бывало, отдельным проходом переводился C++ в С. А ещё где-то я видел отдельный перевод С в текст на ассемблере.
> В си когда-то отдельным проходом обрабатывались дефайны

Сейчас препроцессор и парсер работают в одном проходе (по множеству причин, но вот одна из них, которая показывает что это действительно так — если бы препроцессор работал отдельно, в диагностиках вы получите ссылки не ваш исходный код, а на отпрепроцессеный).

> бывало, отдельным проходом переводился C++ в С

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

> А ещё где-то я видел отдельный перевод С в текст на ассемблере.

А у паскаля что, прямо AST процессор исполнять будет?

Хватит уже про эту «однопроходность». Сегодня любой компилятор, любого языка, который хочет выдавать нормальные диагностики и делать оптимизации, является многопроходным. Просто проходы идут не по исходному коду, по по внутреннему представлению.
Сейчас препроцессор и парсер работают в одном проходе (по множеству причин, но вот одна из них, которая показывает что это действительно так — если бы препроцессор работал отдельно, в диагностиках вы получите ссылки не ваш исходный код, а на отпрепроцессеный).
Высосанная из пальца причина. Препроцессор, при смене файла вставляет в output директиву
#line 20 "program.cpp"
И следующий парсер, который обрабатывает отпроцешенный файл, устанавливает у себя внутренние переменные «текущий файл» и «текущая строка» на указанные.
Можно, но это прошлый век — только номер строки и сохраняется. Caret diagnostics нет, macro expansion stack нет.
MSVC — прошлый век :(
Если фронтэнд начали писать 10+ лет назад, то так и есть.

Исходный код и процесс разработки MSVC закрыт, а вот в GCC пытаются добавить caret diagnostics, но это очень тяжело даётся. Особенно учитывая то, что «однопроходные компиляторы» и другие «прикольные трюки» были тогда в моде и в AST GCC сразу сворачивает константные выражения. То есть AST не соответствует исходному коду и вообще выдавать по нему диагностики — подвиг (не говоря уже о caret diagnostics).
Пост канул в архив, но пусть это будет здесь: для использования QT тож нжен специальный препроцессор, вызывающийся перед компилятором.
Кстати, да — на презентации Rad Studio XE3 это подтвердили. Компилятор C++Builder под x64 обещают где-то недалеко от нового года выпустить, и он делается на LLVM. Delphi будущих версий тоже на него пересаживать уже задумано.
Интересно, они сохранят свой компилятор под win 32/64 или полностью откажутся от него в пользу LLVM?
Их компайлер в плане скорости / компактности и архитектуры — просто замечателен. LLVM ему проиграет по первым двум пунктам точно, третий сравнить сложно, ибо задачи перед LLVM стоят большие и в плане масштабируемости он намного круче. Если они перенесут концептуальные моменты (работа с модулями и прочее) без особых изменений на LLVM toolchain, то это будет блестящая связка.
Удивительно! Если на самом деле пойдут в сторону LLVM это будет просто потрясающе.
А вот кстати, я прочитал про LLVM чуть больше, и перестал понимать в чем именно его бонус? Пред-компиляция исходников по мере набора их в IDE, с облегчением реактора и интроспекции — не его бонус, в отличие от того, что мне показалось когда я читал про его в связке с CLang. Построение AST ведь не его дело, да?

Хотя, компилятор в него отделить от компиляторов под целевые платформы — позволит развивать компиляторы языков отдельно и независимо от компиляторов под целевые платформы.

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

С третьей стороны, чем оно так сильно отличается от java-машины или .net байткода? Почему к ним не делают компиляторов, чтобы раздавать exe-шники?..
Рефакторинга, а не реактора. За Swype не уследил опять…
Ну и кто после этого epic-треда скажет, что Delphi мертв?! Ха-ха, да в классических холиварах такого кипения нет. Он не мертв, просто за него все переживают. Хейтеры-неадекваты переживают, что он еще дергается. А любящие его люди, что ему реально кранты (в контексте их работы, а то сейчас получу по шапке от местного евангелиста, мол, 1.7М установок бла-бла-бла).
naum, то же самое хотел написать — не каждый пост 200+ комментов наберет. И, на удивлением, довольно полезных — даже в сраче можно подчерпнуть много полезного. Я удивился — но приятно. Все таки не все равнодушны. Точнее — все скорее неравнодушны, чем равнодушны ;) А если еще посмотреть что это сугубо рофильный хаб…

Меня всегда удивляло — пишут Delphi сдох и умер, а затем это пытаются доказать.
Наличие спора вокруг Delphi показывает однозначно, что он жив и про него знают даже те, кто только о нем слышал.
Насчет использования .Net сборок в нативном Delphi.
Есть как минимум 2 сторонних продукта, позволяющих это осуществить. Один заточен на использование не визуальных классов (не помню название), а второй — на использование визуальных компонент на нативных формах (Hydra от RemObjects).
Нагуглил название первого: Atozed Software CrassTalk.

Есть еще возможность использовать сборки .Net через COM, но от самой мысли лезть в COM меня выворачивает наизнанку.
А как по вашему работают CrassTalk и Hydra? Только COM.
Может быть, но это, по крайней мере, обернуто…
А ещё парням из Embarcadero над прекратить заниматься фигнёй.
Я просто оставлю это здесь.
Да уж…

Там очень верный комментарий есть: Embarcadero have a remarkable ability to shoot themselves in the foot, one toe at a time.

Вот очень интересно, чъя именно это была инициатива в этот раз?
Есть мнение, что если продавать продукт несколько подешевле и в добавок к этому сделать ещё и бесплатную Express версию — то такую турбо-защиту можно было бы и не городить.
UFO just landed and posted this here
Можно подумать, дельфи/студию/етц покупают не для программирования, а чтобы саппорт лизал яйца.
А Вы не ошиблись топиком?
Здесь обсуждается компания Embarcadero и в частности её продукт Rad Studio, а не служба эскорт-услуг.
Поэтому приём «всяких там WebMoney» и лизания яиц со знанием дела выглядят как-то неуместно…

А что касается блядей — наверное действительно неудобно им свой CVV2 вводить, тут уж вам виднее.
Вообще, в этом подходе резон есть — создавать инфраструктурный продукт, раздавать его задешево и зарабатывать на консалтинге, обучении, сертификации, обновлениях, платных доработках. Но этот сегмент бизнеса очень локален, в каждом райцентре должны быть местные представители… Если иметь ввиду мировое господство — возможно, проще отдавать этот сегмент местным подрядчикам типа реселлеров, как это и сделано.
Я знаю несколько фирм, сосредоточенных на одном продукте, основатели которых стремились сделать лучший вариант продукта в отрасли. Например, из свеже узнанного ирландского — Гиннес с их стаутом, Джеймсон с их виски, Бэйлис с ликёром. Но и до них я таких встречал, и не только в области спиртного. Они все гордятся своим продуктом, и вполне заслуженно. И неплохо живут. Хотя в Бэйлисс, наверно, подзабыли истоки и стали расширять ассортимент, кажется попсеют…
Цены на Бэйлиз, кмк, тоже завышены. Конкурирующие продукты Brogans Carolans и Mersi предлагают качество не хуже по ценам в разы меньше. То же самое и с Jameson… хотя о вкусах я спорить не буду, это очень личное.
Цены на Бэйлиз, кмк, тоже завышены. Конкурирующие продукты Brogans, Carolans и Mersi предлагают качество не хуже по гораздо более приятным ценам. То же самое и с Jameson… хотя о вкусах я спорить не буду, это очень личное.
WTF даблпост… а говорили Internal server error...=(
Не надо тут лялякать о том, что Delphi говно и полной отстой! Если у Вас тонка кишка на нем написать полностью игровой движок под Win32/Win64 со своей внутренней оптимизацией + написать свои оригинальные квесты и заработать на этом деньги, так нечего тут тему ломать. Учиться надо было в своё время, а не по девках шляться и с пивом целоваться!

Articles