Языково-ориентированное программирование

Языково-ориентированное программирование (ЯОП) (English: Language Oriented Programming), также Расходящаяся разработка (English: middle out development), также , также Разработка, опирающаяся на предметно-специфичный язык (English: DSL-Based Development)[1] — парадигма программирования, заключающаяся в разбиении процесса разработки программного обеспечения на стадии разработки предметно-ориентированных языков (DSL) и описания собственно решения задачи с их использованием. Стадии могут вестись последовательно или параллельно, однократно или рекурсивно[2][1]; DSL могут быть реализованы зависимо или независимо от базового языка и иметь одну или множество реализаций.

 Место и роль в информатике

ЯОП предназначено для разделения сложностей: машино-ориентированная часть кода (низкоуровневая функциональность) и человеко-ориентированная (собственно решение прикладной задачи) разрабатываются независимо друг от друга, что исключает экспоненциальный рост результирующей сложности разработки всего проекта и решает проблему сложности как фундаментальную проблему программирования[2], описанную Фредериком Бруксом в знаменитом эссе «Серебряной пули нет», из-за которой оказывается невозможно простым совершенствованием рабочего инструментария повысить производительность труда программистов даже на порядок. Из этого же прямо следует большинство остальных преимуществ.
О достоинствах сужения специализации языков говорили ещё в середине 1980-х[3], а о достоинствах повышения уровня языков — намного раньше[4], но DSL-ориентированная разработка сформировалась как самостоятельная методология лишь к середине 1990-х.
Использование DSL вместо языков общего назначения существенно повышает уровень абстрактности кода, что позволяет вести разработку быстро и эффективно и создавать программы, которые легки в понимании и сопровождении; а также делает возможным или существенно упрощает решение многих задач, связанных с манипулированием программами (порождение программ, исследование определённого свойства программ — корректности, эффективности и др.)[3][1][5][6]. С другой стороны, разработка нового языка и эффективная его реализация является нетривиальной проблемой теоретической и прикладной информатики.
Среди прочих подходов к проектированию программ ЯОП выделяется гораздо более агрессивной направленностью на приближение компьютера к человеку. Среди исследователей ЯОП бытует мнение, что в наукоёмких задачах хорошо спроектированный и реализованный DSL делает общение человека с компьютером куда более удобным и продуктивным, чем графический интерфейс пользователя. В качестве примеров чаще всего приводятся следующие популярные предметно-специфичные языки:
AutoLisp для компьютерного моделирования (САПР)
 для подготовки (компьютерной вёрстки) текстовых документов
Perl для манипулирования текстами
SQL для СУБД
Mathematica и Maple для символьных вычислений
и др.

Преимущества ЯОП проявляются даже в тех случаях, когда DSL разрабатывается не для массового использования, а для решения единственной задачи. Например, при разработке системы автоматического эквивалентного преобразования программ  переход от «плоского» программирования на Лиспе к рекурсивному ЯОП (на Лиспе был реализован язык WSL, на нём — язык MetaWSL, а уже на нём — целевая функциональность) не только позволил сократить общий объём кода со 100 до 16 тысяч строк, но одновременно повысил все основные качественные характеристики кода и даже сделал возможным решение задач, которые иначе решить не удавалось[2].
Упрощённо сравнить рост трудозатрат при использовании традиционного и языково-ориентированного подходов позволяет график[1]. Как видно, ЯОП оказывается целесообразно лишь начиная с некоторого порога объёма и сложности функциональности целевой системы.
Большинство исследователей ЯОП опирается на функциональные языки и метаязыки, что обусловливает высокий порог вхождения для разработчиков. Мартин Уорд отмечает возможность реализации DSL на традиционных языках, но лишь после его окончательной разработки.
В мейнстриме часто применяется встраивания интерпретатора в язык общего назначения (см. Подход), хотя это делается не только без апелляции к принципам ЯОП, но и зачастую без осознания факта её применения как таковой. Наиболее часто встраиваются: язык регулярных выражений (интерпретатор PCRE), Lua, SQL, XML. Также был разработан инструментарий визуального программирования для использования в мейнстриме некоторых идей ЯОП.
Многие исследователи видят цель ЯОП в том, чтобы полностью размыть границы между математической моделью и её реализацией на ЭВМ и сделать возможной разработку программного обеспечения специалистами предметных областей, не имеющими специфичных знаний в программировании[1][6]:
Template:Конец цитаты
 Подход
