Практично ли языковое программирование?

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

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

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

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

Если он предлагает второе, я бы ответил: «Уже сделано!» и приведи Лисп в качестве примера. Как полагает Пол Грэм, языки, похоже, постоянно движутся к этому .

Что касается первого, я думаю, что это хорошая идея, если есть основной язык, который связывает их всех вместе. Это кажется мне слабым местом: общение между языками. Будете ли вы использовать вызовы, которые являются процедурной концепцией или передачей сообщений, которые напоминают мне о межпроцессном взаимодействии? Я бы приветствовал возможность работать с небольшими предметно-ориентированными языками, если их легко использовать одновременно. Будет ли этот подход (LOP) практичным?

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

Что такое язык? Это словарный запас и синтаксис, в котором значения могут быть переданы, верно? Каждый раз, когда вы объявляете переменную, пишете функцию, определяете класс, вы создаете новый язык, добавляя существительные и глаголы к существующему языку. Теперь вы можете сказать то, чего не могли раньше.

Я думаю, что делает язык специфичным для предметной области - это степень, в которой он естественным образом выражает ментальные концепции, которые передаются, и я думаю, что есть простая мера этого. По сути, если существует простое независимое автономное требование X, которое может быть включено в программу или нет, для его правильной реализации требуется некоторый набор вставок, удалений и замен кода. Y может отображаться простой разностный анализ до и после Y. Число N таких изменений является мерой того, насколько предметно-специфичен язык. Чем меньше N для типичных требований, тем лучше.

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

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

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

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

Это довольно подход Ruby.

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

Я не знаю, лучше ли это, но я думаю, это очень прагматично.

LOP подход чрезвычайно практичен. Имейте в виду, что вам не обязательно реализовывать «языки сценариев» - эта методология применима и к eDSL, и они обычно эффективно компилируются. Я использую этот подход буквально во всех моих разработках.

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

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

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