Pull to refresh

Comments 101

Кросс-платформерная библиотека визуальных компонентов. Ура! Правда еще года 3 ждать когда допилят =) Судя по отзывам бета-тестеров — разрабатывать под iOS — мучения, под MacOS — полегче, за счет компилятора от Embro. Но хоть какой-то выход на уровень кросплатформенности не может не радовать. Чудесно, может скоро произойдет обратная миграция на Delphi? Кстати, читал что они не только ограничатся маком — будут расширять функции кросплатформенности на Linux, Blackberry, Androind и еще на пару мобильных платформ, всех не упомню ;)
Библиотека KsDev от Крюкова более-менее нормально работала в Windows и Mac OS X. В iOS он показывал только демки, рабочих проектов не было. Его библиотека отвечала только за интерфейс, биндинги к API, видимо, они делали сами с нуля.

Вопрос ещё, будет ли обёртка для нативных контролов, а? :) В приложениях для бизнеса красивости не нужны.
Вот что написал пользователь deks на руборде:

Смотрел про поддержку iOS/OS X в DXE2. Больше всего интересовало — как работает RTL и будут ли поддержка каких-либо native API на «чужих» платформах.
Выяснилось: OS X — совершенно отдельная платформа от iOS.
OS X имеет «встроенный» в RAD Studio кросс-компилятор, подготовленную под Mac RTL, в которую включены возможность вызывать многие нативные фреймвоки мака — (они живут в пространстве имет MacAPI.xxx). Есть поддержка откладки в среде RAD Studio и «совмещенная» с отладкой возможность «отправки» приложения на Mac и его запуска там (через Platform Assistant).
iOS поддержана гораздо скромнее. Скорее можно говорить о «предварительном» выпуске такой фичи. по всей видимости, благодаря наличию у KSDev готовой поддержки iOS через FPC решили от такой темы не отказаваться! Благо в маркетинговом плане наличие какой-никакой поддержки iOS — это хороший жирный плюс, так что выпустити нижеследующее. Проекты под iOS создаются в RAD Studio, там же и отлаживаются — но как Win32 приложения. Потом необходимо «конвертировать» проект RAD Studio в XCode (есть соответствующая утилита). проект должен лежать на общедоступном для Win и Mac месте (сетевая папка, DropBox, Shared folder между VM и Host OS). потом мы на Mac ставим (внимание!) специальный набор — XCode3 + FPC (сначала 2.4.4, а потом с помощью его компилируем и дальше используем FPC 2.5.1). Соответственно, в качестве RTL доступны все возможности RTL от прокта FPC, включая конвертированные заголовки от фреймвоков Apple. Сконвертированный проект компилируется через XCode из ObjectPascal, там же и отлаживается (симулятор или реальный дивайс).
Думаю, «исключить» XCode из «пищевой цепочки» в ближайшее время не получится — заливать на дивайсы и подписывать софт будет без XCode сложно. А вот FPC рано или поздно отвалится — его заменят на кросс-компилятор под ARM от Emro.
Небольшие танцы с бубном получаются…
Хоть бы под ARM компилятор быстрее чем за 8 лет сделали, это имхо нужнее будет после появления 8-ой Windows.
Да, я про нормальный компилятор. Embryo для iOS это рантайм выполняющий байт-код.
Какой анонс? Его зарелизило 2-го сентября
Извините.
Анонс продуктов Embarcadero на Хабре.
Черт побери, меня так и подрываем каждый раз высказать простые истины. Ребята просрали все полимеры, однозначно. Я этой среде / языку отдал 10 лет своей жизни, чтобы в итоге принять решение о переходе на C++/Qt и все равно немного жалеть об этом. Мне, блин, рыдать хочется когда я вижу последние релизы (XE / XE2). Здесь есть представители Embarcadero? Можно с кем-нибудь пообщаться?
Рыдать от чего хочется? От того что ушли, а продукт стал развиваться в правильном направлении, или наоборот? Ушли, и смотрите как продукт разваливается?
Давайте только соблюдем рамки. Я своим комментом не хотел открывать холивар. Средой и языком я до сих пор активно пользуюсь, но коммерческие приложения пришлось переводить на другую технологическую площадку. Рыдаю я от выбранной стратегии и направления развития. Если хотите нормально пообщаться, без холивара, давайте продолжим, но без подкалывания друг друга, ок?
Да я не собирался подкалывать, спросил просто, чтоб понять ;) У меня у самого до XE и вот этого роадмапа было схожее и устойчивае желание уйти, причем как раз рассматривал C++/Qt.
Конечно же, продукт разлагается, они двигаются зигзагами, пытаясь залезть в ниши, где им точно ничего не светит (iOS), при этом забывая свои столпы и былые удачные опыты предшественников (тот же CLX / Kylix, дружбу с Qt Framework'ом и т.д.).
CLX, насколько я помню, про*бал Borland еще в 8-ой версии, вохитившись .NET и начав ее поддерживать. Про дружбу с Qt, к сажалению, ничего сказать не могу, но, после покупки у GodeGear, Embarcadero вроде бы выбрали правильный вектор развития. Посмотрите RoadMap повыше, если они не слажают и сделают все как надо, получится довольно неплохой, соответствующий современным трендам, продукт.
Какого хрена в XE2 делает iOS? Почему велосипед в виде FireMonkey? Неужели хватит агрессии и экспириенса? Неужели не было других задач для реализации?

.Net ладно, вовремя появились ребята из RemObjects, они крутые — продукт отпочковался и правильно. Небольшая категория пользователей, стабильный саппорт, динамичное развитие в динамичной среде. Не дай бог бы они его оставили в составе RAD Studio.
Альтернативы какие? Нативные приложения под винду за дельфи остаются, под дотнет предлагается призма, под линукс самим ломиться смысла нет, Ынтрыпрайз поеден явой. Что остается? Нативные приложения под яблочников ИМХО самое то.
Альтернативы чему? Нативные приложения под винду в итоге порождают проблему реюзабильности кода, когда требуется масштабирование на другие платформы. Мы не можем игнорировать стабильный рост Mac OS X / *nix, а как мобильные девайсы?
«Когда требуется масштабирования на другие платформы» — для 90% приложений не требуется никогда. Можно юзать яву — но тогда про ваш десктоп надо будет говорить или хорошо или ничего.
Для 90% приложений не требуется ни одна фича из XE/XE2-релизов, согласитесь. Речь идет о возрождении и попытке удержать рынок + захватить его новые куски. Что они и пытаются сделать, но как?!
Нормально пытаются — яблочный рынок вполне себе капиталоемкий. 64-битность нужна для нормальной интеграции в проводник, FastReport дает возможность фрилансить без обязательного приобретения себя любимого, поддержка документации на лету давно уже нужна. Кроссплатформенность — добавляется прямо сейчас. Что еще надо-то от далеко не самой крупной конторы-производителя?
Т.е. по вашему поддержка (почти готовая) линукс-зоопарка это мелочь жизни, а будучи в нелегкой ситуации «далеко не самой крупной компании» попробовать выйти на рынок dev-приложений под iOS нормально? Про x64 ничего не говорю, это нормальный шаг, пускай и был он долгим. Я лишь спорю о приоритетах, о выборе партнеров и о характере «движения» в целом.
попробовать выйти на рынок dev-приложений под iOS

Из всего под iOS я знаю только XCode и Flash. Это если не брать веб-приложения. Может я и ошибаюсь, но рынок IDE под iOS вроде не такой уж большой.
О нем не знал, спасибо =)
«Т.е. по вашему поддержка (почти готовая) линукс-зоопарка это мелочь жизни,»
Вопрос в степени этого «почти». И субъективно — для меня мелочь. Ибо десктоп на линуксе как-то заработка не обещает, а не десктоп занят плотно и не Дельфи.
«Я лишь спорю о приоритетах, о выборе партнеров и о характере «движения» в целом. „
Ну спорить об этом можно и иногда нужно, но пока принятые решения не дают повода говорить о сливе, тем более эпическом. А выбор партнера — операция, требующая взаимности. Хорошо иметь, скажем, яблоко в союзниках, но надо чтобы и яблочные этого союза хотели.
Для сравнения — эталонный эпический слив борланда: как можно было бросать рынок разработки нативных приложений, вставая в полную зависимость от микрософт, пытаясь портировать непортируемое с гарантированным отставанием от оригинала. Приницпиальная разница с XE2 очевидна, не так ли?
Пожалуй, мы — пример того, что Mac/Linux дает заработок, пускай не прямой, но дает. Заработок, лояльность и радость у пользователей.