В основе подхода лежит идея о том, что язык, специально разработанный под поставленную задачу, будет обеспечивать заведомо более высокие показатели качества кода, чем любой язык общего назначения[1][6], и что для решения сложных промышленных задач более эффективным будет изобрести более простой в понимании (человеко-ориентированный[8] или точно инкапсулирующий предметные знания[2][1]) язык, нежели преодолевать трудности использования имеющегося, даже укоренившегося в промышленности[4].
Большинство исследователей говорят о ЯОП как о переводе всей индустрии разработки ПО на использование текстовых языков 4-го и 5-го поколения[8], но некоторые ориентируются на использование визуальных языков[9][10].
Основные проблемы подхода состоят в нахождении способов быстро создать реализацию придуманного DSL, чтобы начать разрабатывать собственно решение задачи, и в обеспечении хорошей вычислительной производительности DSL.
Предметно-ориентированный язык, как и вообще любой язык программирования, определяется алфавитом, грамматикой, семантикой и психолингвистикой, однако, в зависимости от способа реализации DSL, роль и взаимосвязь этих уровней может размываться и/или наследоваться от языка его реализации.
Разные авторы делают акцент на разных способах разработки предметно-специфичных языков:
реализация независимого компилятора (Ахо — Сети — Ульман[11], Кнут);
встраивание интерпретатора в язык общего назначения (Маккарти,  —  — , Уорд);
использование макросредств языка (и нередко отождествление их с термином «метапрограммирование») (Маккарти, , Шалуа — Манури — Пагано[12], Таха[13]);
чистое встраивание (English: pure embedding) (, Хейнс, Хьюдак[1], Шиверс[14], Бертомью[15], Рэмси[16]).
При использовании макросредств, в свою очередь, различают шаблонное метапрограммирование и многостадийную статическую интерпретацию[13][17][18][5].
Третий и четвёртый методы имеют фундаментальное преимущество перед первыми двумя — DSL не заменяет, а расширяет язык общего назначения[14][1][19][20], повторно используя весь инструментарий базового языка, начиная с парсера, благодаря чему:
появляется возможность комбинировать в едином коде возможности базового языка, общих библиотек к нему, разработанного предметно-специфичного языка и даже нескольких других разработанных аналогичным образом предметно-специфичных языков, применяя устоявшиеся для базового языка идиомы, трюки, скрещивая методологии;
устраняется необходимость реализовывать с нуля тривиальные вещи (такие как арифметика чисел) — достаточно адаптировать синтаксис;
устраняется необходимость разработки полного комплекса инструментария разработки (оптимизирующего транслятора с информативными сообщениями об ошибках, REPL, отладчика, профилировщика и пр.). При рекурсивном встраивании DSL повторное использование кода достигает гигантских масштабов[1].
Многие авторы состредотачиваются на эффективном (без интерпретации) встраивании в язык определённых изначально отсутствующих в нём возможностей для адаптации к определённым задачам[15][16], что в дальнейшем может служить основой для чистого встраивания DSL[21]. Значительное внимание уделяется использованию продолжений для разработки DSL с недетерминированной семантикой (, , , ,  и другие).
 Приложения подхода и самоприменимость

Важным подвидом ЯОП является , позволяющее самым разным людям, не имеющим никакого представления об информатике, эффективно решать множество прикладных задач. Роль этого приложения ЯОП столь велика, что едва ли не самым распространённым в мире языком программирования на практике оказываются средства вёрстки крупноформатных таблиц (English: spreadsheets)[6].
В зависимости от трактовки термина «метапрограммирование» (МП) и способа реализации DSL, либо ЯОП является квинтэссенцией МП, либо МП служит одним из способов реализации ЯОП. Последний вариант наиболее применим в случае встраивания DSL в язык общего назначения посредством макро-подмножества последнего[13]. При использовании средств визуальной разработки DSL[9][10] эти определения оказываются синонимичными, т.к. само визуальное программирование представляет собой простейшую форму МП. Рассмотрение МП в качестве самоприменения ЯОП означает:
для встраиваемых DSL — рекурсивное применение ЯОП, предлагаемое Уордом и Хьюдаком;
для независимых DSL — раскрутку компилятора (English: bootstrapping).
 Инструментарий
