Русская Википедия:Языково-ориентированное программирование

Материал из Онлайн справочника
Перейти к навигацииПерейти к поиску

Шаблон:Парадигмы программирования Языково-ориентированное программирование (ЯОП) (Шаблон:Lang-en), также Расходящаяся разработка (Шаблон:Lang-en), также метаязыковая абстракция, также Разработка, опирающаяся на предметно-специфичный язык (Шаблон:Lang-en)Шаблон:Sfn — парадигма программирования, заключающаяся в разбиении процесса разработки программного обеспечения на стадии разработки предметно-ориентированных языков (DSL) и описания собственно решения задачи с их использованием. Стадии могут вестись последовательно или параллельно, однократно или рекурсивноШаблон:SfnШаблон:Sfn; DSL могут быть реализованы зависимо или независимо от базового языкаШаблон:Переход и иметь одну или множество реализаций.

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

ЯОП предназначено для разделения сложностей: машино-ориентированная часть кода (низкоуровневая функциональность) и человеко-ориентированная (собственно решение прикладной задачи) разрабатываются независимо друг от друга, что исключает экспоненциальный рост результирующей сложности разработки всего проекта и решает проблему сложности как фундаментальную проблему программированияШаблон:Sfn, описанную Фредериком Бруксом в знаменитом эссе «Серебряной пули нет», из-за которой оказывается невозможно простым совершенствованием рабочего инструментария повысить производительность труда программистов даже на порядок. Из этого же прямо следует большинство остальных преимуществШаблон:Переход.

О достоинствах сужения специализации языков говорили ещё в середине 1980-хШаблон:Sfn, а о достоинствах повышения уровня языков — намного раньшеШаблон:Sfn, но DSL-ориентированная разработка сформировалась как самостоятельная методология лишь к середине 1990-хШаблон:Переход.

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

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

и др.

Файл:Hudak LOP vs Conventional.gif
Сравнение ЯОП с традиционным подходом

Преимущества ЯОП проявляются даже в тех случаях, когда DSL разрабатывается не для массового использования, а для решения единственной задачи. Например, при разработке системы автоматического эквивалентного преобразования программ Шаблон:Iw переход от «плоского» программирования на Лиспе к рекурсивному ЯОП (на Лиспе был реализован язык WSL, на нём — язык MetaWSL, а уже на нём — целевая функциональность) не только позволил сократить общий объём кода со 100 до 16 тысяч строк, но одновременно повысил все основные качественные характеристики кода и даже сделал возможным решение задач, которые иначе решить не удавалосьШаблон:Sfn.

Упрощённо сравнить рост трудозатрат при использовании традиционного и языково-ориентированного подходов позволяет графикШаблон:Sfn. Как видно, ЯОП оказывается целесообразно лишь начиная с некоторого порога объёма и сложности функциональности целевой системы.

Большинство исследователей ЯОП опирается на функциональные языки и метаязыки, что обусловливает высокий порог вхождения для разработчиков. Мартин Уорд отмечает возможность реализации DSL на традиционных языках, но лишь после его окончательной разработки.

В мейнстриме часто применяется встраивания интерпретатора в язык общего назначения (см. Подход), хотя это делается не только без апелляции к принципам ЯОП, но и зачастую без осознания факта её применения как таковой. Наиболее часто встраиваются: язык регулярных выражений (интерпретатор PCRE), Lua, SQL, XML. Также был разработан инструментарий визуального программирования для использования в мейнстриме некоторых идей ЯОП.

Многие исследователи видят цель ЯОП в том, чтобы полностью размыть границы между математической моделью и её реализацией на ЭВМ и сделать возможной разработку программного обеспечения специалистами предметных областей, не имеющими специфичных знаний в программированииШаблон:SfnШаблон:Sfn: Шаблон:Начало цитаты-- проверка вхождения точки в регион:
inRegion :: Point -> Region -> Bool
p ‘inRegion‘ r = r p
...
Благодаря точному запечатлению семантики предметной области даже не-программисты оказываются способны понять значительную часть кода. В эксперименте, проведённом по заказу Naval Surface Warfare Center, совершенно незнакомые с Хаскелом люди схватывали основные понятия на лету. Некоторые даже выразили неверие в то, что этот код был действительно исполнимым.
(В самом деле, несмотря на присутствие в тексте этого последнего предложения, один из рецензентов первого черновика данной работы выразил недовольство тем, что «работа заявляется как рассуждения одновременно о синтаксисе и семантике, но её содержание в основном касается синтаксиса (как, например, определение inRegion), и не делается никаких различий между математикой и программированием». Но на самом деле, это определение inRegion целиком и полностью семантическое. Более того, эквациональные рассуждения[1] ... позволяют размыть грань между математикой и программированием: программы могут рассматриваться как спецификации. Это особое свойство, так как расширяет применение формальных методов.)Шаблон:OqШаблон:Конец цитаты