О каком провале Borland'a идет речь? Вы относительно .Net'a в 8ке? Ну там никто не бросал native, просто был наркоманский эксперимент уровня iOS'a в XE2 ) Сейчас Prism стал участником рынка, пускай не полноценным, но вполне достойным. Prism — это не borland'овский потуги, а отдельная коммерческая разработка, которая не пыталась хватать звезд с неба, а действовала четко, решитель, осознавая что им нужно. Это уже потом появилась партнерка с Embarcadero.
«Mac/Linux дает заработок» — ну вот Mac поддерживают уже сейчас, Linux обещают в дальнейшем.
«О каком провале Borland'a идет речь? Вы относительно .Net'a в 8ке? Ну там никто не бросал native»
Это как это не бросал? Выкинута старая IDE, все силы на .NET, ЕМНИП восьмера под Win32 вообще не собирала.
«Ну там никто не бросал native, просто был наркоманский эксперимент уровня iOS'a в XE2 ) „
Поддержка iOS — лишь малая часть нововведений XE2. А Delphi 8 — это чистый метадон.
“Prism — это не borland'овский потуги, а отдельная коммерческая разработка, которая не пыталась хватать звезд с неба»
Я в курсе, чья это разработка :)
Да, не собирала. Я имею в виду, что борланд не планировал отказываться от native, само собой. Никаких официальных заявлений, если мне мне память тоже не изменяет, не было. Не было особого шума, просто все ждали чуда, а появилась диковинная хуевина. Ровно как с XE2 :) Хе-хе.

