Вот что нам, разработчикам, действительно нужно? Я тут как раз сегодня задумался — накидал несколько букв, сначала комментом, а потом решил, что оно на пост тянет:
Во-первых, меня ужасно раздражает, что всю разработку под винды уже который раз пытаются пересадить подальше уровнем от железа. Побольше толстых прокладок напихать между прикладным софтом и процессором, между пригладным софтом и ОС. ИМХО, ближе к native коду нужно стремиться, ближе к железу, ближе к ОС! К любому железу, к любой ОС. Нужно развивать Object Pascal как альтернативу C++, отличающуюся развитыми средствами ООП, синтетическим сахаром, за который мы Паскаль любим, мощным IDE и родным быстрым однопроходным компилятором.
Кроме того, нужны развитые возможностями интеграции со сторонними библиотеками. Этого, по сравнению с C, очень не хватает. Вокруг множество библиотек, всякие интерпретаторы чего только не умеют, а для Delphi библиотеки нынче фиг найдёшь, и в итоге с известным трудом сам делаешь. А потом переделываешь при обновлении API. Для этого — генераторы тонких обёрток нужны. У Лазаруса есть поделка под названием pas2h, но её ж развивать нужно, а то интегрировать! Занялись бы они, а?.. А ещё лучше — попробовать осмыслить и сделать прозрачное использование в одном проекте модулей на разных языках — в частности, прямое подключение h-файлов библиотек. Уверен, что линкер можно сделать так, что бы он с этим справлялся.
Встроенный ассемблер — был, покоцали его… Ассемблерные вставки теперь нельзя, можно только целые процедуры. Зачем?.. хз. Надо вернуть его, и развивать, документировать (документации по встроенному ассемблеру вовсе никогда не было!), сделать поддержку всех современных наборов команд для процессоров и сопроцессоров!
Средства для интеграции внешних компиляторов вместо собственного. Сменные компиляторы — под разные платформы, от разных производителей. Например, я видел, что Intel делала оптимизирующий компилятор для своих процессоров — было б здорово уметь его использовать для программ на Delphi.
В комплекте нужны встроенные синтаксические средства доступа не только к dll (это давно есть и это хорошо) и через них к ActiveX (что тоже давно есть, но не столь красиво оформлено, как могло бы быть), но и к библиотекам .net, Юникса, MacOS, iOS, Android и т.п. — в общем, поддержка платформообразующих библиотек. Хотя, я не видел, как это оформлено для FireMonkey, может оно там уже и есть… Но странно, что про это не гудят на всех углах громче, чем гудят про само FireMonkey. А вот про возможность использовать в native Delphi мощь библиотек .net я вовсе не слыхал.
Соответственно, на тех средствах было бы верно иметь обёртки для API базовых библиотек .net, Cocoa, iOS, Android SDK, к X Window System и т.п. Возможно, генерящиеся налету теми генераторами тонких обёрток, о которых я выше говорил… И документация к ним чтобы могла быть привязана из любых источников, как локальных, так и онлайновых.
Поверх них, как уровень абстракции типа VCL — тонкая же обёртка к Qt или вовсе порт Qt под Delphi. Как альтернативу VCL, больной наследственными болезнями, осложнёнными завязками пакетов компонентов на пакеты, которыми пользуется сама IDE. Должна быть поддержка смены дизайнеров форм и формата хранения этих форм, должна быть независимость кода дизайнеров от кода и базовых библиотек среды разработки, чтобы можно было в дизайнере использовать измененную VCL или вовсе не VCL.
Должна быть двусторонняя онлайн-конвертация кода и форм во что угодно, плагинами на открытом API, а не только чем-то встроенным в диаграммы ModelMaker. В частности, мне кажется вполне можно уже на лету конвертить код не только в код C++ и обратно (что, кстати, один из прекрасных вариантов реализации импорта h-файлов) и на язык ассемблера (и то и другое полезно и для использования сторонних компиляторов типа GNU и интеловского), но и прямо в исполняемый бинарный код, то есть компиляцию делать на лету, так чтобы для запуска оставалось лишь линкеру поработать, выкидывая неиспользуемое и формируя исполняемый файл.
И кстати вот, сборка пакетов и дистрибутивов под разные платформы — тоже плагинами, чтобы сообщество могло участвовать в расширении сфер влияния.
Вопрос только — что тут и как продавать? Какой могла бы быть успешная стратегия монетизации подобного проекта? Лазарус с FreePascal вон догоняет, и теоретически тоже может всё это сделать…
Автор: Nashev