Подход

В основе подхода лежит идея о том, что язык, специально разработанный под поставленную задачу, будет обеспечивать заведомо более высокие показатели качества кода, чем любой язык общего назначенияШаблон:SfnШаблон:Sfn, и что для решения сложных промышленных задач более эффективным будет изобрести более простой в понимании (человеко-ориентированныйШаблон:Sfn или точно инкапсулирующий предметные знанияШаблон:SfnШаблон:Sfn) язык, нежели преодолевать трудности использования имеющегося, даже укоренившегося в промышленностиШаблон:Sfn.

Большинство исследователей говорят о ЯОП как о переводе всей индустрии разработки ПО на использование текстовых языков 4-го и 5-го поколенияШаблон:Sfn, но некоторые ориентируются на использование визуальных языков[2][3].

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

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

Разные авторы делают акцент на разных способах разработки предметно-специфичных языков:

При использовании макросредств, в свою очередь, различают шаблонное метапрограммирование и многостадийную статическую интерпретациюШаблон:SfnШаблон:SfnШаблон:SfnШаблон:Sfn.

Третий и четвёртый методы имеют фундаментальное преимущество перед первыми двумя — DSL не заменяет, а расширяет язык общего назначенияШаблон:SfnШаблон:SfnШаблон:SfnШаблон:Sfn, повторно используя весь инструментарий базового языка, начиная с парсера, благодаря чему:

  • появляется возможность комбинировать в едином коде возможности базового языка, общих библиотек к нему, разработанного предметно-специфичного языка и даже нескольких других разработанных аналогичным образом предметно-специфичных языков, применяя устоявшиеся для базового языка идиомы, трюки, скрещивая методологии;
  • устраняется необходимость реализовывать с нуля тривиальные вещи (такие как арифметика чисел) — достаточно адаптировать синтаксис;
  • устраняется необходимость разработки полного комплекса инструментария разработки (оптимизирующего транслятора с информативными сообщениями об ошибках, REPL, отладчика, профилировщика и пр.). При рекурсивном встраивании DSL повторное использование кода достигает гигантских масштабовШаблон:Sfn.

Многие авторы состредотачиваются на эффективном (без интерпретации) встраивании в язык определённых изначально отсутствующих в нём возможностей для адаптации к определённым задачамШаблон:SfnШаблон:Sfn, что в дальнейшем может служить основой для чистого встраивания DSLШаблон:Sfn. Значительное внимание уделяется использованию продолжений для разработки DSL с недетерминированной семантикой (Шаблон:Iw, Шаблон:Iw, Шаблон:Iw, Шаблон:Iw, Шаблон:Iw и другие).

Приложения подхода и самоприменимость

Важным подвидом ЯОП является Пользовательское программирование, позволяющее самым разным людям, не имеющим никакого представления об информатике, эффективно решать множество прикладных задач. Роль этого приложения ЯОП столь велика, что едва ли не самым распространённым в мире языком программирования на практике оказываются средства вёрстки крупноформатных таблиц (Шаблон:Lang-en)Шаблон:Sfn.

В зависимости от трактовки термина «метапрограммирование» (МП) и способа реализации DSL, либо ЯОП является квинтэссенцией МП, либо МП служит одним из способов реализации ЯОП. Последний вариант наиболее применим в случае встраивания DSL в язык общего назначения посредством макро-подмножества последнегоШаблон:Sfn. При использовании средств визуальной разработки DSL[2][3] эти определения оказываются синонимичными, т.к. само визуальное программирование представляет собой простейшую форму МП. Рассмотрение МП в качестве самоприменения ЯОП означает:

Инструментарий

Для разработки независимых трансляторов широко распространены генераторы лексеров и парсеров на основе определения грамматики целевого DSL посредством БНФ и регулярных выражений:

и другие.

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

  • языка общего назначения высокого уровня;
  • языка общего назначения среднего уровня (Си, BitC, Forth)
  • промежуточного языка или фреймфорка компиляторов (C--, MLRISC[6])
  • низкоуровневой виртуальной машины (LLVM)

Для встраивания DSL в язык общего назначения используются следующие технологии:

Чистое встраивание не предполагает каких-либо дополнительных инструментов, но накладывает довольно жёсткие ограничения на выбор базового языкаШаблон:Переход.

При использовании многостадийной статической интерпретации целевая платформа совпадает с базовым языкомШаблон:SfnШаблон:SfnШаблон:SfnШаблон:Sfn.

В рамках традиционного программирования (на языках, наследованных от Алгола) использование некоторых идей ЯОП делает возможным инструментарий визуального программирования, разработанный в первой половине 2000-х годов[2][3][10][11]:

  • Intentional Software, Meta Programming System (JetBrains)[12]

История, философия, терминология

В сообществе языка Lisp практически от момента создания практиковалось использование макросредств для адаптации к требованиям предметной области задачи. Этот подход, в частности, был подробно описан в книге Структура и интерпретация компьютерных программ. Аналогичные идеи временами применялись в сообществе языка Forth. В основном эти решения носили спонтанный характер, и зачастую их можно классифицировать как ad hoc-решенияШаблон:Sfn.

Во второй половине 1970-х годов была изобретена система типов Хиндли — Милнера, которая легла в основу языка ML (аббревиатура от «MetaLanguage» — Шаблон:Lang-ru). Изначально ML разрабатывался в качестве DSL для системы автоматического доказательства теорем LCF, но вскоре стало ясно, что он может быть хорошим прикладным языком общего назначения — более качественным, чем языки, изначально проектируемые быть языками общего назначения, т.к. отлажен на одной конкретной сложной задачеШаблон:SfnШаблон:Sfn. Как следствие, он породил целое семейство Х-М-типизированных языков, завоевавших популярность в качестве языков для разработки языков (метаязыков) и часто определяемых как «DSL для Шаблон:Iw»Шаблон:Sfn.

В 1994 году Мартин Уорд (Шаблон:Lang-en)[13] дал подробную характеристику методологииШаблон:Sfn и предложил термины «языково-ориентированное программирование» и «расходящаяся разработка» (или «разработка от центра к краям», Шаблон:Lang-en2), отметив, что подход в разнообразных формах неоднократно применялся ранее. Термин «расходящаяся разработка» подчёркивает, что средним слоем (Шаблон:Lang-en2) в результирующей системе является разработанный DSL,— в противовес ранее известным и широко до сих пор применяющимся методам «восходящей разработки» (Шаблон:Iw), «нисходящей разработки» (Шаблон:Iw) и совмещающей их «сходящейся разработки» (Шаблон:Lang-en2).

Уорд также предложил использовать ЯОП рекурсивно, поэтапно наращивая сложность разрабатываемой системы снизу вверх; и сочетать ЯОП с быстрым прототипированием, разрабатывая сперва простейший прототип DSL (что может быть выполнено очень быстро) и простейшее решение с его использованием, затем, после тестирования языка, выявления недочётов и уточнения требований, дорабатывать DSL и переписывать решение на новой версии языка, и так далее итеративно.

Шаблон:Iw предложилШаблон:Sfn метод чистого встраивания (Шаблон:Lang-en) с применением типобезопасных языков (предпочтительно ленивых, таких как Haskell, но возможно и строгих, таких как ML, хотя в последнем случае реализация выходит несколько более громоздкой и менее естественной) и эквациональные рассуждения[1], рекурсивно разрабатывая систему сверху вниз и накапливая повторно используемый код в виде «DSL для разработки DSL».

