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

49

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

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

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

Даниэль Риковски
источник
8
Я считаю, что нужно создать DSL для каждой проблемы.
SK-logic
4
Разве это не то, для чего LISP отлично подходит?
Darknight
1
@Darknight, не обязательно Lisp - любой язык с приличными возможностями метапрограммирования в порядке.
SK-logic
2
Когда у вас есть желание узнать о внутренностях компилятора.
dan_waterworth
1
Когда вы думаете, это будет весело или познавательно. Разработка нового языка, для которого нужен собственный компилятор, никогда не служит какой-либо полезной цели, учитывая количество прилагаемых усилий. (Есть, конечно, люди, которые достаточно умны, образованы и имеют опыт, чтобы знать, когда игнорировать мой совет.)
Дэвид Торнли

Ответы:

40

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

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

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

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

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

Simucal
источник
13
Я должен упомянуть, что в «Прагматичном программисте» написание небольших, специфичных для предметной области языков для помощи в выполнении задачи невероятно полезно и поощряется. Я бы не рекомендовал писать полноценный язык общего назначения, но метаязык, который генерирует код, иногда может быть полезен.
Джордан Пармер
5
Это ложь. Написание языка не добавляет сложности - обычно это значительно уменьшает сложность. В любом случае, реализация компилятора и его поддержка - крошечная часть работы.
SK-logic
3
@ SK-logic, «В любом случае, реализация компилятора и его поддержка - крошечная часть работы». Ты пробовала? Для какого процессора?
2
@ Thorbjørn Ravn Andersen, я делаю это для жизни. В настоящее время вам не нужно ориентироваться на какой-либо конкретный процессор напрямую - поскольку есть отличные виртуальные машины, такие как LLVM, .NET и даже JVM. И если вы не собираетесь делать слишком много дорогостоящих оптимизаций, даже нацеливание на «реальный» процессор не имеет большого значения - посмотрите компилятор OCaml для примера такого примитивистского подхода.
SK-logic
8
@ Thorbjørn Ravn Andersen по определению переводчик переводит с одного языка на другой. Уровень этого целевого языка ничего не значит. И никто из здравомыслящих не будет реализовывать полностью оптимизирующий бэкэнд компилятора для DSL - лучше использовать уже существующий. На самом деле, большинство современных DSL скомпилированы в C. Что касается ассемблера и компоновщика - их всегда считали отделенными от компиляции, с самых первых дней системного программирования.
SK-logic
24

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

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

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

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

Конрад Рудольф
источник
8
VB! = VBA. Кстати, законно ли критиковать VBA на этом сайте? В конце концов, Джоэл помог развить это, верно?
Конрад Рудольф
1
Хотя прагматичный программист был такой хорошей книгой, рекомендации DSL в этой книге были просто глупы. Так же, как они рекомендовали изучать новый язык каждый год, ИМХО, это тоже довольно глупо.
доктор злой
2
Я только что отредактировал ваш ответ, чтобы снова указывать на статью Пола Вика, а не на кеш Google. В 2011 году он «перезагрузил свой блог» и удалил весь контент VB, но в 2012 году он вернул его обратно, хотя и с разными URL-адресами. Похоже, ему лично было тяжело, когда он удалял эти вещи.
MarkJ
2
@MarkJ Большое спасибо. И ничего себе, что статья не не делает для приятного чтения. Надеюсь, сейчас ему лучше.
Конрад Рудольф
2
Спасибо за добрые комментарии, сейчас я работаю над JavaScript и, да, все немного лучше. :-) Не уверен, почему оригинальная ссылка не работает, я попытался заставить работать все старые стили ссылок, я посмотрю на это.
Panopticoncentral
23

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

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

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

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

Дело в том, что создание DSL происходит постоянно. Фреймворк - это DSL. Макрос это DSL. Каждый раз, когда вы пишете функцию для своей программы, это является частью DSL. Конечно, это в пределах грамматики, но словарь является частью языка. Вот почему отрасли часто создают свой собственный народный язык: это более эффективно!

Если бы «не делай этого» было правильным ответом, мы все писали бы на языке COBOL и Fortran.

неизвестный
источник
3
В самом деле? Я считаю, что фреймворки, макросы и функции - это вещи, которые помогают языку поддерживать независимость от домена.
CurtainDog
3
@CurtainDog, он становится частью языка, только если он является частью стандартной библиотеки. В противном случае это «диалект» языка.
9

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

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

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

Ruben Steins
источник
7

Я полагаю, что ключевые вопросы: «Какую проблему я пытаюсь решить?» и "Кто получает рентабельность инвестиций?"

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

