Когда целесообразно создавать свой собственный язык программирования?

Существуют ли типы приложений-убийц, классы алгоритмических задач и т. Д., Где в конечном итоге лучше создать свой собственный язык?

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

РЕДАКТИРОВАТЬ : Спасибо за ответы. Можете ли вы привести некоторые примеры, когда абсолютно необязательно создавать DSL или случаи, когда DSL может быть хорошей идеей?

Для человека, безусловно, уместно писать собственный язык в образовательных целях. Узнать о дизайне языка программирования и о дизайне компилятора. Но использование в реальном мире мало и далеко друг от друга.

При написании своего языка вы:

• Добавление огромной сложности к вашей проблеме
• Добавление значительного объема работы по написанию и поддержанию нового языка и компилятора

Таким образом, если вы планируете написать свой собственный язык для своего проекта, то функции, которые он предоставляет, не должны компенсировать затраты на других языках.

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

Позвольте мне процитировать Пола Вика, бывшего главного разработчика компилятора VB, который сейчас работает над проектом Oslo и языком M:

Сногсшибательно, невероятно сложно создать новый язык, даже тот, который в значительной степени основан на существующем. Тем не менее, многие программисты думают: «Эй, я использую языки, насколько это может быть сложно?» И продолжаю. ... вероятно, более 98% из них вообще не получают никакой поддержки, но, благослови Бог оптимистов, потому что без них мы никогда не получили бы 2% успешных языков. Лично я готов пожертвовать миллионами долларов и часов, потраченных впустую на языки, которые никогда не делают это просто ради того, чтобы мы могли получить такие языки, как C # и Java, Ruby и Python и так далее.

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

DSLs: определенно плохая идея!

Когда это разумно?

Когда тебе хочется!

Не слушайте этих людей, у которых есть странные комментарии, которые в основном говорят:

«Не делайте этого, потому что это слишком сложно, и язык 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 лет были адом для любого, кто имел несчастье работать на тупиковом языке.

Так что давай, создай свой собственный язык, но, пожалуйста, не проси кого-либо еще использовать его. Пожалуйста, не ожидайте, что кто-то еще поблагодарит вас за это.

Проектирование языков может быть веселым. Но вам не нужно ограничивать себя языками программирования.

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

Это вполне разумно, если сделать это, чтобы расширить свои навыки и учиться.

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

И вы тоже можете ошибаться в этом, но вам понадобится другой эксперт, чтобы убедить вас в этом (или показать, что вы не тот эксперт, которым себя считаете). Оживленная дискуссия, а не просто вопросы и ответы, как вы найдете здесь.

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

Это определенно зависит от ситуации. Как сказал Носкло: «Если у вас есть хорошая идея, новая концепция или что-то в этом роде, я настоятельно рекомендую вам это сделать.

В целом я бы предложил опираться на сложившуюся технологию.

Но если вы заинтересованы в создании своего собственного «языка», вы должны проверить: YACC & Lex

Вы можете просто не ловить себя в анти-паттерне «Воссоздание квадратного колеса».

Это означает, что вы воссоздаете то, что уже сделано, только хуже, чем оригинал (ы).

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

Когда создать свой собственный язык?

Когда вы хотите, как большой проект хобби.

Для предметно-ориентированного языка. Они могут быть довольно сложными; посмотрите, что происходит в сообществе Interactive Fiction (или текстовом приключении), проверив архив .

Когда ваши цели очень амбициозны, и вы думаете, что можете добиться реального прогресса, как проект Арка Пола Грэма .

Кроме того, на любом достаточно адаптируемом языке (возможно, C ++, определенно Common Lisp) в процессе разработки низкоуровневых конструкций.

Надеюсь, когда избежать этого, как вы, избегать клише, как избегать его, как чумы?

Когда это станет основой постоянного развития реальных проектов. Он всегда будет серьезно отставать от того, что коммерчески доступно для дешевых, и будет препятствовать дальнейшему развитию. Я работал в компании с собственной версией COBOL и никогда не хотел работать в другой компании, которая поддерживает свой язык. Мы наблюдали, как другие версии COBOL получают лучшие возможности и лучшие инструменты, в то время как мы застряли с теми же проблемами. (Я больше не хочу работать с COBOL, но это уже другая история.)

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

Моя точка зрения заключается в том, что DSL, как правило, являются «слабой идеей», и в долгосрочной перспективе более продуктивно использовать стандартный язык и строить специфичные для вашего домена потребности в качестве библиотеки «не-DSL».

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