Метод чистого встраивания породил термин «встраиваемый предметно-специфичный язык» (Шаблон:Lang-en; иногда Шаблон:Lang-en2)Шаблон:SfnШаблон:Sfn. Был разработан целый ряд EDSL над Хаскелем для программирования в чистом функциональном стиле интерактивных приложений реального времени (Fran, Fruit, FRP и RT-FRP, FAL, Frob, Fvision, Yampa)Шаблон:SfnШаблон:Sfn, сформировавших самостоятельную парадигму — функциональное реактивное программирование (ФРП). Это показывает, что ЯОП не является отдельной замкнутой парадигмой программирования, а напротив, может использоваться в качестве инструмента при разработке новых парадигм.

Вокруг [[Standard ML|Шаблон:Nowrap]] — базового диалекта ML — с начала 1990-х годов велись споры в отношении отсутствия макросредств в языкеШаблон:Sfn. Критики утверждали, что отсутствие макросредств является недостатком, но сторонники строгой типизации возражали, что их отсутствие является как раз преимуществом. В другом диалекте ML — OCaml — была предложена компромиссная идея — параметризация синтаксиса за счёт выделения парсера в настраиваемый модуль Шаблон:Iw компилятора, посредством которой было разработано множество EDSL для OCaml. Позже появилось расширение для генерации кода во время выполнения — Шаблон:Iw. В конце 1990-х годов была предложена идея типобезопасных макросредств как инструмента эффективной реализации типобезопасных DSLШаблон:Sfn. Эту идею вскоре воплотили в виде расширений Шаблон:NowrapШаблон:SfnШаблон:SfnШаблон:Sfn — для языка [[Standard ML|Шаблон:Nowrap]] и Шаблон:IwШаблон:Sfn — для языка Haskell. В первом случае макросредства рассматриваются исключительно как многостадийный статический интерпретатор; во втором они рассматриваются одновременно и как этот же подход, и как известное из языка Lisp квазицитирование, и как подсистема шаблонов, аналогичная имеющейся в языке C++.

Исследование возможности реализации и применения этих подходов в разных языках показали, что C++ является крайне неудобным инструментом разработки встраиваемых языковШаблон:Sfn. Тем не менее, C++ позволяет воплощать решения этого направления, культивированные и отлаженные под эгидой функционального программированияШаблон:Sfn[14], что для мейнстримных языков является редким достоинствомШаблон:Sfn.

Данные предварительных исследований, опубликованные в 2012 году, показали, что независимый DSL оказывается удобнее в использовании, в то время как EDSL проще в реализацииШаблон:Sfn.

Критика и сравнение с альтернативами

Достоинства

Шаблон:Начало цитатыРост сложности любой программной системы принципиально ограничен тем пределом, до которого ещё можно сохранять контроль над ней: если объём информации, требуемый для осмысления компонента этой системы, превышает «вместимость» мозга одного человека, то этот компонент не будет до конца понят. Станет чрезвычайно тяжело дорабатывать его или исправлять ошибки, и от каждой корректировки можно ждать введения новых ошибок из-за этого неполного знания.Шаблон:OqШаблон:Конец цитаты

