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

В качестве примера приведем фрагмент грамматики ANTLR для языка арифметических выражений, содержащих числа, а также операции ‘+’ и ‘*’. Хотя подобная запись и выглядит страшновато, при наличии определенных навыков она воспринимается достаточно легко.

expr : mexpr (‘+’ mexpr)* ‘;’!;

mexpr : number (‘*’ number)*;

number : (‘0’..’9’)+;

Несмотря на ряд трудностей, связанных с повсеместным применением ГСА, на сегодняшний день они являются распространенным средством автоматизации разбора исходных текстов*. Например, распознаватель SQL для широко известной открытой СУБД PostgreSQL разработан при помощи пары lex и yacc. Интересно отметить, что эта «сладкая парочка» оказала существенное влияние на открытый софт, породив целое направление так называемых «малых языков» (по сути своей являющихся DSL), с которыми пользователи *nix-систем часто имеют дело при редактировании конфигурационных файлов.

* Тот, кто боролся с неоднозначностями и устранением левой рекурсии путем введения фиктивных правил в грамматику, хорошо понимает, трудности какого рода приходится преодолевать.

Привязка DSL к языку реализации

DSL сам по себе, пусть даже и с хорошим редактором, не представляет интереса до тех пор, пока мы не привяжем его понятия к языку реализации — как правило, некоторому универсальному языку программирования, например Java или С#. Для решения этой задачи в языковых инструментариях применяются технологии метапрограммирования (см. врезку «Что такое метапрограмма?»).

Вид метапрограммы существенно зависит как от структуры DSL, так и от языка реализации проекта. Например, в случае DSL «Структура статьи в КТ» можно сгенерировать документ HTML или макрос для Word, который в процессе выполнения сформирует шаблон будущей статьи с необходимой разметкой документа. При этом метапрограмма, генерирующая HTML, будет сильно отличаться от метапрограммы-генератора документа Word.

Вообще говоря, метапрограммирование — интересная и мощная, но довольно сложная технология. Именно поэтому в окончательном варианте статьи опущен пример, связанный с написанием метапрограммы для нашего DSL «Структура статьи в КТ». Отметим лишь, что процесс написания метапрограмм можно радикально облегчить, если мы хорошо представляем себе конечный результат — исходный код на языке реализации. Поэтому при ведении проекта на DSL целесообразно использовать прототипирование, то есть вначале создать «скелет» разрабатываемого приложения, а уж затем проектировать DSL и метапрограммы-генераторы для него.

Процесс разработки

Обобщая, можно выделить следующие этапы разработки приложений с участием языковых инструментариев:

1. Cоздание прототипа, содержащего частичную реализацию минимально необходимого набора бизнес-функций («скелет» будущего приложения).

2. Определение существенных абстракций проекта, разработка DSL.

3. Создание метапрограмм-генераторов для понятий DSL.

4. Перевод разработанного прототипа приложения в окружение языкового инструментария.

5. Реализация бизнес-функций проекта в терминах DSL.

6. Автоматическая генерация исходных текстов на языке реализации проекта.

Этапы 2—6 схематически изображены на диаграмме (рис. 5), там же показана взаимосвязь между языковыми инструментариями и классическими средами разработки.

Возможно, многим покажется, что вышеописанный подход к разработке — не более чем преодоление трудностей, которые мы сами же себе и создали, приняв решение вести проект системы на DSL, однако список полученных при этом преимуществ весьма внушителен:

полностью подавляется расхождение проекта и исходного кода. Высокоуровневые абстракции проекта, записанные на DSL, связаны с кодом реализации проекта. При этом проект всегда остается актуальным, ведь изменения исходного кода теперь вторичны по отношению к изменениям в самом DSL;

облегчаются доработки проекта под изменившиеся требования заказчика. Этому способствует сама философия метапрограммирования: DSL как бы параметризует проект. При небольших изменениях проекта разработчику нужно лишь слегка модифицировать конкретную конфигурацию, описанную на DSL. Серьезные изменения, затрагивающие предметную область, тоже становятся проще, поскольку в таких случаях алгоритм действий четко определен: вначале модифицируем сам DSL и редакторы для него, а затем — генераторы исходного кода на языке реализации;

упрощается управление проектом. Например, при вхождении в проект новых участников для получения общего представления о проекте (в его актуальном состоянии!) достаточно показать им лишь ту часть исходного кода, которая записана на DSL. Более того, взаимодействие между участниками проекта становится эффективнее. Допустим, аналитик проекта, хорошо представляющий себе бизнес-логику приложения, теперь сможет самостоятельно описывать на DSL ее отдельные части[В принципе, достаточно лишь понимания аналитиком кода на DSL. При этом он (как правило, все же, она) сможет на словах рассказать разработчикам, что нужно сделать, а затем, просмотрев код на DSL, проконтролировать их работу]. При этом проект избавляется от лишних документов, а разработчики — от их прочтения (на что тоже нужно время) и двусмысленного толкования;