Ладно, мы оба говорим практически об одном и том же, только вы оптимист, а я обманутый вкладчик. Время покажет.

А RemObjects клевые :) Был крайне рад, когда они взяли на работу автора IPS (Carlo, вроде бы).
«Не было особого шума, просто все ждали чуда, а появилась диковинная хуевина. Ровно как с XE2»
Не ровно. XE2 — эволюционное развитие того что было плюс кое-что новое. Delphi 8 — бледная тень того что было минус нативные проекты.
Бляха-муха, Bonart, само собой уровень продуктов 8 vs. XE2 даже сравнивать нельзя, но степень «новизны» сделанного выбора, по крайней мере для меня, очень близка.
Ну почему же? Сам выбор — повернуться лицом к перспективной платформе я могу только одобрить. Вот исполнение в случае Delphi 8 не могу одобрить никак, RemObjects с призмой показал как было надо.
XE2 лучше XE, даже если макось даром не сдалась, Delphi 8 много хуже Delphi 7, даже если нужен только дотнет.
К слову (хоть и не в тему), про FireMonkey — Интерфайс демку с двумя видео публиковал
CLX был пр*ебан еще раньше, кто принимал решение отказаться от биндингов к Qt, пускай даже в формате временного решения? Ведь CodeGear допускали это и обсуждали, а Borland использовал, опыт был, процесс миграции Qt3-Qt4 не слишком сложен. Зачем было связываться с KSDev вообще не понимаю, если кто может — поясните.
Завязываться на нокию? Не самый прстой способ самоубийства.
Будучи одной ногой на краю бездны решиться сделать кульбит с двойным сальто — лучше?
Какая бездна-то? Эмбаркадеро на Дельфи убытков явно не несет, а понадеяться на нокию — можно эпически слить, даже сделав все остальное правильно. Вытащить Дельфи из застоя можно только решительными мерами по развитию, что и делается. Да, есть риск облажаться, но выигрывать без риска нельзя.
Разве у них нормально идут дела? Посмотрите на скорость ухода с рынка специалистов в другие сегменты (.Net / Java / Qt), может количество вакансий? Как вы думаете, решится ли компания стартовать свой проект на Delphi, зная о том, что не смотря на все прелести RAD будут проблемы масштабирования & etc? Вы правы, они себя вытягивают, решительными мерами, но на мой взгляд, крайне странными.
Решается и стартует — я как раз в такой работаю. Проблемы масштабирования на другие платформы не стоят, а со всем остальным Дельфи справляется вполне успешно. Главное что беспокоит — размеры комьюнити в целом и оправданность цены. XE2 ИМХО позитивно работает на оба показателя.
Слишком красочно, дай бог, конечно, но я уже почти смирился.
Я вот пока всё ж не пойму — оно что, обёртка над OpenGL с DirectX-ом? Или что?
Да. И свой набор виджетов.
Плиз, впиши слово «FireMonkey» в пункт про KsDev в топике.
Я недавно делал утилиту на C++/Qt и по сравнению с Delphi не понравилось 2 пункта:
1. В визуальном редакторе форм нельзя использовать свои виджеты — они должны добавляться на формы в ран-тайме. Это всегда так или я что-то проглядел?
2. Грид-грид-грид. По сравнению с DevExpress QuantumGrid, QTableWidget кое-чего не умеет. Может, есть сторонние виджеты для табличного представления данных с множеством возможностей?