Для разработки независимых трансляторов широко распространены генераторы лексеров и парсеров на основе определения грамматики целевого DSL посредством БНФ и регулярных выражений:
Lex
Yacc
ANTLR
Библиотека Parsec[22] для языка Haskell
и другие.
При компиляции независимого DSL целевой платформой редко выбирается машинный код или даже Ассемблер, более предпочтительным (как для снижения трудоёмкости реализации DSL, так и для повышения портируемости) является использование платформы более высокого уровня:
языка общего назначения высокого уровня;
языка общего назначения среднего уровня (Си, BitC, Forth)
промежуточного языка или фреймфорка компиляторов (C--, MLRISC[23])
низкоуровневой виртуальной машины (LLVM)
Для встраивания DSL в язык общего назначения используются следующие технологии:
Метаязыки: Lisp, ML, Haskell, Nemerle, Forth, Tcl, Rebol
Встраивание объектного языка посредством квазицитирования[24]
 — параметрический парсер ОКамла[25][26]
Библиотека Boost.Spirit для языка C++ (за исключением регулярных грамматик и )
Чистое встраивание не предполагает каких-либо дополнительных инструментов, но накладывает довольно жёсткие ограничения на выбор базового языка.
При использовании многостадийной статической интерпретации целевая платформа совпадает с базовым языком[13][17][18][5].
В рамках традиционного программирования (на языках, наследованных от Алгола) использование некоторых идей ЯОП делает возможным инструментарий визуального программирования, разработанный в первой половине 2000-х годов[9][10][27][28]:
Intentional Software, Meta Programming System (JetBrains)[29]
 История, философия, терминология
В сообществе языка Lisp практически от момента создания практиковалось использование макросредств для адаптации к требованиям предметной области задачи. Этот подход, в частности, был подробно описан в книге Структура и интерпретация компьютерных программ. Аналогичные идеи временами применялись в сообществе языка Forth. В основном эти решения носили спонтанный характер, и зачастую их можно классифицировать как ad hoc-решения[13].
Во второй половине 1970-х годов была изобретена система типов Хиндли — Милнера, которая легла в основу языка ML (аббревиатура от «MetaLanguage» — Russian: МетаЯзык). Изначально ML разрабатывался в качестве DSL для системы автоматического доказательства теорем , но вскоре стало ясно, что он может быть хорошим прикладным языком общего назначения — более качественным, чем языки, изначально проектируемые быть языками общего назначения, т.к. отлажен на одной конкретной сложной задаче[30][31]. Как следствие, он породил целое семейство Х-М-типизированных языков, завоевавших популярность в качестве языков для разработки языков (метаязыков) и часто определяемых как «DSL для »[1].
В 1994 году Мартин Уорд (English: Martin Ward)[32] дал подробную характеристику методологии[2] и предложил термины «языково-ориентированное программирование» и «расходящаяся разработка» (или «разработка от центра к краям», ), отметив, что подход в разнообразных формах неоднократно применялся ранее. Термин «расходящаяся разработка» подчёркивает, что средним слоем () в результирующей системе является разработанный DSL,— в противовес ранее известным и широко до сих пор применяющимся методам «восходящей разработки» (), «нисходящей разработки» () и совмещающей их «сходящейся разработки» ().
Уорд также предложил использовать ЯОП рекурсивно, поэтапно наращивая сложность разрабатываемой системы снизу вверх; и сочетать ЯОП с быстрым прототипированием, разрабатывая сперва простейший прототип DSL (что может быть выполнено очень быстро) и простейшее решение с его использованием, затем, после тестирования языка, выявления недочётов и уточнения требований, дорабатывать DSL и переписывать решение на новой версии языка, и так далее итеративно.
 предложил[1] метод чистого встраивания (English: pure embedding) с применением типобезопасных языков (предпочтительно ленивых, таких как Haskell, но возможно и строгих, таких как ML, хотя в последнем случае реализация выходит несколько более громоздкой и менее естественной) и эквациональные рассуждения[7], рекурсивно разрабатывая систему сверху вниз и накапливая повторно используемый код в виде «DSL для разработки DSL».