ЯОП имеет множество достоинств перед традиционной «плоской» разработкойШаблон:Sfn:

  • Разделение сложностей. Реализация и собственно решение оказываются полностью независимы, что исключает экспоненциальный рост результирующей сложности разработки всего проекта.
  • Высокая скорость разработки. Всего несколько строк на DSL могут реализовывать очень сложные функции. Реализация DSL также сохраняется простой, так как содержит лишь необходимые функции.
  • Высокая модифицируемость. Исследования, на которые ссылается Мартин Уорд, показывают, что самым важным фактором, обусловливающим трудности модификации системы, является размер кода. Разделение логики и реализации и сокращение общего объёма кода существенно упрощают его модификацию и исправление ошибок. При традиционном подходе принятые решения по реализации оказываются «размазанными» по проекту, что затрудняет понимание зависимостей (решений, которые привели к написанию данного участка кода). Сторонники «модульного проектирования» приводят те же аргументы, но более фундаментальные проектные решения обычно не могут быть инкапсулированы в одном модуле.
  • Существенное увеличение коэффициента повторного использования кода. DSL, инкапсулирующий специфичные знания предметной области, может быть повторно использован для решения задач одного класса, в т.ч. для самой задачи разработки DSLШаблон:SfnШаблон:Sfn.
  • Существенное упрощение портирования системы. Необходимо переделывать только реализацию DSL, тогда как логика системы (код на DSL) переносится без изменений. В случае с Шаблон:Iw, реализация DSL нижнего уровня занимала всего 2-3 тысячи строк кода на Lisp, и в дальнейшем была переписана на Си всего за три человеко-дня. Другим примером служит высокая портируемость системы [[Tex|Шаблон:TeX]]. Кроме того, после создания прототипа реализации DSL дальнейшая разработка приложения может быть распараллелена — одни разработчики занимаются решением прикладной задачи, в то время как другие независимо от них реализуют DSL на разных платформах и совершенствуют эти реализации.
  • Принципиальная возможность решения задач. Многие подзадачи не удавалось решить посредством классического подхода из-за превышения общей сложности решения возможностей человека по восприятию и переработке информации. Решение же на DSL оказывается не просто возможным, а очень простым и интуитивным, к тому же исключающим размножение ошибок, так как доступ к очень сложным функциям системы осуществляется через примитивы DSL.
  • Получение программных систем, расширяемых их пользователямиШаблон:Sfn. DSL делает программирование доступным для специалистов предметной области, не имеющих специфичных знаний в программировании, и даёт им возможность самостоятельно расширять функциональность системы, что принципиально невозможно при использовании традиционного подхода.

Реализация языков путём разработки независимых трансляторов является рутинной задачей, так как накоплена обширная формальная база и основанного на ней инструментария (Lex/Yacc, ANTLR, Parsec[5]). Например, на Parsec разработка парсеров для языков с несложной грамматикой (сопоставимой с грамматикой Паскаля Вирта) выполняется за считанные человеко-часы[15][16].

Недостатки

Языково-ориентированное программирование имеет два основных недостатка перед традиционным, которые, однако, не являются фундаментальными: высокий порог вхождения для разработчиков языков (снижаемый ценой отказа от большинства преимуществ методологии) и трудности обеспечения вычислительной производительности. Оба недостатка актуальны лишь для разработчиков предметно-специфичных языков; пользователи языка (прикладные специалисты) получают чистые преимущества.

Ограничения

Для разработки новых языков требуется хорошая теоретическая подготовка и свободное владение семантически разными языками и их расширениями. Мартин Уорд отмечает, что проектирование хорошего языка, потенциально способного удовлетворять его пользователей и иметь длительный жизненный цикл — это сложная задача, требующая высокой степени грамотности в информатике, и рекомендует программистам постоянно практиковаться в разработке языков для накопления достаточного практического опыта. Кроме того, он указывает, что назначение ЯОП не в том, чтобы снизить порог вхождения для разработчиков, а наоборот, в том, чтобы расширить возможности и упростить работу квалифицированных разработчиков,— а уже в дальнейшем это приводит к снижению порога вхождения пользователей системы, необходимого для её использования и развития.

Методы встраивания DSL в язык общего назначения применимы далеко не в любом языке, т.к. требуют определённых свойств семантики базового языка в разных сочетаниях: аппликативной модели вызова, истинно полиморфной системы типов либо динамической типизации (см. полиморфизм), функций высшего порядка, продолжений, развитой подсистемы макрорасширения, рефлексивности, ленивости. Эти свойства доступны изначально (или могут быть полноценно реализованы) далеко не в любом языке. Чаще всего оба метода и их комбинации используются в диалектах языков, основанных на нетипизированном и типизированном лямбда-исчислении (математической модели описания семантик), порой с нестандартизированными специфичными расширениями: Common Lisp, Scheme, Standard ML, MetaMLШаблон:Sfn, Alice, OCaml, Шаблон:Iw, Haskell, Шаблон:Iw, Nemerle. Также эти методы применимы в языке Forth, хотя реально применяются разработчиками на Forth относительно редко. Все эти языки имеют высокий порог вхождения. Некоторые авторы отмечают возможность применения третьего метода в мейнстримном языке C++, но пригодность C++ для ЯОП подвергается критике[17].

