Сегодня у нас первая часть большого интервью с Всеволодом Леоновым, российским евангелистом из компании Embarcadero Technologies, который расскажет нам из первых уст про самые последние и горячие новости из мира Delphi.
В сегодняшней первой части мы поговорим про особенности новейшей Delphi XE3, рассмотрим её детали поддержки Windows 8, а также коснемся предстоящего перехода на LLVM. Кроме того, Всеволод выскажет свое отношение к проекту Lazarus, попутно передаст своё «горячее спасибо» корпорации Microsoft за “её гуманизм по отношению к разработчикам”. Во второй части, немного подняв градус полемики, мы продолжим обсуждать Microsoft и её ”гигабайтный фреймворк” на базе платформы .Net, при этом не теряя из вида всех особенностей продуктов от Embarcadero Technologies.
От себя выскажу предположение, что это интервью, вероятней всего, будет интересно не только бывшим и нынешним приверженцам продуктов Borland/Embarcadero, но и всем любителям MS Visual Studio, так как речь у нас пойдет, в том числе, о весьма противоречивых современных трендах развития в области инструментов для программной разработки.
– Всеволод, буквально недавно была представлена последняя версия вашего главного продукта – Delphi XE3. Не могли бы вы перечислить и описать его главные новшества?
– Продукт Delphi XE3 является продолжением нового поколения средств быстрой разработки семейства Delphi. Напомню, в 2011 году вышла Delphi XE2 с платформой FireMonkey, которая является альтернативой библиотеки визуальных компонентов VCL.
– Кстати, почему потребовалось создавать новую библиотеку FireMonkey вместо уже существующей VCL?
– Да, она очень похожа на VCL по методам использования и составу компонентов (кнопки, метки, поля ввода, меню и т.д.), но обладает способностью быть перенесенной на другую операционную систему. FireMonkey – кроссплатформенная. Приложения, созданные с помощью FireMonkey, могут компилироваться и под Windows, и под Mac OS. Практически в один-два «клика» мы можем пересобрать проект под принципиально другую операционную систему. Практически все демонстрационные проекты, поставляемые с Delphi на платформе FireMonkey, имеют две версии: одну под Windows, другую – под Mac OS. И для этого не нужно вносить изменения в исходный код приложения!
Хотя библиотека FireMonkey отличается от своей предыдущей версии в Delphi XE2 лишь в сторону увеличения компонентной базы и, следовательно, прикладных возможностей, сама же новая версия XE3 помимо этого добавила много новых «степеней свободы» для разработчиков. Это поддержка создания приложений в стиле Windows 8, а также визуальный дизайнер гибких связей Visual LiveBindings. Сначала разберёмся с Windows 8. Не все восприняли Windows 8 с восторгом, но мы верим в её перспективы и постарались максимально облегчить создание приложений с новой метафорой интерфейса. Есть разные подходы к созданию приложений в стиле Windows 8, но опять же – универсальные механизмы стилизации в основе VCL и FireMonkey уже сейчас помогают корпорации Microsoft ликвидировать дефицит прикладного ПО для новой ОС.
Visual LiveBindings – для пользователей «классических» версий Delphi (1-7), а также релизов последнего поколения (2009-XE2), это будет новым шагом и в проектировании связей между объектами и компонентами в приложениях, и в построении более гибких и универсальных архитектур. Теперь мы используем техники визуального программирования не только к созданию прототипа пользовательского интерфейса, но и для проектирования внутренних связей на основе механизма выражений или «живого связывания». Теперь Delphi XE3 оснащена действительно новыми и интересными технологиями, которые без значительного усложнения процесса разработки по-настоящему дают еще более развитые возможности для создания новых решений, а также для модификации и развития уже существующих.
Возвращаясь к конкурентным преимуществам Delphi XE3. Кроссплатформенная библиотека FireMonkey сочетает в себе классические преимущества RAD-средств – быстрая и гибкая разработка, а также возможность быстро перекомпилировать проекты под разные платформы. Все это создается в «нативном» коде, не требующим промежуточных сред выполнения. Мы уже знаем, как сложно бывает обеспечить распространение приложений, которым нужен именно конкретный «фреймворк», версии которого также влияют на процесс разработки и эксплуатации. Ну, а кроме того, достаточно сложно представить себе ситуацию, когда Visual Studio станет поддерживать «нативную» разработку, к примеру, под Mac OS или iOS.
Наш девиз – один и тот же исходный код, а компиляция под различные платформы.
– Поскольку это сейчас очень актуально, сразу мой уточняющий вопрос по новомодной Windows 8: как у вас реализована поддержка новейших продуктов от MS? Я слышал, что работа с LiveTile у вас реализована через враппер, скомпилированный вами же на MS VC++, можете последовательно рассказать, что и как у вас в этой области устроено?
– Embarcadero является технологическим партнёром Microsoft, мы очень внимательно следим за их продуктами, всецело поддерживая их линию на обновление, по крайней мере, операционной системы и СУБД MS SQL Server. К средствам разработки мы относимся, честно говоря, нейтрально, т.к. чётко представляем себе, чем мы лучше. Windows 8 мы поддерживаем за счет стилизации как новых, так уже и существующих desktop-приложений, причем без разницы, с использованием какой библиотеки они сделаны – Windows-ориентированной VCL или кроссплатформенной FireMonkey. Вы берете уже сделанный на Delphi проект и практически мгновенно, применив к нему «стиль Windows 8», делаете его абсолютно интерфейсно-родным для новой ОС. Чисто технически компоненты остаются теми же, но внешний вид их эмулирует стиль Windows 8, который оптимизирован под сенсорные экраны планшетов. Более быстрый способ сложно себе представить.
Что касается интегрирования с механизмом «живых плиток» (LiveTile), то здесь есть различные подходы. На текущий момент мы это делаем так – вы берете обычный проект VCL или FireMonkey и одним компонентом TLiveTile добавляете возможность интеграции с новым «стартовым экраном Windows 8». Вы сможете взаимодействовать с приложением при помощи вашей «живой плитки» даже в режиме обновления его содержимого. Последнее, кстати, достаточно спорный момент. Пока я не видел ничего более внятного и полезного, чем прогноз погоды и ротация фотографий. Сама идея-то великолепна, но как она может помочь пользователям прикладного ПО? Пока ответа от самой корпорации Microsoft я не увидел, хотя специально посетил Windows 8 Summit в Москве.
Технологически мы решаем проблему использования LiveTile путем небольшой сервисной программы, которая, используя новый API, полностью контролирует LiveTile. Хорошо ли это? Достаточно ли это технологично? В любом случае, пока это является достаточно удачным и для нас, и для программистов на Delphi, использующих компонент TLiveTile в рамках обычного desktop-приложения. Установка небольшой сервисной программы на рабочую станцию с Windows 8 не является архисложной задачей, тем более, что обычно даже корпоративный софт распространяется в виде инсталляционного пакета вместе с драйверами СУБД и т.д., так что еще один маленький сервис в общем наборе ничего не усложнит.
Технически этот наш сервис – да, является полноценным WinRT-приложением и создан в Visual Studio. Но всем известный факт, что интерфейсная часть Skype на момент его приобретения Microsoft была создана на Delphi, а сразу после этого указанная выше корпорация опубликовала вакансию на должность Delphi-разработчика. Некоторые горячие головы со стороны фанатов Delphi отметились рядом шуток, но мы не видим ничего такого, когда используемые продукты оцениваются по их функциональным качествам и применяются без каких бы то ни было предрассудков.
Например, один из продуктов-конкурентов нашего кроссплатформенного средства администрирования баз данных – DBArtisan – разработан на Delphi. Такая ситуация встречается очень часто. А закончить очередную «священную войну» хочется следующим примером. Есть внутренний чемпионат по футболу, когда клубы соревнуются между собой. А есть чемпионат мира, когда игроки разных команд играют за одну сборную. На поле Windows 8 мы с Microsoft однозначно играем вместе, а не друг против друга. Например, мы технологически не позволяем применять стиль Windows 8 для приложений под Mac OS, хотя, как ни странно это звучит, есть масса таких запросов со стороны прикладных разработчиков.
– Какие вообще платформы и операционные среды поддерживает Delphi XE3 на данный момент? Насколько я знаю, это достаточно всеядная и универсальная среда – очертите её границы применения. Кстати, какова судьба Kylix и поддержки Linux?
– «Всеядность» и универсальность, которую мы называем «кроссплатформенностью», достигается за счет абстрагирования уровня визуализации и объектной модели визуального компонента. Представьте себе «кнопку», которая будет нарисована тем API, для которой данный проект скомпилирован. Также нужно добавить тот факт, что мы еще применяем «платформенно-ориентированный» стиль. Ваше приложение не просто скомпилируется под Windows, а затем под Mac OS. Для Mac OS оно будет еще и выглядеть, как стандартное приложение под данной операционной системой. И меню, и кнопки, и прочие компоненты визуального интерфейса будут «родными» с точностью до пикселя. Но если вы хотите единый стиль вашей системы для любой операционной системы, то можно применить именно ваш оригинальный стиль, явно подчёркивающий бренд вашей компании – не только по функциональному набору приложения, но и даже по внешнему виду.
Судьба Kylix во много характерна для ИТ-продуктов. Далеко не все даже очень сильные бренды выдержали проверку временем в рамках сверхбыстрого развития аппаратных и программных средств, передела рынков и даже просто изменяющихся трендов из области ИТ-моды. Некоторые из них были действительно «тупиковыми» ветвями эволюции (да-да, многие вспомнили некоторые версии одной из самых популярных и по сей день операционной системы). Некоторые послужили фундаментом для развития понимания и стартовой площадкой для последующего роста. Kylix пал жертвой двух обстоятельств. Первое – многообещающий рост популярности Linux в качестве операционной системы для настольных компьютеров (в тот момент я работал системным администратором – каждый второй мой коллега дома обязательно имел Linux, иногда и в качестве основной ОС, а те, кто не знал Linux, становились изгоями). Но потом к середине 2000-х был резкий спад. Желающих создавать прикладного ПО резко поубавилось, хотя продукт был хороший и до сих пор люди его успешно используют. Вторым, но уже не обстоятельством, но промахом компании Borland стало разделение двух продуктов Delphi и Kylix. Началось создание «кроссплатформенного» клона VCL – библиотеки CLX. Программисты в основной массе предпочитали работать в Windows, а Kylix использовали только для сборки проекта под другую платформу. Но это был хороший опыт, на его основе Embarcadero выстроила более успешную, на наш взгляд, концепцию для развития Delphi. Едина среда разработки, кроссплаторменная реализация компонентной платформы FireMonkey, сборка проекта под разные платформы за несколько «кликов».
Именно здесь мы видим самые яркие перспективы развития.
Но не надо думать, что Embarcadero не планирует поддержать Linux. Это, кстати, является одной из реальных будущих задач перед Delphi и C++Builder. Однако нужно понимать, что средства разработки идут вслед платформе, а не обгоняют её, таков закон этого бизнеса. Как только доля настольных систем под управлением Linux опять наберет былые величины, мы с радостью ускорим темп развития в данном направлении. Технологически Delphi и кроссплатформенная библиотека FireMonkey к этому готовы. Задача комбинирования компилятора с платформенно-оринтированной реализации компонентов FireMonkey нами уже решена на примере Windows и Mac OS. Можно даже сказать, что мы всячески приветствуем развивающуюся многополярность мира операционных систем, т.к. это еще сильнее подчеркнет конкурентные преимущества Delphi нового поколения. Не следует также забывать C++Builder, как аналогичного по возможностям средства визуальной разработки, но с использованием C++11.
– В прошлом году я брал интервью у автора популярной программы Total Commander, который, несмотря на всю свою пламенную любовь к Delphi, очень сильно ругал компилятор 64-битового кода. Во-первых, он не верил, что вы его таки выпустите (как я понял, он всё-таки вышел), а во-вторых, с ним связано множество ограничений, например, нет возможности ассемблерных вставок.
– Delphi уже больше года поддерживает генерацию 64-битного кода, начиная с версии XE2. Ряд неизбежных для нового функционала ошибок уже исправлен, каких-то особых нареканий мы не наблюдаем. Другое дело, что для чистых прикладников, программирующих приложения для работы с базами данных, поддержка 64-битов, скорее проблема, нежели преимущество. Зачем иметь два варианта приложения, когда и 32-битная программа хорошо себя чувствует на 64-битной машине?
Здесь можно еще раз сказать «спасибо» корпорации Microsoft за гуманизм по отношению к разработчикам. Конечно, это не альтруизм чисто воды, а необходимость продвигать 64-битные версии ОС без провала в плане оснащения прикладным софтом рабочих станций пользователей. Мы реализовали поддержку 64-бит в Delphi, что повлекло за собой реальную переработку и RTL, и библиотеки VCL. Но сказать, что эта новая возможность по своей привлекательности соизмерима с кроссплатформенной FireMonkey или стилизацией приложений под Windows 8, нельзя. Конечно, многие разработчики выразили компании Embarcadero благодарность за «преданность делу Delphi», но абсолютное большинство начнет создавать 64-битные версии своих проектов только тогда, когда доля рабочих станций с такой архитектурой достигнет отметки в 90%, а это, согласитесь, будет нескоро.
Технические нюансы перехода на 64-битные приложения достаточно хорошо нами описаны вплоть до конкретных рекомендаций. Например, найти и заменить сомнительные преобразования типов, причем именно в местах вызова Windows API. Опять же, кто использовал константу 4 вместо sizeof, будут неприятно удивлены необходимостью пересмотреть свой исходный код. Также есть программисты, которые используют древние и бесплатные компоненты, 64-битные версии которых уже никогда не увидят свет. Они тоже не спешат переходить на новую разрядность. Но мы всячески поддерживаем наших технологических партнеров (например, компанию Fast Reports, производителя одноименного средства генерации отчетов), которые чётко отслеживают появление новых возможностей в Delphi и стараются не отставать, синхронизируя релизы и версии своих решений.
Вместе с поддержкой 64-битной кодогенерации появился и ряд ограничений, это касается, например, ассемблерных вставок. Возможность использования ассемблера осталась, но на уровне полностью изолированных функций. Но мы рекомендуем по возможности вообще отойти от этого стиля программирования, т.к. вследствие все более и более ускоряющегося роста многообразия настольных и мобильных устройств переносимость приложений требует отказаться от платформенно-зависимого кода.
– Расскажите про ваш грядущий переход на LLVM – как обстоят дела с этим, какие преимущества это дает?
– Переход на более прогрессивную архитектуру компилятора уже произошел, но в рамках продукта C++Builder. 64-битная поддержка в C++Builder основывается на связке CLANG-LLVM как альтернативе монолитному компилятору. Language engine (front-end) – code generator (back-end) в такой схеме наши задачи по реализации кроссплатформенности имеют наиболее технологичное решение. Этим путем мы и пошли, создавая 64-битный компилятор к C++Builder XE3. Можно сравнивать и проводить замысловатые тесты, какой компилятор – «классический» или «модульный» – более производительный, но для нас это означает, прежде всего, при необходимости поддержки новой аппаратной платформы достаточна быстрая разработка всего лишь «плагина» в рамках указанной архитектуры, а не создания нового варианта с нуля.
Для средств быстрой кроссплатформенной разработки бизнес-приложений (а уже и Delphi, и C++Builder можно называть чуть по-новому) это и будет магистральным направлением развития. По-другому сейчас нельзя, особенно из-за взрывоподобного распространения мобильных платформ. Количество настольных систем и мобильных устройств уже сопоставимо, но последний сегмент растет несоизмеримо быстрее. Вот именно тут Embarcadero имеет все шансы дать Delphi и C++Builder второе рождение. Пока Embarcadero исправила ошибки позднего Borland-а и заложила основу развития, правильно определив цели и сформулировав задачи. Платформа FireMonkey, компиляторы на новой архитектуре, разработка настольных и мобильных систем на основе единого исходного кода.
Мы не сторонники экстенсивного пути, мы не будем «фаршировать» средство разработки второстепенными по важности сервисами. Если какой-то «плагин» или «дополнение» в виде «профайлера» или «модуля журналирования» или «визуального компонента с рюшечками» действительно важен – пусть это будет основой для бизнеса и его процветания нашего технологического партнера. Нам важно создать устойчивую экосистему Delphi, а не гипертрофировать мышцы бездумной накачкой стероидами и пугать своим внешним видом окружающих. Мы не сторонники громоздкой среды, в которой нельзя толком ни разобраться, ни эффективно использовать.
– Как вы относитесь к Lazarus? В чем можете похвалить этого открытого конкурента, а в чем – покритиковать?
– Lazarus является полностью независимым от нас проектом, но его участники не ставят перед собой задачу «победить» Delphi. Между нами нет ни явного, ни тайного противостояния. Лично моё отношение к ним очень хорошее, а в свободное время я помогаю команде русской редакции Blaise Pascal Magazine под руководством Александра Алексеева (aka GunSmoker), где очень много статей про Lazarus. Да и как представитель Embarcadero я всячески способствую развитию русскоязычной версии этого журнала, а сам Алексей – участник всех мероприятий Embarcadero, кроме того имеет наш статус MVP (most valuable professional).
Сегодня у нас первая часть большого интервью с Всеволодом Леоновым, российским евангелистом из компании Embarcadero Technologies, который расскажет нам из первых уст про самые последние и горячие новости из мира Delphi.
В сегодняшней первой части мы поговорим про особенности новейшей Delphi XE3, рассмотрим её детали поддержки Windows 8, а также коснемся предстоящего перехода на LLVM. Кроме того, Всеволод выскажет свое отношение к проекту Lazarus, попутно передаст своё «горячее спасибо» корпорации Microsoft за “её гуманизм по отношению к разработчикам”. Во второй части, немного подняв градус полемики, мы продолжим обсуждать Microsoft и её ”гигабайтный фреймворк” на базе платформы .Net, при этом не теряя из вида всех особенностей продуктов от Embarcadero Technologies.
От себя выскажу предположение, что это интервью, вероятней всего, будет интересно не только бывшим и нынешним приверженцам продуктов Borland/Embarcadero, но и всем любителям MS Visual Studio, так как речь у нас пойдет, в том числе, о весьма противоречивых современных трендах развития в области инструментов для программной разработки.
Visual LiveBindings – для пользователей «классических» версий Delphi (1-7), а также релизов последнего поколения (2009-XE2), это будет новым шагом и в проектировании связей между объектами и компонентами в приложениях, и в построении более гибких и универсальных архитектур. Теперь мы используем техники визуального программирования не только к созданию прототипа пользовательского интерфейса, но и для проектирования внутренних связей на основе механизма выражений или «живого связывания». Теперь Delphi XE3 оснащена действительно новыми и интересными технологиями, которые без значительного усложнения процесса разработки по-настоящему дают еще более развитые возможности для создания новых решений, а также для модификации и развития уже существующих.
Возвращаясь к конкурентным преимуществам Delphi XE3. Кроссплатформенная библиотека FireMonkey сочетает в себе классические преимущества RAD-средств – быстрая и гибкая разработка, а также возможность быстро перекомпилировать проекты под разные платформы. Все это создается в «нативном» коде, не требующим промежуточных сред выполнения. Мы уже знаем, как сложно бывает обеспечить распространение приложений, которым нужен именно конкретный «фреймворк», версии которого также влияют на процесс разработки и эксплуатации. Ну, а кроме того, достаточно сложно представить себе ситуацию, когда Visual Studio станет поддерживать «нативную» разработку, к примеру, под Mac OS или iOS.
Наш девиз – один и тот же исходный код, а компиляция под различные платформы.
– Поскольку это сейчас очень актуально, сразу мой уточняющий вопрос по новомодной Windows 8: как у вас реализована поддержка новейших продуктов от MS? Я слышал, что работа с LiveTile у вас реализована через враппер, скомпилированный вами же на MS VC++, можете последовательно рассказать, что и как у вас в этой области устроено?
– Embarcadero является технологическим партнёром Microsoft, мы очень внимательно следим за их продуктами, всецело поддерживая их линию на обновление, по крайней мере, операционной системы и СУБД MS SQL Server. К средствам разработки мы относимся, честно говоря, нейтрально, т.к. чётко представляем себе, чем мы лучше. Windows 8 мы поддерживаем за счет стилизации как новых, так уже и существующих desktop-приложений, причем без разницы, с использованием какой библиотеки они сделаны – Windows-ориентированной VCL или кроссплатформенной FireMonkey. Вы берете уже сделанный на Delphi проект и практически мгновенно, применив к нему «стиль Windows 8», делаете его абсолютно интерфейсно-родным для новой ОС. Чисто технически компоненты остаются теми же, но внешний вид их эмулирует стиль Windows 8, который оптимизирован под сенсорные экраны планшетов. Более быстрый способ сложно себе представить.
Что касается интегрирования с механизмом «живых плиток» (LiveTile), то здесь есть различные подходы. На текущий момент мы это делаем так – вы берете обычный проект VCL или FireMonkey и одним компонентом TLiveTile добавляете возможность интеграции с новым «стартовым экраном Windows 8». Вы сможете взаимодействовать с приложением при помощи вашей «живой плитки» даже в режиме обновления его содержимого. Последнее, кстати, достаточно спорный момент. Пока я не видел ничего более внятного и полезного, чем прогноз погоды и ротация фотографий. Сама идея-то великолепна, но как она может помочь пользователям прикладного ПО? Пока ответа от самой корпорации Microsoft я не увидел, хотя специально посетил Windows 8 Summit в Москве.
Технологически мы решаем проблему использования LiveTile путем небольшой сервисной программы, которая, используя новый API, полностью контролирует LiveTile. Хорошо ли это? Достаточно ли это технологично? В любом случае, пока это является достаточно удачным и для нас, и для программистов на Delphi, использующих компонент TLiveTile в рамках обычного desktop-приложения. Установка небольшой сервисной программы на рабочую станцию с Windows 8 не является архисложной задачей, тем более, что обычно даже корпоративный софт распространяется в виде инсталляционного пакета вместе с драйверами СУБД и т.д., так что еще один маленький сервис в общем наборе ничего не усложнит.
Технически этот наш сервис – да, является полноценным WinRT-приложением и создан в Visual Studio. Но всем известный факт, что интерфейсная часть Skype на момент его приобретения Microsoft была создана на Delphi, а сразу после этого указанная выше корпорация опубликовала вакансию на должность Delphi-разработчика. Некоторые горячие головы со стороны фанатов Delphi отметились рядом шуток, но мы не видим ничего такого, когда используемые продукты оцениваются по их функциональным качествам и применяются без каких бы то ни было предрассудков.
Например, один из продуктов-конкурентов нашего кроссплатформенного средства администрирования баз данных – DBArtisan – разработан на Delphi. Такая ситуация встречается очень часто. А закончить очередную «священную войну» хочется следующим примером. Есть внутренний чемпионат по футболу, когда клубы соревнуются между собой. А есть чемпионат мира, когда игроки разных команд играют за одну сборную. На поле Windows 8 мы с Microsoft однозначно играем вместе, а не друг против друга. Например, мы технологически не позволяем применять стиль Windows 8 для приложений под Mac OS, хотя, как ни странно это звучит, есть масса таких запросов со стороны прикладных разработчиков.
– Какие вообще платформы и операционные среды поддерживает Delphi XE3 на данный момент? Насколько я знаю, это достаточно всеядная и универсальная среда – очертите её границы применения. Кстати, какова судьба Kylix и поддержки Linux?
– «Всеядность» и универсальность, которую мы называем «кроссплатформенностью», достигается за счет абстрагирования уровня визуализации и объектной модели визуального компонента. Представьте себе «кнопку», которая будет нарисована тем API, для которой данный проект скомпилирован. Также нужно добавить тот факт, что мы еще применяем «платформенно-ориентированный» стиль. Ваше приложение не просто скомпилируется под Windows, а затем под Mac OS. Для Mac OS оно будет еще и выглядеть, как стандартное приложение под данной операционной системой. И меню, и кнопки, и прочие компоненты визуального интерфейса будут «родными» с точностью до пикселя. Но если вы хотите единый стиль вашей системы для любой операционной системы, то можно применить именно ваш оригинальный стиль, явно подчёркивающий бренд вашей компании – не только по функциональному набору приложения, но и даже по внешнему виду.
Судьба Kylix во много характерна для ИТ-продуктов. Далеко не все даже очень сильные бренды выдержали проверку временем в рамках сверхбыстрого развития аппаратных и программных средств, передела рынков и даже просто изменяющихся трендов из области ИТ-моды. Некоторые из них были действительно «тупиковыми» ветвями эволюции (да-да, многие вспомнили некоторые версии одной из самых популярных и по сей день операционной системы). Некоторые послужили фундаментом для развития понимания и стартовой площадкой для последующего роста. Kylix пал жертвой двух обстоятельств. Первое – многообещающий рост популярности Linux в качестве операционной системы для настольных компьютеров (в тот момент я работал системным администратором – каждый второй мой коллега дома обязательно имел Linux, иногда и в качестве основной ОС, а те, кто не знал Linux, становились изгоями). Но потом к середине 2000-х был резкий спад. Желающих создавать прикладного ПО резко поубавилось, хотя продукт был хороший и до сих пор люди его успешно используют. Вторым, но уже не обстоятельством, но промахом компании Borland стало разделение двух продуктов Delphi и Kylix. Началось создание «кроссплатформенного» клона VCL – библиотеки CLX. Программисты в основной массе предпочитали работать в Windows, а Kylix использовали только для сборки проекта под другую платформу. Но это был хороший опыт, на его основе Embarcadero выстроила более успешную, на наш взгляд, концепцию для развития Delphi. Едина среда разработки, кроссплаторменная реализация компонентной платформы FireMonkey, сборка проекта под разные платформы за несколько «кликов».
Именно здесь мы видим самые яркие перспективы развития.
Но не надо думать, что Embarcadero не планирует поддержать Linux. Это, кстати, является одной из реальных будущих задач перед Delphi и C++Builder. Однако нужно понимать, что средства разработки идут вслед платформе, а не обгоняют её, таков закон этого бизнеса. Как только доля настольных систем под управлением Linux опять наберет былые величины, мы с радостью ускорим темп развития в данном направлении. Технологически Delphi и кроссплатформенная библиотека FireMonkey к этому готовы. Задача комбинирования компилятора с платформенно-оринтированной реализации компонентов FireMonkey нами уже решена на примере Windows и Mac OS. Можно даже сказать, что мы всячески приветствуем развивающуюся многополярность мира операционных систем, т.к. это еще сильнее подчеркнет конкурентные преимущества Delphi нового поколения. Не следует также забывать C++Builder, как аналогичного по возможностям средства визуальной разработки, но с использованием C++11.
– В прошлом году я брал интервью у автора популярной программы Total Commander, который, несмотря на всю свою пламенную любовь к Delphi, очень сильно ругал компилятор 64-битового кода. Во-первых, он не верил, что вы его таки выпустите (как я понял, он всё-таки вышел), а во-вторых, с ним связано множество ограничений, например, нет возможности ассемблерных вставок.
– Delphi уже больше года поддерживает генерацию 64-битного кода, начиная с версии XE2. Ряд неизбежных для нового функционала ошибок уже исправлен, каких-то особых нареканий мы не наблюдаем. Другое дело, что для чистых прикладников, программирующих приложения для работы с базами данных, поддержка 64-битов, скорее проблема, нежели преимущество. Зачем иметь два варианта приложения, когда и 32-битная программа хорошо себя чувствует на 64-битной машине?
Здесь можно еще раз сказать «спасибо» корпорации Microsoft за гуманизм по отношению к разработчикам. Конечно, это не альтруизм чисто воды, а необходимость продвигать 64-битные версии ОС без провала в плане оснащения прикладным софтом рабочих станций пользователей. Мы реализовали поддержку 64-бит в Delphi, что повлекло за собой реальную переработку и RTL, и библиотеки VCL. Но сказать, что эта новая возможность по своей привлекательности соизмерима с кроссплатформенной FireMonkey или стилизацией приложений под Windows 8, нельзя. Конечно, многие разработчики выразили компании Embarcadero благодарность за «преданность делу Delphi», но абсолютное большинство начнет создавать 64-битные версии своих проектов только тогда, когда доля рабочих станций с такой архитектурой достигнет отметки в 90%, а это, согласитесь, будет нескоро.
Технические нюансы перехода на 64-битные приложения достаточно хорошо нами описаны вплоть до конкретных рекомендаций. Например, найти и заменить сомнительные преобразования типов, причем именно в местах вызова Windows API. Опять же, кто использовал константу 4 вместо sizeof, будут неприятно удивлены необходимостью пересмотреть свой исходный код. Также есть программисты, которые используют древние и бесплатные компоненты, 64-битные версии которых уже никогда не увидят свет. Они тоже не спешат переходить на новую разрядность. Но мы всячески поддерживаем наших технологических партнеров (например, компанию Fast Reports, производителя одноименного средства генерации отчетов), которые чётко отслеживают появление новых возможностей в Delphi и стараются не отставать, синхронизируя релизы и версии своих решений.
Вместе с поддержкой 64-битной кодогенерации появился и ряд ограничений, это касается, например, ассемблерных вставок. Возможность использования ассемблера осталась, но на уровне полностью изолированных функций. Но мы рекомендуем по возможности вообще отойти от этого стиля программирования, т.к. вследствие все более и более ускоряющегося роста многообразия настольных и мобильных устройств переносимость приложений требует отказаться от платформенно-зависимого кода.
– Расскажите про ваш грядущий переход на LLVM – как обстоят дела с этим, какие преимущества это дает?
– Переход на более прогрессивную архитектуру компилятора уже произошел, но в рамках продукта C++Builder. 64-битная поддержка в C++Builder основывается на связке CLANG-LLVM как альтернативе монолитному компилятору. Language engine (front-end) – code generator (back-end) в такой схеме наши задачи по реализации кроссплатформенности имеют наиболее технологичное решение. Этим путем мы и пошли, создавая 64-битный компилятор к C++Builder XE3. Можно сравнивать и проводить замысловатые тесты, какой компилятор – «классический» или «модульный» – более производительный, но для нас это означает, прежде всего, при необходимости поддержки новой аппаратной платформы достаточна быстрая разработка всего лишь «плагина» в рамках указанной архитектуры, а не создания нового варианта с нуля.
Для средств быстрой кроссплатформенной разработки бизнес-приложений (а уже и Delphi, и C++Builder можно называть чуть по-новому) это и будет магистральным направлением развития. По-другому сейчас нельзя, особенно из-за взрывоподобного распространения мобильных платформ. Количество настольных систем и мобильных устройств уже сопоставимо, но последний сегмент растет несоизмеримо быстрее. Вот именно тут Embarcadero имеет все шансы дать Delphi и C++Builder второе рождение. Пока Embarcadero исправила ошибки позднего Borland-а и заложила основу развития, правильно определив цели и сформулировав задачи. Платформа FireMonkey, компиляторы на новой архитектуре, разработка настольных и мобильных систем на основе единого исходного кода.
Мы не сторонники экстенсивного пути, мы не будем «фаршировать» средство разработки второстепенными по важности сервисами. Если какой-то «плагин» или «дополнение» в виде «профайлера» или «модуля журналирования» или «визуального компонента с рюшечками» действительно важен – пусть это будет основой для бизнеса и его процветания нашего технологического партнера. Нам важно создать устойчивую экосистему Delphi, а не гипертрофировать мышцы бездумной накачкой стероидами и пугать своим внешним видом окружающих. Мы не сторонники громоздкой среды, в которой нельзя толком ни разобраться, ни эффективно использовать.
– Как вы относитесь к Lazarus? В чем можете похвалить этого открытого конкурента, а в чем – покритиковать?
– Lazarus является полностью независимым от нас проектом, но его участники не ставят перед собой задачу «победить» Delphi. Между нами нет ни явного, ни тайного противостояния. Лично моё отношение к ним очень хорошее, а в свободное время я помогаю команде русской редакции Blaise Pascal Magazine под руководством Александра Алексеева (aka GunSmoker), где очень много статей про Lazarus. Да и как представитель Embarcadero я всячески способствую развитию русскоязычной версии этого журнала, а сам Алексей – участник всех мероприятий Embarcadero, кроме того имеет наш статус MVP (most valuable professional).
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.