Мовно-орієнтоване програмування (ЯОП) (англ. Language Oriented Programming), також Расходящаяся розробка (англ. middle out development), також метаязыковая абстракція[en], Розробка, яка спирається на предметно-специфічну мову (англ. DSL-Based Development)[] — парадигма програмування, полягає в розбитті процесу розробки програмного забезпечення на стадії розробки предметно-орієнтованих мов (DSL) та опису власне рішення завдання з їх використанням. Стадії можуть вестися послідовно або паралельно, одноразово або рекурсивно; DSL можуть бути реалізовані залежно або незалежно від базової мови[⇨] і мати одну або безліч реалізацій.
ЯОП призначений для поділу складнощів: машино-орієнтована частина коду (низькорівнева функціональність) і людино-орієнтована (власне рішення прикладної задачі) розробляються незалежно один від одного, що виключає експонентний ріст результуючої складності розробки всього проекту і вирішує проблему складності як фундаментальну проблему програмування[], описану Фредеріком Бруксом у знаменитому есе «Срібної кулі немає», через яку виявляється неможливо простим удосконаленням робочого інструментарію підвищити продуктивність праці програмістів навіть на порядок. З цього прямо випливає більшість інших переваг[⇨].
Про достоїнства звуження спеціалізації мов говорили ще в середині 1980-х[3], а про достоїнства підвищення рівня мов — набагато раніше[4], але DSL-орієнтована розробка сформувалася як самостійна методологія лише до середини 1990-х[⇨].
Використання DSL замість мов загального призначення істотно підвищує рівень абстрактності коду, що дозволяє вести розробку швидко і ефективно створювати програми, які легкі в розумінні і супроводі; а також робить можливим або істотно спрощує вирішення багатьох завдань, пов'язаних з маніпулюванням програмами (породження програм, дослідження певної властивості програм — коректності, ефективності та ін.)[]. З іншого боку, розробка нової мови і ефективна його реалізація є нетривіальною проблемою теоретичної і прикладної інформатики[⇨].
Серед інших підходів до проектування програм ЯОП виділяється набагато більш агресивною спрямованістю на наближення комп'ютера до людини. Серед дослідників ЯОП існує думка, що в наукомістких завданнях добре спроектований і реалізований DSL робить спілкування людини з комп'ютером більш зручним і продуктивним, ніж графічний інтерфейс користувача. В якості прикладів найчастіше наводяться такі популярні предметно-специфічні мови: AutoLisp для комп'ютерного моделювання (САПР) ΤΕΧ для підготовки (комп'ютерної верстки) текстових документів Perl для маніпулювання текстами SQL СУБД Mathematica і для символьних обчислень Maple
та ін.
Переваги ЯОП проявляються навіть у тих випадках, коли DSL розробляється не для масового використання, а для вирішення єдиного завдання. Наприклад, при розробці системи автоматичного еквівалентного перетворення програм Ферма[en] перехід від «плоского» програмування на Ліспі до рекурсивного ЯОП (на Ліспі був реалізований мова WSL, на ньому — мова MetaWSL, а вже на ньому — цільова функціональність) не тільки дозволив скоротити загальний обсяг коду зі 100 до 16 тисяч рядків, але одночасно підвищив всі основні якісні характеристики коду і навіть зробив можливим рішення задач, що інакше вирішити не вдавалося[2].
Спрощено порівняти зростання трудовитрат при використанні традиційного та мовно-орієнтованого підходів дозволяє графік[1]. Як видно, ЯОП виявляється доцільним лише починаючи з деякого порогу обсягу і складності функціональності цільової системи.
Більшість дослідників ЯОП спирається на функціональні мови і метаязыки, що обумовлює високий поріг входження для розробників. Мартін Уорд відзначає можливість реалізації DSL на традиційних мовах, але лише після його остаточної розробки.
В мейнстрімі часто застосовується вбудовування інтерпретатора мови загального призначення (див. Підхід), хоча це робиться не тільки без апеляції до принципів ЯОП, але і часто без усвідомлення факту її застосування як такої. Найбільш часто вбудовуються: мова регулярних виразів (інтерпретатор PCRE), Lua, SQL, XML. Також був розроблений інструментарій візуального програмування для використання в мейнстрімі деяких ідей ЯОП.
Багато дослідників бачать мету ЯОП в тому, щоб повністю розмити межі між математичною моделлю та її реалізацією на ЕОМ і зробити можливою розробку програмного забезпечення фахівцями предметних областей, що не мають специфічних знань в програмуванні[]: -- перевірка точки входження в регіон:
inRegion :: Point -> Region -> Bool p 'inRegion' r = r p ... Завдяки точному фіксації семантики предметної області навіть не-програмісти виявляються здатні зрозуміти значну частину коду. В експерименті, проведеному на замовлення Naval Surface Warfare Center, абсолютно незнайомі з Хаскелом люди схоплювали основні поняття на льоту. Деякі навіть висловили невіра в те, що цей код був дійсно виконуваним. (Справді, незважаючи на присутність у тексті цього останнього речення, один з рецензентів першого чернетки даної роботи висловив невдоволення тим, що «робота заявляється як міркування одночасно про синтаксис і семантику, але її зміст в основному стосується синтаксису (як, наприклад, визначення inRegion), і не робиться ніяких відмінностей між математикою і програмуванням». Але насправді, це визначення inRegion цілком і повністю семантичне. Більш того, эквациональные міркування[] ... дозволяють розмити межу між математикою і програмуванням: програми можуть розглядатися як специфікації. Це особлива властивість, так як розширює застосування формальних методів.)
В основі підходу лежить ідея про те, що мова, спеціально розроблений під поставлену задачу, буде забезпечувати свідомо більш високі показники якості коду, ніж будь-яка мова загального призначення[], і що для вирішення складних промислових завдань більш ефективним буде винайти більш простий у розумінні (людино-орієнтований[] або точно інкапсульовану предметні знання[ мову, ніж долати труднощі використання наявного, навіть вкоріненого у промисловості[].
Більшість дослідників говорять про ЯОП як про переведення всієї індустрії розробки ПЗ на використання текстових мов 4-го і 5-го покоління[], але деякі орієнтуються на використання візуальних мов[].
Основні проблеми підходу полягають у знаходженні способів швидко створити реалізацію придуманого DSL, щоб почати розробляти власне рішення задачі, і в забезпеченні гарної обчислювальної продуктивності DSL.
Предметно-орієнтована мова, як і взагалі будь-яка мова програмування, визначається алфавітом, граматикою, семантикою і психолингвистикой, однак, в залежності від способу реалізації DSL, роль і взаємозв'язок цих рівнів може розмиватися і/або успадковуватися від мови його реалізації.
Різні автори роблять акцент на різних способах розробки предметно-специфічних мов: реалізація незалежного компілятора (Агв — Мережі — Ульман[], Батіг); вбудовування інтерпретатора мови загального призначення (Маккарті, Стіл[en] — Абельсон[en] — Сассман[en], Уорд); використання макросредств мови (і нерідко ототожнення їх з терміном «метапрограмування») (Маккарті, Лерой[en], Шалуа — Манури — Пагано[], Таха[]); чисте вбудовування (англ. pure embedding) (Феллейзен[en], Хейнс, Хьюдак[], Шиверс[, Бертомью[], Ремсі[]).
При використанні макросредств, у свою чергу, розрізняють шаблонне метапрограмування і багатостадійну статичну інтерпретацію[].
Третій та четвертий методи мають фундаментальну перевагу перед першими двома — DSL не замінює, а розширює мова загального призначення[], повторно використовуючи весь інструментарій базової мови, починаючи з парсера, завдяки чому: з'являється можливість комбінувати в єдиному коді можливості базової мови, спільних бібліотек до нього, розробленого предметно-специфічного мови і навіть кількох інших розроблених аналогічним чином предметно-специфічних мов, застосовуючи усталені для базового мови ідіоми, трюки, схрещуючи методології; усувається необхідність реалізовувати з нуля тривіальні речі (такі як арифметика чисел) — достатньо адаптувати синтаксис; усувається необхідність розробки повного комплексу інструментарію розробки (оптимізуючого транслятора з інформативними повідомленнями про помилки, REPL, налагоджувач, профилировщика тощо). При рекурсивном вбудовуванні DSL повторне використання коду досягає гігантських масштабів[].
Багато авторів состредотачиваются на ефективному (без інтерпретації) вбудовуванні в мову певних спочатку відсутніх у ньому можливостей для адаптації до певних завдань[], що в подальшому може слугувати основою для чистого вбудовування DSL[]. Значна увага приділяється використанню продовжень для розробки DSL з недетермінованою семантикою (Стіл[en], Уенді[en], Феллейзен[en], Ремсі[en], Реппи[en] та інші).
Важливим підвидом ЯОП є Користувальницьке програмування[en], що дозволяє самим різним людям, які не мають жодного уявлення про інформатику, ефективно вирішувати безліч прикладних задач. Роль цього додатка ЯОП настільки велика, що навряд чи не найпоширенішим у світі мовою програмування на практиці виявляються засоби верстки великоформатних таблиць (англ. spreadsheets)[].
В залежності від трактування терміна «метапрограмування» (МП) і способу реалізації DSL, або ЯОП є квінтесенцією МП, або МП служить одним із способів реалізації ЯОП. Останній варіант найбільш застосуємо у разі вбудовування DSL в мову загального призначення допомогою макро-підмножини останнього[]. При використанні засобів візуальної розробки DSL[] ці визначення виявляються синонімічними, оскільки саме візуальне програмування являє собою найпростішу форму МП. Розгляд МП в якості самоприменения ЯОП означає: для вбудованих DSL — рекурсивне застосування ЯОП, пропоноване Вордом і Хьюдаком; для незалежних DSL — розкручування компілятора (англ. bootstrapping).
Для розробки незалежних трансляторів широко поширені генератори лексеров і парсерів на основі визначення граматики цільового МКД допомогою БНФ та регулярних виразів: Лекс Yacc доступний ANTLR Бібліотека Парсек[] для мови Хаскелл
та інші.
При компіляції незалежного ДСЛ цільової платформою рідко вибирається машинний код або навіть Асемблер, більш кращим (як для зниження трудомісткості реалізації ДСЛ, так і для підвищення портируемости) є використання платформи більш високого рівня: мови загального призначення високого рівня; мови загального призначення середнього рівня (Сі, Біо, вперед) проміжного мови або фреймфорка компіляторів (СІ -, MLRISC[24]) низькорівневої віртуальної машини (з допомогою llvm)
Для вбудовування ДСЛ в мову загального призначення використовуються наступні технології: Метаязыки: Лисп, мл, на haskell, Nemerle, далі, на TCL, rebol був Вбудовування об'єктного мови допомогою квазицитирования[] CamlpX[АН] — параметричний парсер ОКамла[] Бібліотека Наддуву.Дух для мови С++ (за винятком регулярних граматик і лівої рекурсії[АН])
Чисте вбудовування не припускає яких-небудь додаткових інструментів, але накладає досить жорсткі обмеження на вибір базової мови[⇨].
При використанні багатостадійної статичної інтерпретації цільова платформа збігається з базовою мовою[].
В рамках традиційного програмування (на мовах, успадкованих від Algol'у) використання деяких ідей ЯОП робить можливим інструментарій візуального програмування, розроблений в першій половині 2000-х років[]: Умисне Програмного Забезпечення, Мета-Програмування Системи (Від Jetbrains)[]
Зростання складності будь-якої програмної системи принципово обмежений тією межею, до якого ще можна зберігати контроль над нею: якщо обсяг інформації, необхідний для осмислення компонента цієї системи, перевищує «місткість» мозку однієї людини, то цей компонент не буде до кінця зрозумілий. Стане надзвичайно важко допрацьовувати його або виправляти помилки, і від кожної коригування можна чекати введення нових помилок із-за цього неповного знання. Оригінальний текст (англ.) [показати]
— Martin Ward, «Language Oriented Programming»[]
ЯОП має безліч переваг перед традиційною «плоскої» розробкою[]: Поділ складнощів. Реалізація та власне рішення виявляються повністю незалежні, що виключає експонентний ріст результуючої складності розробки всього проекту. Висока швидкість розробки. Всього кілька рядків на DSL можуть реалізовувати дуже складні функції. Реалізація DSL також зберігається простий, так як містить лише необхідні функції. Висока можливість модифікацій. Дослідження, на які посилається Мартін Уорд, показують, що найважливішим чинником, що обумовлює труднощі модифікації системи, є розмір коду. Поділ логіки і реалізації і скорочення загального обсягу коду істотно спрощують його модифікацію і виправлення помилок. При традиційному підході прийняті рішення по реалізації виявляються «розмазаними» за проектом, що ускладнює розуміння залежностей (рішень, які призвели до написання даної ділянки коду). Прихильники «модульного проектування» наводять ті ж аргументи, але більш фундаментальні проектні рішення зазвичай не можуть бути інкапсульовані в одному модулі. Істотне збільшення коефіцієнта повторного використання коду. DSL, інкапсульовану специфічні знання предметної області, що може бути повторно використаний для вирішення завдань одного класу, у т. ч. для самої задачі розробки DSL[]. Суттєве спрощення портування системи. Необхідно переробляти тільки реалізацію DSL, тоді як логіка системи (код на DSL) переноситься без змін. У випадку з Ферма[en], реалізація DSL нижнього рівня займала всього 2-3 тисячі рядків коду на Lisp, і надалі була переписана на Сі всього за три людино-дня. Іншим прикладом служить висока портируемость системи ΤΕΧ. Крім того, після створення прототипу реалізації DSL подальша розробка програми може бути распараллелена — одні розробники займаються вирішенням прикладної задачі, в той час як інші незалежно від них реалізують DSL на різних платформах і вдосконалюють ці реалізації. Принципова можливість розв'язання задач. Багато підзадачі не вдавалося вирішити за допомогою класичного підходу з-за перевищення цілому рішення можливостей людини по сприйняттю і переробці інформації. Рішення ж на DSL виявляється не просто можливим, а дуже простим і інтуїтивним, до того ж виключає розмноження помилок, так як доступ до дуже складних функцій системи здійснюється через примітиви DSL. Отримання програмних систем, розширюваних їх користувачами[]. DSL робить програмування доступним для фахівців предметної області, що не мають специфічних знань в програмуванні, і дає їм можливість самостійно розширювати функціональність системи, що принципово неможливо при використанні традиційного підходу.
Реалізація мов шляхом розробки незалежних трансляторів є рутинною завданням, так як накопичена велика формальна бази і заснованого на ній інструментарію (Lex/Yacc, ANTLR, Parsec[]). Наприклад, на Parsec розробка парсерів для мов з нескладної граматикою (порівнянної з граматикою Паскаля Вірта) виконується за лічені людино-години
Мовно-орієнтоване програмування має два основних недоліки перед традиційним, які, однак, не є фундаментальними: високий поріг входження для розробників мов (снижаемый ціною відмови від більшості переваг методології) і труднощі забезпечення обчислювальної продуктивності. Обидва нестачі актуальні лише для розробників предметно-специфічних мов; користувачі мови (прикладні фахівці) отримують чисті переваги.
Для розробки нових мов потрібна хороша теоретична підготовка та вільне володіння семантично різними мовами та їх розширеннями. Мартін Уорд зазначає, що проектування хорошого мови, потенційно здатного задовольняти його користувачів і мати тривалий життєвий цикл — це складне завдання, що вимагає високого ступеня грамотності в інформатиці, і рекомендує програмістам постійно практикуватися в розробці мов для накопичення достатнього практичного досвіду. Крім того, він вказує, що призначення ЯОП не в тому, щоб знизити поріг входження для розробників, а навпаки, в тому, щоб розширити можливості і спростити роботу кваліфікованих розробників,— а вже в подальшому це призводить до зниження порогу входження користувачів системи, необхідного для її використання та розвитку.
Методи вбудовування DSL в мову загального призначення застосовуються далеко не в будь-якій мові, оскільки вимагають певних властивостей семантики базової мови в різних поєднаннях: аппликативной моделі виклику, істинно поліморфної системи типів або динамічної типізації (див. поліморфізм), функцій вищого порядку, продовжень, розвиненою підсистеми макрорасширения, рефлексивності, ліниво. Ці властивості доступні спочатку (або можуть бути повноцінно реалізовані) далеко не в будь-якій мові. Найчастіше обидва методи і їх комбінації використовуються в діалектах мов, заснованих на нетипизированном і типизированном лямбда-численні (математичної моделі опису семантик), деколи з нестандартизированными специфічними розширеннями: Common Lisp, Scheme, Standard ML, MetaML[], Alice, OCaml, MetaOCaml[en], Haskell, Template Haskell[en], Nemerle. Також ці методи застосовні в мові Forth, хоча реально застосовуються розробниками Forth відносно рідко. Всі ці мови мають високий поріг входження. Деякі автори вказують на можливість застосування третього методу в мейнстрімному мовою З++, але придатність С++ для ЯОП піддається критикеОшибка у виносках?: Відсутній закриваючий тег </ref> реалізацію транслятора функціонально чистого мови FRP методом породження імперативного коду на Сі, за допомогою якого були розроблені програми реального часу для 16-бітного мікроконтролера PIC16C66[41]. Хьюдак вказує[], що багатостадійні модульні реалізації DSL методом чистого вбудовування (див. Підхід) в Haskell виходять вкрай повільними, так як кожен шар абстракції дає 15-70-кратне уповільнення, — але за рахунок застосування техніки суперкомпиляции швидкість може бути назад підвищена на три порядки (від 400 до 2800 разів).
Можлива розробка DSL, призначеного для оптимізації конструкцій, що застосовуються в логіці більш високого рівня. Наприклад, був розроблений мова OL (Operator Language)[] для опису математичних алгоритмів платформно-незалежних чином і спрощення портування на нові архітектури математичних бібліотек з високими вимогами ефективності (див. числодробилка). Компілятор параметризуется даними про архітектуру процесора (підтримки векторних операцій, кількості ядер і ін), а також часом виконує автоматичне порівняльне тестування варіантів реалізації з вибором найбільш швидкою. В результаті програма на декларативної мови надвисокого рівня породжує на виході дуже ефективний (порівнянний з написаним вручну) код на Сі, що реалізує алгоритм максимально ефективним для даної архітектури. В даному випадку компонентом ефективності також стає посилення розміру вхідних даних, наприклад, може бути побудована швидка функція для множення матриць розміру 8x8.
Використання вбудованих DSL мови, для яких існують глобально-оптимізують компіляторів (такі як Stalin Scheme[en], MLton), дозволяє здійснювати мовно-орієнтовану декомпозицію задач без втрат ефективності в порівнянні з іншими підходами до проектування, але може накладати обмеження на розроблювальний DSL. Цей напрямок є предметом багатьох досліджень.
Всі ці рішення є приватними, і придатність кожного з них залежить від природи розроблюваного DSL на всіх рівнях, або навпаки, пред'являє до неї особливі вимоги. Таким чином, співвіднесення архітектури проекту з ефективністю його реалізації є невід'ємною частиною проблематики ЯОП. Це вірно і для інших підходів до проектування, але в набагато меншому ступені.
