Журнал «Компьютерра» № 10 от 14 марта 2006 года - Компьютерра

Позволю себе внести предварительное замечание эстетического характера: в свете языковых инструментариев могут возродиться многие давно забытые дискуссии о самих языках программирования, придававшие нашему ремеслу (искусству?) особое, ни с чем не сравнимое обаяние и притягательную силу. Обаяние, которое автор статьи так настойчиво хотел похоронить, публично обличая страстных приверженцев C++, верных любимому языку по сей день[ «Язык мой...», «КТ» #555-556]. Каюсь, грешен: поддался влиянию поголовного обсишарпивания разработчиков. Прошли годы, и хотя в отношении самого C++ автор своих взглядов не изменил, за настойчивость в желании прервать диалог о языках программирования все же досадно.

Итак, переходим к сути. Вообще говоря, при написании программ существуют две стратегии:

записать, что нам нужно сделать (декларативные языки);

записать, как мы собираемся это делать (императивные языки).

Для декларативных языков характерны емкие и компактные конструкции. Достаточно сказать, что исходный текст довольно сложной программы на ПРОЛОГе — ярком представителе всего семейства — вполне может уместиться «на одном экране».

Тем не менее практически весь мэйнстрим современной разработки составляют императивные языки (все те же С++, Java, C#, ...), а чуть ли не единственной серьезной промышленной нишей для декларативных языков являются технологии баз данных, где прочно обосновался SQL вкупе с множеством диалектов. И это не просто «исторически так сложилось». Несмотря на изящество, компактность и концептуальную простоту декларативных языков их применение оправданно только при условии, что предметная область задачи четко определена. Именно этим обстоятельством и объясняется успех SQL, ведь абстракции, на которых построена работа с реляционными данными, давно изучены и хорошо известны.

При проектировании DSL актуален следующий вопрос: нужно ли вносить в него императивные конструкции (условные операторы и циклы)? Не потеряем ли мы в результате то, к чему, собственно, и стремимся: получение простого языка, на котором записана лишь самая суть проекта, без утомительных деталей реализации?

Руководствуясь здравым смыслом, можно сказать, что императивные конструкции целесообразно использовать лишь тогда, когда это продиктовано спецификой предметной области задачи. Например, если в постановке задачи часто употребляется слово «коллекция элементов» и говорится о задачах добавления/удаления/поиска элементов, введение в DSL понятия «цикл для работы с коллекциями» способно существенно упростить решение. Тем не менее предпочтение все же стоит отдавать декларативным конструкциям: их проще моделировать (сокращаются затраты на проектирование DSL), к тому же зачастую они легче воспринимаются и несут больше информации о проекте.

Для создания DSL «Структура статьи в КТ» автору потребовалось около часа. Разумеется, это не есть адекватный показатель, поскольку мы разработали простой и вдобавок совершенно бесполезный язык, но трудозатраты в один человеко-час все-таки впечатляют. И тем не менее многие почему-то не верят, что разработка в окружении языковых инструментариев будет быстрой, а процесс создания и сопровождения DSL — простым. Мне кажется, здесь вполне уместна аналогия с рефакторингом: кто бы мог подумать лет десять назад, что переименование метода (со всеми вызовами!) можно выполнять почти моментально, практически безоговорочно доверив все действия среде разработки? А сейчас мы постоянно выполняем различные операции рефакторинга, с улыбкой вспоминая времена, когда подобные вещи еще не имели такого сочного названия и выполнялись вручную.

Обо всем этом можно сказать проще (и притом максимально пристрастно): профессиональное чутье подсказывает автору, что с приходом языковых инструментариев в повседневную практику разработки удастся достичь технологического прорыва, сопоставимого с тем, какой в свое время пережил веб при переходе от CGI-скриптов к динамическим серверным страницам[Теоретически между CGI и, допустим, PHP разницы нет: обе технологии позволяют динамически генерировать HTML. Вопрос только в том, какой ценой. В случае CGI для этого нужно поместить весь генерируемый HTML внутрь операторов вывода какого-нибудь языка программирования (допустим, C++). Главная беда такого подхода даже не в том, что код становится очень тяжело модифицировать. Где вы найдете хорошего веб-дизайнера, улавливающего тонкости оператора printf (или программиста, хорошо разбирающегося в веб-дизайне)? С появлением технологии динамических серверных страниц, построенной на ранее обсуждавшихся принципах метапрограммирования, стала возможной эффективная совместная работа людей со столь разными типами мышления]. С той лишь разницей, что языковые инструментарии охватывают все направления прикладной разработки и позволяют эффективно организовать управление проектом в целом.

Одна беда — прекрасное пока еще далёко, а потребность в нем ощущается уже сейчас.

Появившись в далеком 1997 году, XML (eXtensible Markup Language, расширяемый язык разметки) произвел самую настоящую революцию, практически сразу же покорив сердца разработчиков и архитекторов, поскольку совместил в себе, казалось бы, две несовместимые вещи: доступность для восприятия человеком и возможность автоматического распознавания различными программами. Немного позже XML был дополнен технологией XSLT, наделяющей его возможностями метапрограммирования. Вот как выглядит документ XML для разработанного нами языка «Структура статьи в КТ»:

<?xml version="1.0" encoding="UTF-8" ?>

<статья

название=”Ориентация на язык”

автор=”Дмитрий Кириллов”>

<раздел название=”Введение”/>

<раздел название=”Языковые инструментарии”>

<раздел название=”Проектирование DSL”/>

<раздел название=”Создание редактора”/>

</раздел>

</статья>

Забавно, что практически сразу же после появления XML отовсюду посыпались различные идеи «разработки, основанной на метаданных» (metadata-driven development), созвучные концепции языковых инструментариев. Но... громоздкость конструкций (обратная сторона самоописательности XML), а также, мягко говоря, их ограниченная выразительность зачастую сводят на нет любые попытки построить практичный DSL на основе XML. Чтобы это понять, достаточно представить себе мир, в котором для формирования запроса к базе данных вместо простого и компактного оператора SELECT языка SQL каждый раз пишут монстров, пестрящих угловыми скобками.

Что же касается возможностей построения метапрограмм-генераторов, то, как показывает опыт развития средств разработки веб-приложений, связка XML/XSLT проиграла сражение на этом поле технологиям динамических серверных страниц (PHP, JSP, ASP.NET и т. п.). Причин много, но главных, пожалуй, две:

— сложность организации взаимодействия серверных компонентов при разработке средствами XML/XSLT;

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

ФМ-ВЕЩАНИЕ: Web 2.c и Web 2.b

Автор: Феликс Мучник

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

Интересно, что и Антон Антич в своей статье «Бизнес-модель для веб-стартапа: а есть ли она?», опубликованной в его блоге в феврале, тоже рассматривал модели, ориентированные только на конечного пользователя. Назовем их условно Web 2.c. Естественно, при таком подходе возникают только две модели: заработок на рекламе и платные сервисы (или некая их смесь). Это меня несколько удивило, учитывая опыт работы Антича в корпорации Microsoft, одном из самых активных продвигателей ASP-модели (приложения — как платные сервисы для компаний).

Разделение бизнес-моделей на категории в статье профессора Майкла Раппы (Michael Rappa) более подробное, учитывающее как модели «бизнес для пользователя» (B2C), так и модели «бизнес для бизнеса» (B2B) . Например, в статье уже внесено в табличку виртуальное место для торговли (marketplace), типичным примером которого является amazon.com. Он не только торгует товарами с собственного склада, но и давно оказывает услуги другим компаниям по ведению их каталогов, ордер-процессингу и логистике служб доставки. Тот же amazon предоставляет сервис по ведению корпоративных аккаунтов компаний-покупателей (товары заказывают сотрудники, а расплачивается компания). О www.windowsmarketplace.com, на котором предоставлены программы и железо для Windows от различных продавцов, тоже давно известно. В Рунете по пути marketplace идет проект www.marex.ru от eHouse.

В Интернете предыдущей версии сервисы для бизнеса (хостинг, почта, сайты, сервисы по приему денег) предоставляли Yahoo (ныне добавившая сервис по ведению блогов) и MSN (в новой версии бета-сервис Office Live), многочисленные порталы, позволяющие сравнить цены от разных продавцов (типичные примеры в Рунете — это Price.ru, Яндекс-Маркет, Рамблер-Покупки), сервис по использованию распределенной CRM-системы и многие тому подобные. Но все они односторонние, сервер-компания. Они не дают возможности передавать информацию, деньги, товары, услуги между компаниями. Без излишней скромности, можно сказать, что некоторым приближением к концепции Web 2.b является наша система. Она позволяет общаться описанным выше способом поставщикам программ (в том числе и друг с другом через совместные пакеты программ), дилерам, компаниям-покупателям, компаниям, поддерживающим аффилированные с нами витрины. В результате четверть наших компаний-покупателей приносят нам три четверти оборота. Но чего-то в супе еще не хватает для того, чтобы мы окончательно себя ощутили частью новой версии Интернета. Чего именно не хватает всем нам, надеюсь выяснить вместе с вами, уважаемые читатели.