Коли розумно створити власну мову програмування?

Чи існують типи вбивцьких програм, класи алгоритмічних проблем тощо, де краще, в перспективі, створити власну мову?

PS: Просто для впевненості, я маю на увазі нову мову програмування та компілятор, а не новий компілятор для існуючої мови.

EDIT : Дякую за відповіді. Чи можете ви навести кілька прикладів, коли створювати DSL або випадки, коли DSL може бути гарною ідеєю, абсолютно непотрібно?

Безумовно, актуально для людини писати власну мову в освітніх цілях. Щоб дізнатися про дизайн мови програмування та про дизайн компілятора. Але використання в реальному світі мало і далеко між ними.

Написавши свою власну мову, ви:

• Додавши величезну кількість складності до вашої проблеми
• Додавання значної роботи в написанні та підтримці нової мови та укладача

Отже, якщо ви плануєте написати власну мову для свого проекту, то функції, які він передбачає, що для інших мов не потрібно компенсувати вищезазначені витрати.

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

Дозвольте лише цитувати Пола Віка, колишнього головного розробника компілятора VB, який зараз працює над Project Oslo та мовою M:

Дуже складно побудувати нову мову, навіть таку, яка багато в чому заснована на існуючій. І все ж багато програмістів думають: "Ей, я використовую мови, наскільки це важко?" … Напевно, понад 98% з них взагалі не здобули жодної тяги, але Бог благословить оптимістів, оскільки без них ми ніколи не отримаємо 2% мов, які досягли успіху. Я особисто готовий пожертвувати мільйонами доларів і годин, що витрачаються на мови, які ніколи не роблять так, щоб ми могли отримати такі мови, як C # і Java, Ruby і Python тощо.

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

DSL: Безумовно, погана ідея!

Коли це розумно?

Коли ти відчуваєш, як це!

Не слухайте цих людей, які мають примхливі коментарі:

"Не робіть цього, тому що його занадто жорсткий і X-мова краще, ніж будь-яка мова, яку ви можете придумати".

Вся справа в тому, що створення DSL відбувається постійно. Рамка - це DSL. Макрос - це DSL. Кожен раз, коли ви пишете функцію для вашої програми, це частина DSL. Звичайно, це є в межах граматики, але лексика є частиною мови. Ось чому галузі часто створюють власну мову: її ефективніше!

Якби "не роби цього", було правильною відповіддю, ми всі писали б COBOL та Fortran.

Ви можете прочитати частини майбутньої книги DSL Мартіна Фаулера , якщо ви думаєте написати свою мову.

Я справді не можу придумати діловий випадок, щоб створити мову з нуля, крім того, що це надзвичайний досвід навчання.

Редагувати: для DSL існує багато ділових справ, але головне тут - не захоплюватися та зберігати просто.

Я пропоную ключові питання: "Яку проблему я намагаюся вирішити?" і "Хто отримує рентабельність інвестицій?"

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

Схоже, основною причиною того, що ви хочете отримати нову мову, є те, що ви починаєте виявляти в своєму коді зразки, якими існуючі мови не працюють добре. Але існує маса проблем зі створенням власної мови. Ви не будете бракувати всіх бібліотек та рамок, створених для існуючих мов. Ви витратите багато часу на розробку та реалізацію нової мови, яка весь час вам не доведеться витрачати на реальне завдання програмування. Ви витратите багато зусиль, переконуючи інших розробників у тому, що вони повинні використовувати вашу мову. І вам буде важко набирати та навчати нових розробників.

Чому б не написати мовою на зразок Lisp, що дозволяє розширити мову під час відкриття нових зразків? Тоді ви отримуєте всю силу нової мови з усіма перевагами усталеної мови.

Однією з причин може бути його створення в якості експерименту для вивчення мовного дизайну та побудови компілятора.

Іншою причиною може бути вбудованість мови сценаріїв у додаток, коли у вас немає можливості додавати сторонній API.

Я не думаю, що ти можеш запрограмувати без створення нової мови, тому добре усвідомити, що ти робиш, і зрозуміти проблеми.

• Що таке мова?
  Лексика, синтаксис та семантика.