Извините, если вопросы для вас банальные. Опыт с C++/Qt пока минимальный.
Да, Qt и его дизайнер, имхо, проигрывают по многим моментам Delphi (плюсов своих тоже достаточно, чего уж говорить, те же built-in layouts). Или же взять, допустим, удобство создания и дистрибуции компонент, я уж не говорю про наличие компонент-репозитариев (точнее их отсутствие). Собственно, народ делится своими наработками крайне слабо, коммерческих продуктов раз-два и обчелся. Замены привычным «титанам» из Delphi-мира практически нет.

Мой опыт Qt сводится к паре приложений-утилит и наблюдений за воссозданием ранее дельфового (родного мне) продукта на новых рельсах.
Всё понял. Спасибо за ответы.
Пока крупные ограничения в QTableWidget не попадались, но всё время крутится мысль в голове «а это он умеет, а то?» :)
QTableWidget умеет многое и очень многое, все ограничено знаниями и возможностями разработчика. Предоставляемые компоненты QListView, QTableView, QTreeView и конечно QAbstractItemView это лишь каркас для необходимого решения. Используя связки моделей, делегатов, прокси моделей можно добиться интересных и довольно сложных решений.
1. Можно, для этого их нужно предвартельно скомлировать в то, что Qt Creator поймет как новый виджет. В гугле есть подробные пошаговые инструкции, там достаточно просто.
1.а. Можно добавить любой виджет, выбрать «promote» и поменять его на свой, если он от него наследуется.
2. Есть конечно. Но вообще у QTableView (это то, частным случаем чего является QTableWidget) достаточно широкие возможности по расширению — после воскурения используемой MVC парадигмы поведение достаточно просто меняется в несколько строк кода.
1. Можно.
2. Расширяйте, там всё очень просто. Полчаса курения мануалов, просмотр подробного примера — и можно сделать грид какой надо, с любыми перделками.
Конкретика где? Уходить на плюсы к фреймворку с чисто плюсовыми интерфейсами, владелец которого только что кинул разработчиков через известно что?
Прошу прощения, а куда уходить, когда нужна кроссплатформа, несколько архитектур + мобильные приложения? Есть альтернатива Qt?
Кроссплатформа+несколько архитектур+мобильные — причем тут Дельфи? Дельфи — это нативные приложения с удобным пользовательским интерфейсом, удобным разработчику языком и визуальным дизайнером. Делать такое еще и для макоси — замечательно, для афони — великолепно (разуммется, когда до ума доведут). Последняя версия — движение как раз в предложенном вами направлении. Что не так? То что линуксовому зоопарку предпочли яблочную упорядоченность?
Понимаю о чем вы, вполне трезвые мысли, просто я начинаю немного агриться и теряю нить беседы. Вот, смотрите, Delphi в его одном из последних стабильных состояний (возьмем, допустим x86 D2007) — всем хорош, он устраивает от и до.