В написании собственного языка программирования нет ничего плохого, если вы можете использовать существующие инструменты. В современном мире это будет означать, что вы либо определите его в синтаксисе, используемом для существующего языка (например, Java или C #), либо напишите небольшую систему преобразования (макроэкспандер), которая генерирует код на существующем языке.

Пройдя весь путь до машинного кода, заново изобретай МНОГО колес ...

Очень хорошая причина для DSL состоит в том, чтобы представить данные домена кратким способом. Это позволяет экспертам в области работать с данными напрямую, а не через других. Хитрость заключается в том, чтобы получить результирующие программы в простой для обработки форме.

Вообще говоря, ответ будет большим НЕТ. Из сотен языков обычно есть тот, который подойдет вашей проблеме.

Однако существуют обстоятельства, когда это рациональный вариант для развития нового языка:

• Когда один из ваших конкурентов теперь владеет одной из ваших основных платформ разработки. Я имею в виду текущую зависимость Googles от Java и их развитие "go", (это помогает, если у вас есть автор самого успешного языка из когда-либо заработных плат!).
• Когда вам нужно написать тонну кода для новой платформы, а существующие языки многословны и подвержены ошибкам - например, php для веб-разработки.
• Когда вы сталкиваетесь с проблемами масштабирования и параллелизма, с которыми никогда раньше не сталкивались, потому что никто никогда не имел такого большого количества оборудования для обработки такого большого количества данных раньше - например, Scala и (в определенной степени GO).

В чем хорош язык - это композиционность или соединение одних и тех же компонентов разными способами.

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

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

Помимо учебных упражнений, разумно создавать свой собственный язык программирования только тогда, когда вы понимаете другие языки, свою конкретную проблемную область и то, как существующие языки решают эту проблемную область, и это понимание достаточно основательно, чтобы вы знали, что новый язык является разумным Решение без необходимости задавать вопрос.

В последний раз, когда я собирался сделать это в хобби-проекте, я начал задавать, как должен выглядеть синтаксис, и понял, что частично я заново изобретал пролог. Другими языками, которые могут подойти, когда вы думаете, что вам нужно изобрести язык, являются lisp, lua или что-то вроде Haskell. В основном, все эти языки вы игнорировали в колледже, потому что думали, что они никогда не будут полезны.

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

Том Ван Кутсем недавно написал эссе-ответ на этот вопрос:

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

Краткое описание пули (с этой страницы):

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

Наверное, никогда.

Lua - лучший выбор, который вы можете получить, если вы хотите встроить язык практически в любой другой язык.

В настоящее время используются специальные языки для небольших доменов, и это имеет смысл в некоторых приложениях.

Кроме того, причины в основном академические.

Создание языка, когда он не нужен, действительно плохая вещь из-за сложности, связанной с его разработкой и поддержкой. Я видел много проектов, которые вводят какой-то язык сценариев, специфичный только для этой программы, и это было то, что сильно замедляло разработку базового элемента. Хорошими примерами являются, например, языки автоматизации, такие как Phantom, AutoHotKey, AutoIt. Эти инструменты были бы намного лучше IMO, если бы они использовали какой-нибудь известный язык, например Lua.

Ваше «редактирование», по-видимому, является существенно другим вопросом («когда я должен создать DSL?», А не первоначальным вопросом, который люди понимали как «когда я должен создать новый язык программирования общего назначения»). Кажется, что люди полностью ответили на «оригинальный» вопрос, но есть немного ответов, дающих конкретные критерии, когда использовать DSL. Поэтому я предлагаю контрольный список:

1. Ваша база пользователей больше, чем несколько человек, как правило, нетехнических и / или с ограниченным доступом к системе (следовательно, нецелесообразно ожидать, что они изучат / используют существующий язык общего назначения). Если это входит в вашу команду разработчиков или организацию программного обеспечения, вы можете вместо этого сказать «просто напишите сценарий».
2. Ваши пользователи должны использовать его достаточно часто, с достаточно разнообразным и изменяющимся поведением, необходимым (т.е. вы не можете просто предоставить фиксированную библиотеку функций, поддерживаемых вами)
3. Поведение, которое пользователи могут задавать, слишком сложно, чтобы указывать их как данные (например, вы не можете достичь этого, используя таблицу базы данных, или матрицу пользовательского ввода, или список задач, или коллекцию значений ключа ... потому что вы можете достичь много сложности с этим). Если вы можете добиться такого поведения, используя ввод данных или настройку вместо DSL, то, вероятно, вам следует это сделать, потому что это будет намного меньше работать. Некоторая условность, или сочетаемость / связывание воедино, или моделирование нескольких различных абстракций могут быть признаками того, что необходимое вам поведение слишком сложное для простых данных / конфигурации
4. Но поведение все еще достаточно ограничено, так что вы можете указать его в краткой DSL. Большая опасность - «раздувание платформы», например, если пользователи начинают запрашивать «можете ли вы просто добавить ...?». Если им нужно подключиться к Интернету, или читать и писать из файловой системы, или открывать и закрывать процессы - это больше не DSL. (Я видел, что это происходит на самом деле ... пользователям разрешено встраивать небольшие вызовы Python, постепенно переходя к сценариям Python и в конечном итоге разрушая любые ограничения / модульность / производительность)

Если все это верно, то DSL может быть уместным.

Существуют ли типы приложений-убийц, классы алгоритмических задач и т. Д., Где в конечном итоге лучше создать свой собственный язык?

По-разному.

Давайте возьмем наш мозг. Кажется, что это настолько сложный беспорядок, что мы сталкиваемся с границами с ЛЮБЫМ языком программирования (по крайней мере, сейчас). Поэтому, возможно, для виртуализации нашего мозга нам нужны другие подходы и, следовательно, другая семантика и синтаксис.

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