Существуют ли типы приложений-убийц, классы алгоритмических задач и т. Д., Где в конечном итоге лучше создать свой собственный язык?
PS: Просто чтобы быть уверенным, я имею в виду новый язык программирования и компилятор, а не новый компилятор для существующего языка.
РЕДАКТИРОВАТЬ : Спасибо за ответы. Можете ли вы привести некоторые примеры, когда абсолютно необязательно создавать DSL или случаи, когда DSL может быть хорошей идеей?
programming-languages
dsl
Даниэль Риковски
источник
источник
Ответы:
Для человека, безусловно, уместно писать собственный язык в образовательных целях. Узнать о дизайне языка программирования и о дизайне компилятора. Но использование в реальном мире мало и далеко друг от друга.
При написании своего языка вы:
Таким образом, если вы планируете написать свой собственный язык для своего проекта, то функции, которые он предоставляет, не должны компенсировать затраты на других языках.
Взять, к примеру, разработку игр. Им часто нужны мини-языки в играх или скриптовых языках. Они используют эти языки для написания огромного количества происходящих в игре событий. Однако даже в этом случае они почти всегда выбирают существующие языки сценариев и приспосабливают их к своим потребностям.
источник
Позвольте мне процитировать Пола Вика, бывшего главного разработчика компилятора VB, который сейчас работает над проектом Oslo и языком M:
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 состоит в том, чтобы представить данные домена кратким способом. Это позволяет экспертам в области работать с данными напрямую, а не через других. Хитрость заключается в том, чтобы получить результирующие программы в простой для обработки форме.
источник
Вообще говоря, ответ будет большим НЕТ. Из сотен языков обычно есть тот, который подойдет вашей проблеме.
Однако существуют обстоятельства, когда это рациональный вариант для развития нового языка:
источник
В чем хорош язык - это композиционность или соединение одних и тех же компонентов разными способами.
Если вашей проблеме с доменом просто нужно, чтобы вы установили несколько ортогональных переключателей, язык, вероятно, не добавляет много над формами, графическим интерфейсом пользователя или простым текстовым конфигом. файл. (Я предполагаю, что файл, полный пар «ключ-значение», совсем не то, что вы подразумеваете под «языком».)
OTOH, если ваша конфигурация похожа на реальный язык, например. глаголы и существительные могут быть соединены во множество различных (и новых) комбинаций любой степени сложности, и тогда язык станет почти неизбежным, потому что комбинаторный взрыв попытки указать, что вы хотите любым другим методом сокрушает.
источник
Помимо учебных упражнений, разумно создавать свой собственный язык программирования только тогда, когда вы понимаете другие языки, свою конкретную проблемную область и то, как существующие языки решают эту проблемную область, и это понимание достаточно основательно, чтобы вы знали, что новый язык является разумным Решение без необходимости задавать вопрос.
источник
В последний раз, когда я собирался сделать это в хобби-проекте, я начал задавать, как должен выглядеть синтаксис, и понял, что частично я заново изобретал пролог. Другими языками, которые могут подойти, когда вы думаете, что вам нужно изобрести язык, являются lisp, lua или что-то вроде Haskell. В основном, все эти языки вы игнорировали в колледже, потому что думали, что они никогда не будут полезны.
источник
Одна из причин для образовательных целей, как уже говорилось. Но есть и другие. Например, существует много исследований языков как
Sing#
на Singularity операционной системы иBitC
на Coyotos , которые были разработаны , потому что существующие языки не предлагают необходимые функции (для проверки экземпляра на уровне языка).источник
Том Ван Кутсем недавно написал эссе-ответ на этот вопрос:
http://soft.vub.ac.be/~tvcutsem/whypls.html
Краткое описание пули (с этой страницы):
источник
Наверное, никогда.
Lua - лучший выбор, который вы можете получить, если вы хотите встроить язык практически в любой другой язык.
В настоящее время используются специальные языки для небольших доменов, и это имеет смысл в некоторых приложениях.
Кроме того, причины в основном академические.
Создание языка, когда он не нужен, действительно плохая вещь из-за сложности, связанной с его разработкой и поддержкой. Я видел много проектов, которые вводят какой-то язык сценариев, специфичный только для этой программы, и это было то, что сильно замедляло разработку базового элемента. Хорошими примерами являются, например, языки автоматизации, такие как Phantom, AutoHotKey, AutoIt. Эти инструменты были бы намного лучше IMO, если бы они использовали какой-нибудь известный язык, например Lua.
источник
Ваше «редактирование», по-видимому, является существенно другим вопросом («когда я должен создать DSL?», А не первоначальным вопросом, который люди понимали как «когда я должен создать новый язык программирования общего назначения»). Кажется, что люди полностью ответили на «оригинальный» вопрос, но есть немного ответов, дающих конкретные критерии, когда использовать DSL. Поэтому я предлагаю контрольный список:
Если все это верно, то DSL может быть уместным.
источник
По-разному.
Давайте возьмем наш мозг. Кажется, что это настолько сложный беспорядок, что мы сталкиваемся с границами с ЛЮБЫМ языком программирования (по крайней мере, сейчас). Поэтому, возможно, для виртуализации нашего мозга нам нужны другие подходы и, следовательно, другая семантика и синтаксис.
Вообще говоря, есть еще такие сложные темы, которые могут привести к другим стратегиям, которые также включают «лучший» язык для данного сценария.
источник