Изначально язык Ada создавался Пентагоном как монолитная конструкция с достаточно чёткой концепцией его использования. И в этом плане на момент своего создания язык Ada был на самом деле очень хорош.
Но, когда появилась и начала активно развиваться концепция объектно-ориентированного программирования, которую органично вписали во многие существовавшие на тот момент языка, например в C или Pascal, либо создав новые, изначально объектно ориентированные языки, такие как Java, разработчики Ada пошли своим путём. Да, в языке Ada изначально было понятие пакетов, которое позволяло реализовывать часть механизмов из концепции ООП. Но делалось это более громоздкими способами с точки зрения синтаксиса и удобства написания и восприятия программ. Например, та же точечная нотация при работе с объектами, насколько я знаю, появилась только в стандарте Ada 2005. А до этого момента использовалась так называемая «процедурная нотация».
Или то же нововведение в синтаксис, которое должно помогать компилятору ловить ошибки с перекрываемыми функциями и процедурами, когда для перекрываемых функция необходимо в начале указывать ключевое слово overriding, а для всех новых процедур и функций not overriding. В итоге получился механизм, который либо бесполезен, поскольку данные ключевые слова не являются обязательными, либо создаёт дополнительные заморочки разработчику, если он решает активировать в компиляторе эту возможность и вынужден будет многократно писать not overriding, поскольку новые функции в большой объектной иерархии добавляются постоянно и их часто больше, чем перекрываемых.
Кроме того, удобство использования того или иного языка определяются не только самим языком, но и наличием удобных и эффективных интегрированных сред разработки, которые включают в себя как инструментальные средства, так и развитые программные библиотеки. А и с тем, и с другим, у Ады, увы, всегда были проблемы, которые изначально во многом были обусловлены той сферой применения, под которую она разрабатывалась.
Кстати, появление проекта Qt Ada, о котором вы упомянули в самом начале, это как раз попытка решить данную проблему путём скрещивания библиотеки и среды разработки Qt с компилятором Ada. Но одним только GUI разработка больших прикладных систем не ограничивается. Нужна ещё масса других библиотек для работы с СУБД, графикой, документами в стандартных форматах, тот же PDF, например.
Кстати, тот же Object Pascal, к сожалению, постепенно умирает как раз по причине того, что под него всё сложнее найти качественные библиотеки, соответствующие новым стандартам или поддерживающие последние редакции форматов тех или иных файлов данных. Особенно когда речь заходить о Free Pascal, а не о платной среде Delphi от Embacadero. Под последнюю ещё можно что-то найти из платных решений, но многие из этих решений не работают с Free Pascal или реализуют там не полный функционал, либо реализуют его менее качественно (много ошибок из-за менее тщательной отладки). Что в общем-то понятно и объяснимо. Если люди на этом зарабатывают, то основные усилия будут вкладываться туда, где больше платят. А сообщество Free Pascal деньги платить не любит.
Именно потому, что в основе язык Ada, который морально устарел и не имеет тех удобств в программировании, которые есть у полноценных объектно-ориентированных языков.
У языка Ada, несомненно, есть определённые достоинства, но они не перевешивают имеющихся в нём минусов.
Я правильно понял, что библиотека, которую вы в конечном итоге использовали, из состава CodeTyphon, является просто фреймворком над OpenGL?
Просто мы тоже достаточно долго выбирали библиотеку для графической части, но пока так ни на чём и не остановились. Либо не устраивает функционал, либо скорость работы, либо и то, и другое одновременно. :(
В конечном итоге 3D сделали через OpenGL, частично использовав GLScene, частично написав свой код, поскольку другого кроссплатформенного варианта для этих целей просто нет. А вот с реализацией 2D возникли некоторые проблемы, особенно в части использования прозрачности. Поэтому пока вывод 2D через OpenGL отложили и сделали первый вариант просто через Canvas, но отказавшись от использования прозрачности.
Проблема была в том, что на платах AMD и NVidia реализация OpenGL при работе с 2D графикой отличаются. В итоге при построении сложных изображений приходится уходить на уровень самых базовых примитивов: отрезок и треугольник. Но когда начинаешь строить ломанную линию из отдельных сегментов, используя при этом прозрачность, то при толщине в несколько пикселов концы отрезков перекрываются и в этом месте прозрачность отображается не так, как требуется.
Если в проекте 15 млн. строк, и это именно одно монолитно приложение, то на 99% это плохо структурированный «клубок спагетти», содержащий большое количество старого кода, который тащится либо в целях «совместимости», либо просто потому, что некому навести порядок и провести нормальный реинжиниринг.
Также из практики могу предположить, что имеет место быть слабое объектно-ориентированное программирование или не грамотно построенная иерархия классов, из-за чего приходится писать много похожего или вообще дублирующегося кода.
Мне приходилось работать с подобным «большим проектом», в котором было сразу четыре фреймворка для работы с классами, которые были написаны в разное время и с разным пониманием того, что там должно быть. При этом на 90% код этих фреймворков, а также иерархий классов, которые от них строились, повторялись, но каждый для своей ветки.
Кстати, если попробовать собрать проект их 15 млн. строк на чём нибудь типа Qt в паре практически с любым компилятором C++, то такая сборка будет занимать не несколько минут, а несколько часов.
Во первых, хочу выразить благодарность за статью и «снимаю шляпу» перед вашим профессионализмом и мастерством.
Во-вторых, что касается выбора инструментальной среды. Мы сейчас тоже реализуем крупный проект, перед началом которого проводили выбор среды разработки. Поскольку изначально одним из условий ставилось обеспечение кроссплатформенности, то многие из популярных сред отпали «на старте». Java в корне не понравился своей производительностью и прожорливостью к ресурсам. У C# проблемы с кроссплатформенностью, что бы там не говорили его адепты. В итоге осталось два реальных варианта. Qt и C++ или Lazarus + FreePascal.
Так вот, в итоге мы выбрали именно Lazarus + FreePascal, поскольку оказалось, что вести большой проект небольшой командой разработчиков (у нас тоже 3 человека) на Lazarus + FreePascal намного проще и быстрее, чем на связке Qt и C++. Причём мы даже сделали два средних проекта на Qt и C++, которые только убедили нас в этом. Сборка проекта происходит намного дольше, управление файлами существенно сложнее, «плясок с бубном» при сборке под разные платформы заметно больше.
В конечном итоге основной проект был запущен на Lazarus + FreePascal и имеющиеся на сегодня результаты показывают, что это был правильный выбор. Правда, мы не используем параллельно сборку на Delphi и Lazarus, что заметно упрощает нам жизнь. Часть когда когда-то была написана именно на Delphi, потом был небольшой период совместного использования кода, но сейчас уже практически всё отвязали от поддержки Delphi. В основном потому, что нам оно не требуется, а без проверки сборки в Delphi смысла прописывать условную компиляцию особого нет, только лишняя трата времени.
Но, когда появилась и начала активно развиваться концепция объектно-ориентированного программирования, которую органично вписали во многие существовавшие на тот момент языка, например в C или Pascal, либо создав новые, изначально объектно ориентированные языки, такие как Java, разработчики Ada пошли своим путём. Да, в языке Ada изначально было понятие пакетов, которое позволяло реализовывать часть механизмов из концепции ООП. Но делалось это более громоздкими способами с точки зрения синтаксиса и удобства написания и восприятия программ. Например, та же точечная нотация при работе с объектами, насколько я знаю, появилась только в стандарте Ada 2005. А до этого момента использовалась так называемая «процедурная нотация».
Или то же нововведение в синтаксис, которое должно помогать компилятору ловить ошибки с перекрываемыми функциями и процедурами, когда для перекрываемых функция необходимо в начале указывать ключевое слово overriding, а для всех новых процедур и функций not overriding. В итоге получился механизм, который либо бесполезен, поскольку данные ключевые слова не являются обязательными, либо создаёт дополнительные заморочки разработчику, если он решает активировать в компиляторе эту возможность и вынужден будет многократно писать not overriding, поскольку новые функции в большой объектной иерархии добавляются постоянно и их часто больше, чем перекрываемых.
Кроме того, удобство использования того или иного языка определяются не только самим языком, но и наличием удобных и эффективных интегрированных сред разработки, которые включают в себя как инструментальные средства, так и развитые программные библиотеки. А и с тем, и с другим, у Ады, увы, всегда были проблемы, которые изначально во многом были обусловлены той сферой применения, под которую она разрабатывалась.
Кстати, появление проекта Qt Ada, о котором вы упомянули в самом начале, это как раз попытка решить данную проблему путём скрещивания библиотеки и среды разработки Qt с компилятором Ada. Но одним только GUI разработка больших прикладных систем не ограничивается. Нужна ещё масса других библиотек для работы с СУБД, графикой, документами в стандартных форматах, тот же PDF, например.
Кстати, тот же Object Pascal, к сожалению, постепенно умирает как раз по причине того, что под него всё сложнее найти качественные библиотеки, соответствующие новым стандартам или поддерживающие последние редакции форматов тех или иных файлов данных. Особенно когда речь заходить о Free Pascal, а не о платной среде Delphi от Embacadero. Под последнюю ещё можно что-то найти из платных решений, но многие из этих решений не работают с Free Pascal или реализуют там не полный функционал, либо реализуют его менее качественно (много ошибок из-за менее тщательной отладки). Что в общем-то понятно и объяснимо. Если люди на этом зарабатывают, то основные усилия будут вкладываться туда, где больше платят. А сообщество Free Pascal деньги платить не любит.
У языка Ada, несомненно, есть определённые достоинства, но они не перевешивают имеющихся в нём минусов.
Просто мы тоже достаточно долго выбирали библиотеку для графической части, но пока так ни на чём и не остановились. Либо не устраивает функционал, либо скорость работы, либо и то, и другое одновременно. :(
В конечном итоге 3D сделали через OpenGL, частично использовав GLScene, частично написав свой код, поскольку другого кроссплатформенного варианта для этих целей просто нет. А вот с реализацией 2D возникли некоторые проблемы, особенно в части использования прозрачности. Поэтому пока вывод 2D через OpenGL отложили и сделали первый вариант просто через Canvas, но отказавшись от использования прозрачности.
Проблема была в том, что на платах AMD и NVidia реализация OpenGL при работе с 2D графикой отличаются. В итоге при построении сложных изображений приходится уходить на уровень самых базовых примитивов: отрезок и треугольник. Но когда начинаешь строить ломанную линию из отдельных сегментов, используя при этом прозрачность, то при толщине в несколько пикселов концы отрезков перекрываются и в этом месте прозрачность отображается не так, как требуется.
Также из практики могу предположить, что имеет место быть слабое объектно-ориентированное программирование или не грамотно построенная иерархия классов, из-за чего приходится писать много похожего или вообще дублирующегося кода.
Мне приходилось работать с подобным «большим проектом», в котором было сразу четыре фреймворка для работы с классами, которые были написаны в разное время и с разным пониманием того, что там должно быть. При этом на 90% код этих фреймворков, а также иерархий классов, которые от них строились, повторялись, но каждый для своей ветки.
Кстати, если попробовать собрать проект их 15 млн. строк на чём нибудь типа Qt в паре практически с любым компилятором C++, то такая сборка будет занимать не несколько минут, а несколько часов.
Во-вторых, что касается выбора инструментальной среды. Мы сейчас тоже реализуем крупный проект, перед началом которого проводили выбор среды разработки. Поскольку изначально одним из условий ставилось обеспечение кроссплатформенности, то многие из популярных сред отпали «на старте». Java в корне не понравился своей производительностью и прожорливостью к ресурсам. У C# проблемы с кроссплатформенностью, что бы там не говорили его адепты. В итоге осталось два реальных варианта. Qt и C++ или Lazarus + FreePascal.
Так вот, в итоге мы выбрали именно Lazarus + FreePascal, поскольку оказалось, что вести большой проект небольшой командой разработчиков (у нас тоже 3 человека) на Lazarus + FreePascal намного проще и быстрее, чем на связке Qt и C++. Причём мы даже сделали два средних проекта на Qt и C++, которые только убедили нас в этом. Сборка проекта происходит намного дольше, управление файлами существенно сложнее, «плясок с бубном» при сборке под разные платформы заметно больше.
В конечном итоге основной проект был запущен на Lazarus + FreePascal и имеющиеся на сегодня результаты показывают, что это был правильный выбор. Правда, мы не используем параллельно сборку на Delphi и Lazarus, что заметно упрощает нам жизнь. Часть когда когда-то была написана именно на Delphi, потом был небольшой период совместного использования кода, но сейчас уже практически всё отвязали от поддержки Delphi. В основном потому, что нам оно не требуется, а без проверки сборки в Delphi смысла прописывать условную компиляцию особого нет, только лишняя трата времени.