Метод чистого встраивания породил термин «встраиваемый предметно-специфичный язык» (English: Embedded DSL, EDSL; иногда )[1][8]. Был разработан целый ряд EDSL над Хаскелем для программирования в чистом функциональном стиле интерактивных приложений реального времени (Fran, Fruit, FRP и RT-FRP, FAL, Frob, Fvision, Yampa)[33][19], сформировавших самостоятельную парадигму — функциональное реактивное программирование (ФРП). Это показывает, что ЯОП не является отдельной замкнутой парадигмой программирования, а напротив, может использоваться в качестве инструмента при разработке новых парадигм.
Вокруг Standard ML — базового диалекта ML — с начала 1990-х годов велись споры в отношении отсутствия макросредств в языке[30]. Критики утверждали, что отсутствие макросредств является недостатком, но сторонники строгой типизации возражали, что их отсутствие является как раз преимуществом. В другом диалекте ML — OCaml — была предложена компромиссная идея — параметризация синтаксиса за счёт выделения парсера в настраиваемый модуль  компилятора, посредством которой было разработано множество EDSL для OCaml. Позже появилось расширение для генерации кода во время выполнения — . В конце 1990-х годов была предложена идея типобезопасных макросредств как инструмента эффективной реализации типобезопасных DSL[34]. Эту идею вскоре воплотили в виде расширений MetaML[13][17][18] — для языка Standard ML и [35] — для языка Haskell. В первом случае макросредства рассматриваются исключительно как многостадийный статический интерпретатор; во втором они рассматриваются одновременно и как этот же подход, и как известное из языка Lisp квазицитирование, и как подсистема шаблонов, аналогичная имеющейся в языке C++.
Исследование возможности реализации и применения этих подходов в разных языках показали, что С++ является крайне неудобным инструментом разработки встраиваемых языков[36]. Тем не менее, С++ позволяет воплощать решения этого направления, культивированные и отлаженные под эгидой функционального программирования[5][37], что для мейнстримных языков является редким достоинством[5].
Данные предварительных исследований, опубликованные в 2012 году, показали, что независимый DSL оказывается удобнее в использовании, в то время как EDSL проще в реализации[8].
 Критика и сравнение с альтернативами