Давайте посмотрим, чего ждало большинство. Может быть iOS? Да ни за что не поверю, это безумие.

Кто мешал договориться с foundation, которое держит FPC на лицензирование последнего? Кто мешал поставить этот, достаточно рыхлый компайлер, построенный на декомпиляции ранних dcc32, на коммерческое русло (оставив оригинал на прежней лицензии), вылизать, привести в порядок, оптимизировать и получить долгожданный профит — код на любимом языке можно компилить под N-платформ.

Встает вопрос VC/RTL — его в любом случае решать надо было. С RTL все более менее ясно, но почему выбор по GUI пал таким макаром? Сколько лет уйдет на приведение в порядок FireMonkey?

*nix — зоопарк, но есть столпы в лице Gtk/Qt. По последнему уже были наработки и достаточно хорошие, да и построенно на CLX было уже не мало. Ведь до последнего, пока не поняли, что их кидают — многие компонент-вендоры держали порты под CLX.
«Вот, смотрите, Delphi в его одном из последних стабильных состояний (возьмем, допустим x86 D2007) — всем хорош, он устраивает от и до. »
Я как раз на нем пишу — не устраивает. Нормальный юникод, генерики, анонимные методы, атрибуты, автодокументация — иногда аж скулы сводит, когда приходится раз за разом вместо нормального решения «кодоблудить».
«Давайте посмотрим, чего ждало большинство. Может быть iOS? Да ни за что не поверю, это безумие. „
Я не ждал, но рад. Ибо дополнительное поле для заработка без необходимости копаться в Objective C
“Кто мешал договориться с foundation, которое держит FPC на лицензирование последнего?»
Обычно такие вопросы не имеют достоверного ответа по построению — возможно, договариваются прямо сейчас, возможно — владельцы упертые. Девок вон тоже было бы хорошо включить в поставку — но видно не все сразу.
«С RTL все более менее ясно, но почему выбор по GUI пал таким макаром?» Полагаю, потому что к Qt/Gtk интерфейс всегда будет оберточным, а две обертки до натива — это не Дельфи стиль ни разу. Плюс, предпочли опираться на свое, не надеясь ни на комьюнити, ни на владельца.
«Ведь до последнего, пока не поняли, что их кидают — многие компонент-вендоры держали порты под CLX.»
А как у CLX с макосью? И запах кидалова, пусть и еще борландовского вендоров точно не привлечет. А тут сразу видно — за свою библиотеку эмбаркадеро будет держаться всеми частями тела.

Я как раз на нем пишу — не устраивает. Нормальный юникод, генерики, анонимные методы, атрибуты, автодокументация — иногда аж скулы сводит, когда приходится раз за разом вместо нормального решения «кодоблудить»

Развитие среды и синтаксиса отдельный вопрос. Тут я целиком согласен, претензий не имею.

Я не ждал, но рад. Ибо дополнительное поле для заработка без необходимости копаться в Objective C

А чему радоваться? Прежде чем это станет полем для заработка — его нужно пилить и пилить. В текущем представлении это далеко не сказка и выбор в сторону Delphi как средства разработки под iOS крайне сомнителен, зато ощущение что их колбасит по трендам (ios, azure, android) без адекватной стратегии развития есть.

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

Боже упаси девок загонять в коробку. Возможно, договариваются, возможно, упертые, но, скорее всего, никто не стал связываться с FPC на должном уровне. Куда проще интегрировать его на халяву в tool chain и не париться, да?