joel.neely
источник
7

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

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

Клинт Миллер
источник
6

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

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

Себастьян Дитц
источник
6

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

  • Что такое язык?
    Словарь, синтаксис и семантика.

Готовый язык, такой как VB, Java, C # и т. Д., Является просто базовым языком. Как только вы добавляете в него классы, методы и т. Д., Вы добавляете словарь и семантику. Существует много способов реализации языков - синтаксический анализ и перевод, синтаксический анализ и интерпретация, макросы поверх существующего языка, добавление классов и методов к существующему языку.

  • Какой язык вы хотите сделать?
    Будьте хороши для краткого изложения проблем.

Как вы знаете, если вы сделали это? Мера, которую я использую, является счетчиком редактирования . Если требование A состоит из одного предложения, я перехожу к реализации этого требования в коде. Когда я закончу и вытащу все ошибки, я проверю код, и репозиторий кода выдаст мне список изменений, которые я сделал, B. Чем меньше B, тем лучше язык. Усредненный по пространству реальных и возможных требований, эта мера говорит мне, насколько «специфичен для предметной области» язык.

  • Почему краткость хороша?
    Потому что это сводит к минимуму ошибки.

Если для реализации требования 1 требуется N изменений кода, а вы иногда допускаете ошибки, то количество ошибок, которые вы вводите, примерно пропорционально N. В пределе, где N = 1, почти невозможно ввести ошибку без попытки.

Обратите внимание, что это прямой вызов «раздутию кода», которое мы наблюдаем в настоящее время.

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

оборота Майк Данлавей
источник
Если бы существовали требования из одного предложения, мы бы все писали на английском. Как и любой человеческий язык, код требует много шаблонов, чтобы иметь какое-либо значение.
CurtainDog
@Dog: с точки зрения ИИ, это было бы идеально. Посмотрите на дифференциальное исполнение. Это реальный пример сокращения исходного кода на порядок. Котел может быть необходим, но это не очень хорошая вещь.
Майк Данлавей,
5

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

Однако это интересный интеллектуальный вызов.

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

Только если основной деятельностью вашей команды являются языки программирования.

Я работал над языком программирования, который был создан в финансовой компании.

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

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

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

Первоначальный архитектор ушел. Язык засох и умер через 10 лет.

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

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

Джо Р
источник
1
Интересный пример ... можно ли избежать такой стагнации, ориентируясь на язык, скажем, на платформы Java или .NET. Таким образом, язык может «расти» по мере добавления в базовые библиотеки.
CurtainDog
2
Я не уверен, почему вы бы создали язык, нацеленный на другой язык, такой как Java. Почему бы просто не использовать Java или C # для начала?
4

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

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

Тун Крижте
источник
4

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

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

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

Адам Беллер
источник
4

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

JesperE
источник
Ваша претензия чрезвычайно спорна и звучит для меня как напыщенная речь.
SK-logic
Сегодня существует несколько платформ для создания ваших собственных настроенных DSL, которые я на самом деле не освещаю, что я пытался сказать (это было 2 года назад). Вероятно, мне следует переформулировать это, поскольку «внедрение нового языка общего назначения с нуля на практике никогда не является правильным путем». :)
JesperE
хорошо, это дополнение "общего назначения" меняет все. Но я не верю в языки «общего назначения» - ни один из них не является достаточно общим, поэтому все еще есть много места для новых «несколько общих» языков (которые на самом деле являются DSL).
SK-logic
3

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

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

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

Крис
источник
3

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

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

Синтаксис
источник
Если бы колеса не были воссозданы, мы могли бы по-прежнему использовать каменные колеса. Рок это детка
Вонг Цзя Хау
3

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

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

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

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

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

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

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

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

Дэвид Торнли
источник
3

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

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

Пол Натан
источник
3

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

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

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

user1249
источник
3

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

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

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

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

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

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

Interstar
источник
1

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

Дейв Шерохман
источник
1

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

Карл Билефельдт
источник
Я обычно использую более десятка самых разных языков. Включая Пролог, различные Лиспы и Хаскелл. Но, тем не менее, я склонен решать практически любую проблему, внедряя для этого DSL. И что DSL достаточно специфичны, чтобы быть далеко от любого из существующих языков - они больше похожи на смесь крошечных частей разных языков.
SK-logic
1

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

sakisk
источник
1

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

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

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

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

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

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

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

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

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

majkinetor
источник
Луа слабоумный. Но, с другой стороны, есть MetaLua с некоторыми приличными возможностями метапрограммирования.
SK-logic
0

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

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

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

оборота user967543
источник
0

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

По-разному.

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

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

Фабиан Биглер
источник