Достоинства
Template:Конец цитаты
ЯОП имеет множество достоинств перед традиционной «плоской» разработкой[2]:
Разделение сложностей. Реализация и собственно решение оказываются полностью независимы, что исключает экспоненциальный рост результирующей сложности разработки всего проекта.
Высокая скорость разработки. Всего несколько строк на DSL могут реализовывать очень сложные функции. Реализация DSL также сохраняется простой, так как содержит лишь необходимые функции.
Высокая модифицируемость. Исследования, на которые ссылается Мартин Уорд, показывают, что самым важным фактором, обусловливающим трудности модификации системы, является размер кода. Разделение логики и реализации и сокращение общего объёма кода существенно упрощают его модификацию и исправление ошибок. При традиционном подходе принятые решения по реализации оказываются «размазанными» по проекту, что затрудняет понимание зависимостей (решений, которые привели к написанию данного участка кода). Сторонники «модульного проектирования» приводят те же аргументы, но более фундаментальные проектные решения обычно не могут быть инкапсулированы в одном модуле.
Существенное увеличение коэффициента повторного использования кода. DSL, инкапсулирующий специфичные знания предметной области, может быть повторно использован для решения задач одного класса, в т.ч. для самой задачи разработки DSL[2][1].
Существенное упрощение портирования системы. Необходимо переделывать только реализацию DSL, тогда как логика системы (код на DSL) переносится без изменений. В случае с , реализация DSL нижнего уровня занимала всего 2-3 тысячи строк кода на Lisp, и в дальнейшем была переписана на Си всего за три человеко-дня. Другим примером служит высокая портируемость системы . Кроме того, после создания прототипа реализации DSL дальнейшая разработка приложения может быть распараллелена — одни разработчики занимаются решением прикладной задачи, в то время как другие независимо от них реализуют DSL на разных платформах и совершенствуют эти реализации.
Принципиальная возможность решения задач. Многие подзадачи не удавалось решить посредством классического подхода из-за превышения общей сложности решения возможностей человека по восприятию и переработке информации. Решение же на DSL оказывается не просто возможным, а очень простым и интуитивным, к тому же исключающим размножение ошибок, так как доступ к очень сложным функциям системы осуществляется через примитивы DSL.
Получение программных систем, расширяемых их пользователями[6]. DSL делает программирование доступным для специалистов предметной области, не имеющих специфичных знаний в программировании, и даёт им возможность самостоятельно расширять функциональность системы, что принципиально невозможно при использовании традиционного подхода.
Реализация языков путём разработки независимых трансляторов является рутинной задачей, так как накоплена обширная формальная база и основанного на ней инструментария (Lex/Yacc, ANTLR, Parsec[22]). Например, на Parsec разработка парсеров для языков с несложной грамматикой (сопоставимой с грамматикой Паскаля Вирта) выполняется за считанные человеко-часы[38][39].
Недостатки
Языково-ориентированное программирование имеет два основных недостатка перед традиционным, которые, однако, не являются фундаментальными: высокий порог вхождения для разработчиков языков (снижаемый ценой отказа от большинства преимуществ методологии) и трудности обеспечения вычислительной производительности. Оба недостатка актуальны лишь для разработчиков предметно-специфичных языков; пользователи языка (прикладные специалисты) получают чистые преимущества.
Ограничения
Для разработки новых языков требуется хорошая теоретическая подготовка и свободное владение семантически разными языками и их расширениями. Мартин Уорд отмечает, что проектирование хорошего языка, потенциально способного удовлетворять его пользователей и иметь длительный жизненный цикл — это сложная задача, требующая высокой степени грамотности в информатике, и рекомендует программистам постоянно практиковаться в разработке языков для накопления достаточного практического опыта. Кроме того, он указывает, что назначение ЯОП не в том, чтобы снизить порог вхождения для разработчиков, а наоборот, в том, чтобы расширить возможности и упростить работу квалифицированных разработчиков,— а уже в дальнейшем это приводит к снижению порога вхождения пользователей системы, необходимого для её использования и развития.
Методы встраивания DSL в язык общего назначения применимы далеко не в любом языке, т.к. требуют определённых свойств семантики базового языка в разных сочетаниях: аппликативной модели вызова, истинно полиморфной системы типов либо динамической типизации (см. полиморфизм), функций высшего порядка, продолжений, развитой подсистемы макрорасширения, рефлексивности, ленивости. Эти свойства доступны изначально (или могут быть полноценно реализованы) далеко не в любом языке. Чаще всего оба метода и их комбинации используются в диалектах языков, основанных на нетипизированном и типизированном лямбда-исчислении (математической модели описания семантик), порой с нестандартизированными специфичными расширениями: Common Lisp, Scheme, Standard ML, MetaML[13], Alice, OCaml, , Haskell, , Nemerle. Также эти методы применимы в языке Forth, хотя реально применяются разработчиками на Forth относительно редко. Все эти языки имеют высокий порог вхождения. Некоторые авторы отмечают возможность применения третьего метода в мейнстримном языке С++, но пригодность С++ для ЯОП подвергается критике[40].
Визуальная разработка DSL[9][10] имеет низкий порог вхождения, но жертвует рядом свойств ЯОП, описываемых Уордом, Хьюдаком и другими:
Понятие DSL определяется как «урезанный язык программирования (в большинстве случаев не полный по Тьюрингу)»;
Рассматриваются DSL только с детерминированной семантикой, в частности, Фаулер относит к DSL адаптивные объектные модели (так что размытие границ между математикой и семантикой, на котором делает акцент Хьюдак, не выполняется);
Не рассматриваются возможности ни рекурсивного применения ЯОП, ни увеличения числа реализаций разработанного DSL, так что эффективность реализации DSL целиком зависит от разработчиков визуальной среды.
Эффективность
Вычислительная производительность «небрежной» реализации DSL может оказаться невысокой, а хорошая оптимизация — неоправданно дорогой. Разумеется, в силу предназначения некоторых DSL, скорость для них не имеет принципиального значения (, AutoLisp). В остальных же случаях она зависит как от способа реализации, так и от целевой платформы компиляции, и во многих случаях удаётся добиться очень хороших показателей. Например, Валид Таха описывает[41] реализацию транслятора функционально чистого языка FRP методом порождения императивного кода на Си, с помощью которого были разработаны приложения реального времени для 16-битного микроконтроллера PIC16C66[42]. Хьюдак указывает[1], что многостадийные модульные реализации DSL методом чистого встраивания (см. Подход) в Haskell получаются крайне медлительными, так как каждый слой абстракции даёт 15-70-кратное замедление, — но за счёт применения техники суперкомпиляции скорость может быть обратно повышена на три порядка (от 400 до 2800 раз).
Возможна разработка DSL, предназначенного для оптимизации конструкций, применяемых в логике более высокого уровня. Например, был разработан язык OL (Operator Language)[43] для описания математических алгоритмов платформенно-независимым образом и упрощения портирования на новые архитектуры математических библиотек с высокими требованиями эффективности (см. числодробилка). Компилятор параметризуется данными об архитектуре процессора (поддержке векторных операций, количестве ядер и др.), а также порой выполняет автоматическое сравнительное тестирование вариантов реализации с выбором наиболее быстрой. В результате программа на декларативном языке сверхвысокого уровня порождает на выходе очень эффективный (сравнимый с написанным вручную) код на Си, реализующий алгоритм максимально эффективным для данной архитектуры образом. В данном случае компонентом эффективности также становится ужесточение размера входных данных — например, может быть построена быстрая функция для перемножения матриц размера 8x8.
Использование встраиваемых DSL в языках, для которых существуют глобально-оптимизирующие компиляторы (такие как , MLton), позволяет осуществлять языково-ориентированную декомпозицию задач без потерь эффективности в сравнении с другими подходами к проектированию, но может накладывать ограничения на разрабатываемый DSL. Это направление является предметом многих исследований.
Все эти решения являются частными, и применимость каждого из них зависит от природы разрабатываемого DSL на всех уровнях, либо наоборот, предъявляет к ней особые требования. Таким образом, соотнесение архитектуры проекта с эффективностью его реализации является неотъемлемой частью проблематики ЯОП. Это верно и для других подходов к проектированию, но в гораздо меньшей степени.
Примечания