становится возможным повторное использование DSL в схожих проектах. Все разработанные DSL, подобно общим библиотекам компонентов, становятся серьезным активом компании-разработчика, поскольку являются квинтэссенцией опыта компании и допускают повторное использование в будущих проектах.

На мой взгляд, в настоящий момент у языковых инструментариев существует только один серьезный недостаток: риск попадания в зависимость от поставщика программного обеспечения. Дело в том, что сейчас DSL жестко привязан к языковому инструментарию, при помощи которого он был разработан. И если в мире Microsoft этот вопрос отпадает автоматически (ввиду тотального характера зависимости), то для будущих пользователей MPS он вполне актуален, даже несмотря на то, что все файлы проекта MPS хранятся в открытом формате XML. Разумеется, это не является непреодолимым препятствием на пути к использованию языковых инструментариев, тем более что стандартизация в этой области станет возможной лишь с появлением на рынке конкурирующих и несовместимых друг с другом продуктов. Просто к списку технологических рисков проекта добавляется еще один пунктик.

Декларация или империя?

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

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

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

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

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

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

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

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

Прекрасное далёко

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

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

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

XML и XSLT

Появившись в далеком 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 является наша система. Она позволяет общаться описанным выше способом поставщикам программ (в том числе и друг с другом через совместные пакеты программ), дилерам, компаниям-покупателям, компаниям, поддерживающим аффилированные с нами витрины. В результате четверть наших компаний-покупателей приносят нам три четверти оборота. Но чего-то в супе еще не хватает для того, чтобы мы окончательно себя ощутили частью новой версии Интернета. Чего именно не хватает всем нам, надеюсь выяснить вместе с вами, уважаемые читатели.

Вот, к примеру, одна из идей. Дарю безвозмездно, то есть даром. Есть множество курьерских служб, оказывающих услуги по доставке грузов в разные регионы, за разное время и за разные деньги. Дайте им возможность занести перечень своих тарифов в некий портал. Дайте возможность компании, которой нужно отправить пачку грузов, сформировать и разместить заказ (учитывая, что разные позиции могут отправляться разными компаниями). Дайте возможность курьерским службам в реальном времени получать эти заказы, а компаниям — отслеживать выполнение заказов. Заведите службу отзывов и хелп-деск, белые/черные списки курьеров. Далее, думаю, идею развивать не надо. Уже понятно, за что в данном случае порталу брать деньги. Конечно, за транзакции. Ведь в сегодняшней ситуации все компании (несмотря на то что компании покрупнее заводят и свои курьерские службы) вынуждены отрабатывать логистические (и не только) проблемы взаимодействия с несколькими службами доставки. По крайней мере, в электронной коммерции именно так и происходит. Думаю, в остальных отраслях совершенно такая же ситуация.

Опишите аналогичную идею в виде бизнес-плана и смело идите к ангелам, венчурам, инвесторам. Наверняка она привлечет больше внимания, чем идея очередного сервиса для блоггеров. Дедушка одного из моих друзей, когда внуки обращались к нему с просьбой о деньгах, всегда говорил: «Дети, я вас не понимаю. Зачем вы просите деньги у меня, когда надо выйти на улицу и опустить глаза. Деньги валяются на каждом шагу, только их никто не берет». Подводя итог, для получения работающих Web 2.b и Web 2.c надо «выйти и посмотреть» и продолжить трансформацию денежно-товарных отношений в денежно-информационно-товарные отношения.

ПИСЬМОНОСЕЦ: Некоторые слова в фильтре файрвола

Автор: Илья Щуров

Здравствуй, «Компьютерра».

Ты уникальный журнал. Статьи интересные, полезные, нужные в хозяйстве. Хочу внести предложение по организации архива бумажных номеров. Часто в журнале печатают практические статьи, про которые вспоминаешь в определенные моменты жизни: при поломке компьютера, покупке сканера или другой железки, закачке программы и др. Так вот нужно сделать многоуровневый каталог, облегчающий поиск статей. Например:

Железо

Сканер

Выбор

Эксплуатация

Принтер

Софт

Для фотографий

Для здоровья ПК

И так далее. Каталог будет постепенно пополняться статьями и подразделами. Так существенно облегчится поиск нужной информации.