Неповна мова, наприклад VB, Java, C # тощо, є лише базовою мовою. Як тільки ви додаєте до них класи, методи тощо, ви додали словниковий запас та семантику. Існує багато способів реалізації мов - розбір та переклад, розбір та інтерпретація, макроси над існуючою мовою, додавання класів та методів до існуючої мови.

• Що ви хочете робити мовою?
  Будьте добрі, щоб висловити проблеми стисло.

Звідки ви знаєте, чи зробили ви це? Я використовую міру - кількість редагувань . Якщо виникла вимога A в одному реченні, я переходжу до виконання вимоги в коді. Коли я закінчую і виймаю всі помилки, я перевіряю код, і сховище коду дає мені список змін, які я вніс, B. Чим менше B, тим краще мова. У середньому за простором реальних та можливих вимог цей показник підказує мені, якою є "доменна" мова.

• Чому лаконічність хороша?
  Тому що це мінімізує помилки.

Якщо для впровадження 1 вимоги потрібні зміни коду N, а ви іноді помиляєтеся, то кількість введених вад помилок приблизно пропорційна N. У межі, де N = 1, ввести помилку майже неможливо, не намагаючись.

Зауважимо, що це прямий виклик "роздуванню коду", який ми бачимо сьогодні.

ДОБАВЛЕНО: У відповідь на ваш запит для прикладу див. Виконання . Я не скажу, що це можна швидко зрозуміти, але це значно зменшує код інтерфейсу.

Використовувати слово у своєму (оригінальному) питанні завжди "можливо", але це не дуже часто корисно і дуже рідко оптимально, враховуючи велику кількість добре підтримуваних та зрілих мов та рамок, які існують.

Однак це цікавий інтелектуальний виклик.

Тільки якщо основним бізнесом вашої команди є мови програмування.

Я працював над мовою програмування, створеною у фінансовій компанії.

Зрозуміло, що для самого архітектора це було великим викликом і покращило власну майстерність.

Мова неминуче не могла зростати чи покращуватися в будь-якій близькості від швидкості, яка могла б зробити щось на зразок C # або Java - у них є команди, віддані цьому.

Мова незабаром застоюється, оскільки ніхто з нових не захотів взяти на себе завдання вдосконалити чужий проект для домашніх тварин.

Оригінальний архітектор пішов. Мова в’янула і померла через 10 років.

Ці 10 років були пеклом для всіх, хто мав нещастя працювати над глухою мовою.

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

Дизайн мов може бути цікавим. Але не потрібно обмежувати себе мовами програмування.

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

Це цілком розумно, якщо зробити це, щоб розширити свої навички та навчитися.

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

І ви також можете помилитися з цим, але вам знадобиться інший експерт, який переконає вас у цьому (або покаже вам, що ви не той експерт, якого ви думаєте). Була б жива дискусія, а не простий Q-і-A, як ви знайдете тут.

За винятком самоосвітніх цілей, я хочу стверджувати, що сьогодні немає необхідності створювати власну мову. За будь-яких обставин. Колись. Незалежно від того, що ви хочете зробити, існують вантажі наявних мов, які ви можете взяти / адаптувати під свої потреби.

Це остаточно залежить від ситуації. Як сказав nosklo - Якщо у вас є гарна ідея, абсолютно нова концепція чи щось подібне, я б дуже рекомендував вам це зробити.

Загалом я б запропонував покластися на усталені технології.

Але якщо ви зацікавлені у створенні власної "мови", вам слід перевірити: YACC & Lex

Можна, просто не впіймайтеся в анти-шаблоні "Відтворити квадратне колесо".

Це означає, що ви відтворюєте те, що вже було зроблено, лише бідніше, ніж оригінал.

Вутер був відомий тим, що створив нову мову для будь-якої нової ідеї. Ви можете черпати натхнення з його роботи: сторінка мови програмування Вутера .

Коли створити власну мову?

Коли хочеш, як великий проект хобі.

Для мови, що залежить від домену. Вони можуть бути досить детальними; подивіться, що відбувається в спільноті інтерактивних вигадок (або текстових пригод), переглянувши архів .