Литература
Учебники, руководства, справочники, использование
CS1 maint: multiple names: authors list (link)
Check date values in: |date= (help)CS1 maint: multiple names: authors list (link)
CS1 maint: multiple names: authors list (link)
Cite journal requires |journal= (help)CS1 maint: date and year (link)
Cite journal requires |journal= (help)CS1 maint: date and year (link)
Check date values in: |date= (help)CS1 maint: extra text (link)
Cite journal requires |journal= (help)CS1 maint: date and year (link)
Cite journal requires |journal= (help)CS1 maint: date and year (link)
Cite journal requires |journal= (help)CS1 maint: date and year (link)
Cite journal requires |journal= (help)CS1 maint: multiple names: authors list (link) CS1 maint: date and year (link)
Cite journal requires |journal= (help)CS1 maint: date and year (link)
Cite journal requires |journal= (help)CS1 maint: date and year (link)
Cite journal requires |journal= (help)CS1 maint: date and year (link)
Cite journal requires |journal= (help)CS1 maint: date and year (link)
История, анализ, критика
Cite journal requires |journal= (help)CS1 maint: date and year (link)
Cite journal requires |journal= (help)CS1 maint: date and year (link)
Cite journal requires |journal= (help)CS1 maint: date and year (link)
Cite journal requires |journal= (help)CS1 maint: date and year (link)
Cite journal requires |journal= (help)CS1 maint: date and year (link)
Cite journal requires |journal= (help)CS1 maint: date and year (link)
Cite journal requires |journal= (help)CS1 maint: date and year (link)
Cite journal requires |journal= (help)CS1 maint: multiple names: authors list (link) CS1 maint: date and year (link)
Cite journal requires |journal= (help)CS1 maint: multiple names: authors list (link) CS1 maint: date and year (link)
Cite journal requires |journal= (help)CS1 maint: date and year (link)
Ссылки

Категория:Информатика
Категория:Языки программирования
Категория:Компиляторы
Категория:Парадигмы программирования
*
Категория:Метамоделирование