Полагаю, потому что к Qt/Gtk интерфейс всегда будет оберточным, а две обертки до натива — это не Дельфи стиль ни разу. Плюс, предпочли опираться на свое, не надеясь ни на комьюнити, ни на владельца.

С точки зрения рисков, возможно, вы правы.

А как у CLX с макосью? И запах кидалова, пусть и еще борландовского вендоров точно не привлечет. А тут сразу видно — за свою библиотеку эмбаркадеро будет держаться всеми частями тела.

CLX -> Qt3 bindings, Qt под Mac OS X есть, а их идеология Qt Anywhere позволяет рассчитывать на счастливое будущее. А в чем запах кидалова? Nokia официально заявила, что Qt будет независим, ровно как и его команда, но при хорошем саппорте и пока что на родных площадях.
«CLX -> Qt3 bindings, Qt под Mac OS X есть, а их идеология Qt Anywhere „
Вот это эмбаркадеро наверняка и не нравится — обертка над оберткой над оберткой, причем контроль есть только над верним слоем.
Коллеги, может кто в курсе — а что у них с поддержкой Linux / Unix?
Технические подробности уже известны? Они собираются базироваться на Qt, Gtk, чем-то менее известном или вообще свое поверх X11 и POSIX писать?
Насколько я понял, свое. Вероятность наличия биндингов к Qt/Gtk ничтожно мала, даже на большом временном расстоянии.
FireMonkey + свои компиляторы. Это по слухам ;)
Да я не собирался подкалывать, спросил просто, чтоб понять ;) У меня у самого до XE и вот этого роадмапа было схожее и устойчивае желание уйти, причем как раз рассматривал C++/Qt.
Не туда написал :(
о_О, Delphi еще развивается? Сегоднф за пивом надо вспомнить Delphi 3/4, VCL, BDE…
Похоже пиво уже действует.
Да, слили карму за комментарий не по теме (хотя он к ней относится в какой-то мере). Надо бы не писать по пятницам больше (:
Кто копался в Fire Monkey, что это вообще такое? Embarcadero решило запилить собственный WPF? Из хвалебных обзоров ясно ровным счетом ничего. Как это реализовано? Написали свой графический движок и переписали под него всю иерархию компонентов, начиная с TPersistent?
До WPF/QML далековато. Породить из бывшего skin engine что-то стоящее сложно, без обидняков в сторону KSDev.
Выпустили бы годик назад, я бы тогда оценил все прелести новшеств, а теперь уж ушёл совсем другие просторы разработки.
ура, скоро будет тоталкоммандер х64
Не факт что скоро, слишком много доработок =) С 2-ой Delphi версии сразу на XE2… Хм =)
И не только он один а еще и FL Studio
Я правильно понимаю что нынче разработка всех этих продуктов ведется в Петербурге?
Почему вы так решили?
Потому что видел на HH.RU позиции Embarcadero в Питере.
У них много представительств и команд по всему миру, так же как и разрабатываемых программных продуктов, в т.ч. напрямую не связанных с IDE.
А кто является конечными пользователями их продуктов? Просто я так краем уха слышал, но ни разу ни встречал разработчиков которые работают с этими продуктами.
Пользователей много — если одним словом, то все разработчики под Windows-платформу: системный софт, мультимедия, ShareWare, бизнес (ERP и CRM) и многое другое. Особенность IDE как раз и заключается в том, что там есть практически ВСЕ инструменты под любые нужды разработчиков.

Вот тут можно посмотреть на общедоступные приложения, написанные с использованием Delphi и C++ Builder:
www.embarcadero.com/rad-in-action/application-showcase