Коли ваші цілі дуже амбітні, і ви думаєте, що ви можете досягти справжнього прогресу, як проект Дуги Пола Грема .

Також будь-якою достатньо адаптованою мовою (можливо, C ++, безумовно, Common Lisp) у процесі розробки конструктів низького рівня.

Коли уникати цього, як ви, я сподіваюся, уникати кліше, як уникати його, як чуми?

Коли це має бути основою для постійного розвитку реальних проектів. Це завжди буде серйозно відставати від того, що продається дешево, і покалічить подальший розвиток. Я працював у компанії з власною версією COBOL і ніколи не хочу працювати в іншій компанії, яка підтримує свою мову. Ми спостерігали, як інші версії COBOL отримують кращі можливості та кращі інструменти, в той час як ми стикалися з тими ж проблемами. (Я не хочу більше працювати з COBOL ніколи, але це вже інша історія.)

Ситуації, в яких ви можете створити свою власну мову, не підпадають під це. Хобі-проекти не використовуються для реального розвитку. Щось на кшталт Arc вдасться (і отримає кілька реалізацій та подальшого розвитку та розвитку) або зазнає невдачі (і ніхто більше не буде цим користуватися). Невелика мова, що залежить від домену, є лише частиною проекту, і оскільки вона невелика, її можна вдосконалити з часом. Мова текстових пригод використовується для написання окремих ігор, і ці ігри, окрім хобі-проектів, майже ніколи не використовуються для подальшого розвитку.

Моя точка зору полягає в тому, що DSL - це, як правило, "слабка ідея", і в перспективі більш продуктивним є використання стандартної мови та побудова ваших доменних потреб як бібліотеки "не DSL".

Однак може виявитись, що ваші потреби є достатньо на замовлення, що для вашої компанії бажано мати DSL (а не лише трохи змінену реалізацію gcc або lisp). Багато компаній використовують вивільнення поточних мов, орієнтованих на те, що вони роблять, не пишучи / не підтримуючи власну мову. Наприклад, я чув, що PHP має гарне падіння; Lua розроблений таким чином, щоб бути вибудовувачем, ModelView використовує Python, а AutoCAD має AutoLISP в якості сценарію.