Пока писал письмо, подумал: а почему бы не сделать базу знаний на основе статей «Компьютерры»— задаешь вопрос и получаешь ответ от коллектива авторов журнала в виде статей?

Андрей Вахтанов

ОТ РЕДАКЦИИ: Андрей, ваша идея уже давно реализована: мы тем и занимаемся, что задаем вопросы авторам и получаем от них ответы в виде статей. А потом эти статьи попадают на страницы журнала. Так вот и делается «Компьютерра».

Дорогая «Компьютерра»!

Простите за откровенность, но обложка номера #628 совершенно дурацкая, да и тема какая-то чудная. Конечно, литература (а также и компьютерный еженедельник) — это не семнадцатилетняя барышня, но я ужасно не люблю сворачивать любимый журнал в трубочку или еще как-нибудь его перегибать, чтобы не позориться перед домашними.

Тем не менее моя история связана с темой номера. Не так давно муж по моей просьбе прописал в фильтре файрвола некоторые слова, в частности ххх. И вот я в очередной раз собираюсь отправить эсэмэску с сайта одного известного сотового оператора (из соображений экономии), а страница с бесплатной отправкой не грузится! Все остальное грузится, а страница с эсэмэсками — нет. Я была чрезвычайно озадачена, пока наконец не сообразила, что страницу не пропускает файрвол из-за такого пассажа: «Мобильный номер должен быть семизначным с префиксом 7095 и т.д. Например, 7095xxxxxxx». Мне было очень смешно.

С уважением, ваша постоянная (с замужества) читательница tapoint

ОТ РЕДАКЦИИ: Пожалуй, нам надо бы сделать статью про настройку файрволов. А вам— заехать к нам за призом.

С тех пор как я увлекся трехмеркой, понял, что фотография сугубо вторична и всякий настоящий фотограф заворачивает свою страсть к подглядыванию в форму искусства. Какое, в баню, искусство, если фотограф НИЧЕГО не создает! Он только, в меру отпущенного таланта, подсматривает в видоискатель и фиксирует то, что создано до него. Это понятно, что грамотно поставить модель в нужную позу— тоже некоторая фантазия нужна, да и ракурс подобрать и оптику уметь надо… Но, как я не совсем скромно думаю, сие не совсем искусство. Мне кажется, что фотографы, называя себя творцами, немного лукавят и набивают себе цену.

С появлением компьютеров и программ трехмерного моделирования, как мне кажется, случился прорыв в творчестве. Теперь каждый, у кого есть доступ к приличному компьютеру, может ТВОРИТЬ и визуализировать свои мысли напрямую, не обращаясь к посредничеству моделей, студий и прочих прихлебателей, которые так и норовят нажиться на этом процессе. Вы никогда не сможете сфотографировать свои мысли, а визуализировать— вполне. Вы никогда не сможете сфотографировать Увиденное в книжке Крапивина, а смоделить и отрендерить — запросто. Фотография — по природе своей — аналоговая, но как снять то, чему нет аналога? То, что уникально по сути своей? Мне кажется, что это невозможно. Можно только найти подобное и снять на пленку или матрицу. Но в том-то и дело, что это будет именно ПОДОБНОЕ, а не ТО! Это будут не Безлюдные Пространства, а всего-то навсего убитые заводы и фабрики, с которых ушли рабочие…

Я отдаю себе отчет в том, что так называемые «настоящие фотографы» попытаются выступить в защиту, но вероятность того, что они смогут корректно опровергнуть мои тезисы, невелика. Фотографы еще заняты тем, что пытаются доказать наличие некой душевности пленки и бездушности (хорошо хоть не бездуховности) цифры. Также я понимаю, что настоящее творчество уже на грани гордыни, которая, как мне известно, есть первый смертный грех… Потому как всякий человек, вытворяющий нечто из мыслей, уподобляется Творцу, а это уже не безопасно. Может преизрядно аукнуться. Потом. Когда-нибудь. Но аукнется обязательно. <…>

C уважением,

Лев Шелдунов

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

Редакторы, будьте осторожнее с порнотехнологиями! Вы всего лишь поместили девушку на обложку, а линки уже ведут не туда, куда надо. Страница не 42-я, а 60-я. Не иначе, постарался злой дух этих самых порнотехнологий.

ОТ РЕДАКЦИИ: Ваша правда, Петр! Будем делать обложки с большой осторожностью. А то, неровен час, разозлим духов, и на страницах журнала начнут появляться всплывающие и мигающие баннеры в пол-экрана и прочие атрибуты соответствующих сайтов. А нам бы этого не хотелось.

Антивирусом Dr.Web награждается tapoint — за чувство юмора. Приз предоставлен компанией Dr.Web