Чи практичне мовне орієнтування?

Я читав цю статтю про мовно-орієнтоване програмування. Він вказує на деякі слабкі сторони у сучасних процедурних / процедурних підходах до програмування та пропонує нову парадигму програмування, яка їх вирішить.

Я все для невеликих, нещільно зв'язаних частин програми: Набагато краще вивчити багато дрібних речей, які ви будете використовувати, ніж пару великих речей, якими ви користуєтесь лише шматочки та шматочки.

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

• Безліч мов сценаріїв, які легко створюються
• Єдина, легко розширювана мова, яка може переписати себе для задоволення потреб програміста

Якщо він пропонує другий, я відповів би "Вже зроблено!" і наведіть Лісп як приклад. Як пропонує Пол Ґрем, мови, як видається, все одно постійно рухаються до цього .

Що стосується першого, я вважаю, що це гарна ідея, якщо є основна мова, яка поєднує їх усіх разом. Мені здається, це слабке місце: спілкування між мовами. Чи використовуєте ви дзвінки, що є процедурною концепцією чи передачею повідомлення, що нагадує мені про міжпроцесорний зв’язок? Я б вітав можливість працювати з невеликими мовами домену, якщо їх легко одночасно використовувати. Чи був би такий підхід (ЛОП) практичним?

Я довго виступаю за DSL, але я переживаю, що трапляється з Good Ideas, коли вони стають смугами. Побудуйте продукти, які рекламують «Гарну ідею», обіцяючи все, що вам потрібно зробити, - це отримати її , і ви потрапите в групу, не замислюючись надто ретельно про те, що це означає.

Що таке мова? Це словниковий запас і синтаксис, в якому значення можна передавати, правда? Кожного разу, коли ви оголошуєте змінну, пишете функцію, визначаєте клас, ви будуєте нову мову, додаючи іменники та дієслова до існуючої мови. Тепер ви можете сказати речі, які ви раніше не могли.

Я думаю, що для доменної мови визначається те, наскільки вона природно виражає психічні поняття, які передаються, і я думаю, що це є простим заходом. В основному, якщо є проста незалежна окрема вимога X, яка могла бути включена в програму чи ні, її правильна реалізація вимагає певного набору вставок коду, видалення та заміни коду. Y. Кількість N таких змін є мірою того, наскільки мова залежить від домену. Чим менше N, тим типові вимоги, тим краще.

Це не обов'язково залежить від фантазійного синтаксису, структур управління, передачі повідомлень чи того, що у вас є. Від чого це залежить, наскільки стисло він виконує вимогу. Багато інструментів будуть претендувати на це, але претензії не є актуальністю. Це має бути справжнім .

Іноді незвичайна технологія є необхідною. Ось мій улюблений приклад. Коли він є, це ілюструє те, що для його розуміння може знадобитися зусилля з боку програмістів. Таким чином, специфічність домену (і ремонтопридатність) - це зовсім не те саме, що читабельність .

Тож я погоджуюся з другим підходом, що гарна мова - це така, яка дозволяє легко будувати необхідні мови на ній. (Це мені сподобалось у Lisp.) Але ще важливіше - програмістам потрібно знати, як будувати мови, щоб відповідати доменам, у яких вони працюють, і бути готовими піднятися на криві вивчення таких мов.

Я насправді не бачу цього. Натомість вони застрягли в "програмах = алгоритми + структура даних", або "іменники стають класами, а дієслова стають методами" поворотними режимами мислення. Вони не працюють з точки зору того, як приймати домислиці та лінгвізувати їх для максимальної чіткості.

Це цілком підхід Рубі.

• Зберігайте основну мову простою та поширюйтесь через дорогоцінні камені
• Створіть діалекти Ruby для конкретних доменів за допомогою патч-мавп. ig Ruby on Rails.

Я не знаю, чи краще це, але я думаю, що це дуже прагматично.

LOP підхід надзвичайно практичний. Майте на увазі, що вам не обов’язково впроваджувати "мови сценаріїв" - методологія застосовна і для eDSL, і вони, як правило, ефективно складені. Я використовую цей підхід буквально у всій своїй роботі з розвитку.

У майбутньому ми побачимо набагато більше про мови, що стосуються домену, судячи з людей, які зараз про них говорять. Я помітив, що Мартін Фаулер теж багато говорив про них, і кілька цікавих статей через Lambda The Ultimate на цю тему, серед інших.

Це підказує мені, що це, безумовно, напрямок, у якому дме вітер щодо дизайну мови програмування та платформ програмування. Деяким чином це вже було деякий час - одна з переваг Ruby (як це вже було зафіксовано) полягає в тому, що це дозволяє легко створювати DSL, але насправді є багато наборів у програмах та бібліотеках програмування, які ми вже використовуємо.

Я використовую LOP кожного разу, коли програмую соло. Я виявив, що в деяких проектах немає іншого способу виконати графік. У простій алегорії можна прирівняти використання ЛОП до електроінструментів. Якщо ви працюєте наодинці в майстерні, ви не можете робити речі вручну та дотримуватися терміну. Якщо з вами є інші люди, координація використання цих електроінструментів є важливою для ефективності та безпеки.
У командному режимі ЛОП потребує організаційної підготовки, щоб уникнути катастрофи на Вавилонській вежі.