Визуальная разработка DSL[2][3] имеет низкий порог вхождения, но жертвует рядом свойств ЯОП, описываемых Уордом, Хьюдаком и другими:

  • Понятие DSL определяется как «урезанный язык программирования (в большинстве случаев не полный по Тьюрингу)»;
  • Рассматриваются DSL только с детерминированной семантикой, в частности, Фаулер относит к DSL адаптивные объектные модели (так что размытие границ между математикой и семантикой, на котором делает акцент Хьюдак, не выполняется);
  • Не рассматриваются возможности ни рекурсивного применения ЯОП, ни увеличения числа реализаций разработанного DSL, так что эффективность реализации DSL целиком зависит от разработчиков визуальной среды.

Эффективность

Вычислительная производительность «небрежной» реализации DSL может оказаться невысокой, а хорошая оптимизация — неоправданно дорогой. Разумеется, в силу предназначения некоторых DSL, скорость для них не имеет принципиального значения ([[Tex|Шаблон:TeX]], AutoLisp). В остальных же случаях она зависит как от способа реализации, так и от целевой платформы компиляции, и во многих случаях удаётся добиться очень хороших показателей. Например, Валид Таха описывает[18] реализацию транслятора функционально чистого языка FRP методом порождения императивного кода на Си, с помощью которого были разработаны приложения реального времени для 16-битного микроконтроллера PIC16C66[19]. Хьюдак указываетШаблон:Sfn, что многостадийные модульные реализации DSL методом чистого встраивания (см. Подход) в Haskell получаются крайне медлительными, так как каждый слой абстракции даёт 15-70-кратное замедление, — но за счёт применения техники суперкомпиляции скорость может быть обратно повышена на три порядка (от 400 до 2800 раз).

Возможна разработка DSL, предназначенного для оптимизации конструкций, применяемых в логике более высокого уровня. Например, был разработан язык OL (Operator Language)[20] для описания математических алгоритмов платформенно-независимым образом и упрощения портирования на новые архитектуры математических библиотек с высокими требованиями эффективности (см. числодробилка). Компилятор параметризуется данными об архитектуре процессора (поддержке векторных операций, количестве ядер и др.), а также порой выполняет автоматическое сравнительное тестирование вариантов реализации с выбором наиболее быстрой. В результате программа на декларативном языке сверхвысокого уровня порождает на выходе очень эффективный (сравнимый с написанным вручную) код на Си, реализующий алгоритм максимально эффективным для данной архитектуры образом. В данном случае компонентом эффективности также становится ужесточение размера входных данных — например, может быть построена быстрая функция для перемножения матриц размера 8x8.

Использование встраиваемых DSL в языках, для которых существуют глобально-оптимизирующие компиляторы (такие как Шаблон:Iw, MLton), позволяет осуществлять языково-ориентированную декомпозицию задач без потерь эффективности в сравнении с другими подходами к проектированию, но может накладывать ограничения на разрабатываемый DSL. Это направление является предметом многих исследований.

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

Примечания

Шаблон:Примечания

Литература

Учебники, руководства, справочники, использование

История, анализ, критика

Ссылки

Партнерские ресурсы
Криптовалюты
Магазины
Хостинг
Разное

  1. ↑ 1,0 1,1 Equational reasoning
  2. ↑ 2,0 2,1 2,2 2,3 Шаблон:Статья
  3. ↑ 3,0 3,1 3,2 3,3 Шаблон:Статья
  4. ↑ Developing Applications With Objective Caml
  5. ↑ 5,0 5,1 Шаблон:Cite web
  6. ↑ Шаблон:Cite web
  7. ↑ Шаблон:Cite web
  8. ↑ Шаблон:Cite web
  9. ↑ Шаблон:Cite web
  10. ↑ Шаблон:Cite web
  11. ↑ Шаблон:Cite web
  12. ↑ JetBrains - DSL Development Environment
  13. ↑ Martin Ward's Homepage
  14. ↑ Шаблон:Статья
  15. ↑ Шаблон:Cite web
  16. ↑ Шаблон:Cite web
  17. ↑ Ошибка цитирования Неверный тег <ref>; для сносок one не указан текст
  18. ↑ Шаблон:Статья
  19. ↑ PIC16C66 - PIC® Microcontrollers
  20. ↑ Шаблон:Статья
Источник — http://wikihandbk.com/ruwiki/index.php?title=Русская_Википедия:Языково-ориентированное_программирование&oldid=11425062