Немає нічого поганого в написанні власної мови програмування, якщо ви можете використовувати існуючі інструменти. У сучасному світі це означатиме, що ви або визначаєте його в синтаксисі, застосованому до існуючої мови (наприклад, Java або C #), або пишете невелику систему трансформації (макророзширювач), яка генерує код на існуючій мові.

Перехід до машинного коду - це вигадування багато колес ...

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

Взагалі відповідь буде великим "НІ". З сотень мов там зазвичай є одна, яка відповідає вашій проблемі.

Однак є обставини, коли є раціональним варіантом розробка нової мови: -

• Коли один із ваших конкурентів зараз володіє однією з ваших основних платформ розвитку. Я думаю про те, що Гуглс покладається на Яву та їх розвиток "йди", (це допомагає, якщо ти маєш автора найуспішнішої мови, що коли-небудь була на зарплаті!).
• Коли вам потрібно написати тонну коду для нової платформи, а існуючі мови є багатослівними та схильними до помилок - наприклад, php для веб-розробки.
• Коли ви стикаєтеся з проблемами масштабу та паралелізму, які раніше не зустрічалися, тому що ніхто ніколи не мав так багато обладнання, щоб обробити стільки даних раніше - наприклад, Scala та (певною мірою GO).

Яка мова гарна - це композиційність або поєднання одних і тих же компонентів по-різному.

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

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

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

Востаннє, коли я вирішив це зробити в хобі-проекті, я почав конкретизувати, як я хочу, щоб синтаксис виглядав і реалізовувався наскрізь, я винаходив пролог. Інші мови, які, можливо, добре підійдуть, коли ви думаєте, що вам потрібно вигадати мову, - це лайп, луа чи щось на зразок Haskell. В основному, всі ті мови, які ви ігнорували в коледжі, тому що ви думали, що вони ніколи не будуть корисними.

Одна з причин - як це вже було зазначено в освітніх цілях. Але є і більше. Наприклад, існує багато мов дослідження, як Sing#в операційній системі Singularity, так і BitCв Coyotos , які були розроблені, оскільки існуючі мови не пропонують необхідних функцій (наприклад, перевірка на мовному рівні).

Том Ван Кутсем недавно написав есе на цю саму запитання:

http://soft.vub.ac.be/~tvcutsem/whypls.html

Підсумок кулі (з цієї сторінки):

• Мова як синтаксичний механізм абстракції: зменшити повторюваний код "котлопластика", який не можна абстрагувати від використання вбудованих механізмів абстракції іншої мови.
• Мова як формувач думки: викликати зміну парадигми в тому, як слід структурувати програмне забезпечення (змінюючи "шлях найменшого опору").
• Мова як спрощувач: звести існуючу парадигму лише до її важливих частин, часто для підвищення розуміння та розуміння.
• Мова як правоохоронця: застосовувати важливі властивості або інваріанти, можливо, щоб полегшити висновок про більше корисних властивостей з програм.

Напевно, ніколи.

Луа - найкращий вибір, який ви можете отримати, якщо ви хочете вбудувати мову в будь-яку іншу мову.

Наразі доступ до мов малого доменного профілю, і це має сенс у деяких програмах.

Крім того, причини є переважно науковими.

Створення мови, коли вона не потрібна, насправді погана справа через складність, пов'язану з її розробкою та підтримкою. Я бачив багато проектів, які впроваджують якусь мову сценаріїв, специфічну лише для цієї програми, і саме ця велика кількість сповільнювала розвиток базової речі. Хорошими прикладами є, наприклад, мови автоматизації, такі як Phantom, AutoHotKey, AutoIt. Ці інструменти були б набагато кращими, якби вони використовували якийсь добре відомий провідний мов, наприклад, Lua.

Ваше "редагування" видається суттєво іншим питанням ("коли я повинен побудувати DSL?", А не оригінальним запитанням, яке люди розуміли як "коли я повинен будувати нову мову програмування загального призначення"). Здається, люди ґрунтовно відповіли на "оригінальне" запитання, але мало відповідей, що дають конкретні критерії, коли потрібно використовувати DSL. Тому я пропоную контрольний список:

1. Ваша база користувачів більше кількох людей, як правило, нетехнічна та / або з обмеженим доступом до системи (отже, нерозумно очікувати, що вони вивчать / використовувати існуючу мову загального призначення). Якщо це в межах вашої команди розробників чи програмної організації, ви можете замість цього сказати "просто написати сценарій".
2. Ваші користувачі повинні використовувати його досить часто, при цьому потрібна достатньо різноманітна і змінна поведінка (тобто ви не можете просто надати фіксовану бібліотеку функцій, що підтримуються вами)
3. Поведінка, яку можуть задати користувачі, є надто складною для визначення даних (наприклад, ви не можете досягти цього за допомогою таблиці баз даних, матриці введення користувачем, списку завдань або колекції ключових значень ... продумайте уважно тому що ти можеш досягти великої складності з цими). Якщо ви можете домогтися поведінки, використовуючи введення даних або конфігурацію замість DSL, ви, ймовірно, повинні, тому що це буде набагато менше роботи. Якась умовність, або комбінованість / зв'язування разом, або моделювання кількох різних абстракцій можуть бути ознаками того, що потрібна вам поведінка занадто складна для простих даних / конфігурації
4. Але поведінка все ще досить обмежена, що ви можете вказати її в стислій DSL. Великою небезпекою є "розкрій платформи", наприклад, якщо користувачі почнуть запитувати "ви можете просто додати ...?". Якщо їм потрібно підключитися до Інтернету, або читати і писати з файлової системи, або відкривати і закривати процеси - це вже не DSL. (Я бачив, що це відбувається для справжніх ... користувачам дозволяється вбудовувати невеликі дзвінки python, поступово переростаючи в сценарії python, і врешті руйнуючи будь-які обмеження / модульність / продуктивність)

Якщо все це вірно, DSL може бути доречним.

Чи існують типи вбивцьких програм, класи алгоритмічних проблем тощо, де краще, в перспективі, створити власну мову?

Це залежить.

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

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