В вакансии в Питерский офис вроде намекалось, что берут для разработки FireMonkey
Жаль, что C++ Builder так и не поддерживает x64.
Будет в следующем году =)
Ребят! Может я конечно чего то недопонимаю, но вы видели цены по ссылке в шапке? Как вообще такой продукт может быть конкурентоспособен для людей стартующих новые проекты?
Кроме того, абсолютно невнятные разработчики, которые ещё 10 лет назад «потеряли нить игры». Нокия в её нынешнем состоянии выглядить верхом собранности и целеустремленности по сравнению Borland>Inprise>Borland>Codegear>Embarcadero. Вы знаете что им в голову придет завтра? Лично я — нет.
Да и сам продукт. Даже какая нибудь Eclipse/SWT покажется целостнее. Не говоря уж о Qt.
Данный продукт ориентирован на разработку коммерческих приложений. Цены начинаются от 6000 рублей за лицензию. Для сравнения, цена на Visual Studio — от 9000.

Что касается обратной совместимости — то тут без вопросов — можно без проблем обновляться на более новые версии с минимум исправлений в коде.
> цена на Visual Studio — от 9000
Это самые дорогие редакции. Можно тот же VS2010 Pro за 1200$ купить.
Я полагаю, 9000 это было рублей за то же самое русское. Сейчас розничная цена выше, но для компаний закупающих всего разного может быть, где-то так и есть.
>>Как вообще такой продукт может быть конкурентоспособен для людей стартующих новые проекты?
Легко. Особенно с учетом того простого факта, что нативный десктоп для винды больше делать особо не на чем.
Слушайте, ну давайте хоть как-нибудь сегментируем тогда рынок и выделим все-таки ту секцию, где «легко». Потому что ни хрена не легко. Допустим, мы занимаемся чем-то на стыке Entertainment / Travel / Navigation / Government — нам Delphi оказалась противопоказана для public продуктов, при этом внутреннюю автоматизацию частично закрываем (возможно, временно) D2007. Почему противопоказана? Уже говорил — реюзабильность решений, кроссплатформа / различные архитектуры / мобильные устройства.

Что значит не на чем делать нативный десктоп для винды? Почему из натива уходят те же плюсы с кутями? Почему ограничение на native столь жесткое — куда деть Java / .Net? Последний по набору «готовых кирпичиков» уже практически не отличается от Delphi.
Ответ очевиден — Java и Net требует тащить с собой соответствующие фреймворки на сотню мегабайт. А Java — так там вообще такой бардак для создания современного GUI, что люди даже не смотрят в эту сторону.

Вот и остается небольшой выбор. Пока еще никто не придумал вменяемого решения для мультиплатформенной разработки приложений под десктоп, веб и телефоны.
Потому они и шли последними в моем списке. При этом сегодня говорить «тащить» несколько некорректно. .Net перестал быть диковинной новинкой, к примеру, embedded, начиная с XP SP2 (если мне память не изменила). И, да, там нет сотни мегабайт.

Вменяемые решения есть и, черт побери, вполне успешно используются и заменяют старые дельфовые солюшены. Тоже был удивлен и долгое время противился, но это так. Я сейчас говорю про Qt, который тянет в районе 7-8 метров (desktop), может быть статически слинкован & etc.

Мы можем стоять весь день упершись головами и мычать на тему того, будет ли хорошая жизнь у Delphi или нет. То что Delphi жив и в любом случае будет жить — это факт (у меня прямо сейчас открыт XE и идет работа над небольшим проектом, связанным с БД), но выбранный ими путь спорен для меня и, в силу этого, грустно мне и печально.
«кроссплатформа / различные архитектуры / мобильные устройства» нужно далеко не всем, скажу больше — далеко не большинству заказчиков.
.NET — хорошо и вкусно, но, зараза, жрет и тормозит.
«Почему из натива уходят те же плюсы с кутями?»
Потому что плюсы с кутями, если не нужна кроссплатформенность, на винде никому кроме плюсов же не нужны.
Дальфа тоже отнатива с этим обезьяном уплывает… контролы все само-рисованные, нативного — лишь OpenGL да DirectX
Я люблю Delphi, но нативный десктоп под винды вроде бы ещё на Visual C++ можно делать… Или уже нет?
Делать можно, но примерно так же как медведю кататься на велосипеде.
Sign up to leave a comment.

Articles