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

12

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

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

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

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

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

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

Майкл К
источник
У этого, конечно, есть огромный умопомрачительный потенциал.
2
Мне не ясно, какую проблему решает эта парадигма. Кстати, LISP не является примером успешного языка.
Mouviciel
7
@mouviciel, это во многом зависит от того, что именно вы подразумеваете под «успешным». Используется ли он большинством программистов? Нет. Это было вокруг, в использовании, долгое время? Да - 50 лет и считается. У большинства современных языков украли из него целую кучу полезных функций? Да. (Могут ли языки украсть еще больше из языков Lisp? Да!)
Фрэнк Шеарар
2
Существует разница между широко используемым языком и полезным. Язык, который исследует новые области, как правило, не используется, но может способствовать всем в долгосрочной перспективе. С другой стороны, Java бесполезен, поскольку он не вносит ничего нового в таблицу (даже несмотря на то, что это определенно успешный язык для всех учетных записей).
Матье М.
1
Я бы посчитал более полезным освоить Lisp, чем освоить Cobol.
Гленатрон

Ответы:

8

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

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

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

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

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

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

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

Майк Данлавей
источник
Определенно согласен с вами в том, что касается побеждающей стороны на выборах - «босс с заостренными волосами знает, на каком языке он должен быть написан. [...] Java». Другой вопрос - то, что Джоэл называет «астронавтом архитектуры». Я также мог видеть, как DSL накладываются друг на друга, пока еще нет . Я предполагаю, что это сводится к программисту -> программисту -> ученому.
Майкл К
И если это не требует усилий, чтобы понять, скорее всего, это не стоит того :)
Michael K
4

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

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

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

Nerian
источник
7
RoR это не диалект Ruby.
back2dos
4
@ back2dos: я думал о метапрограммировании. Конечно, RoR - это не другой язык программирования. Под диалектом я подразумеваю, что даже если все, что находится под Rails, это Ruby, с точки зрения разработчика он использует Ruby на более высоком уровне абстракции. Домен Диалект. Он использует представления, модели, контроллеры и программирует их, используя синтаксис, напоминающий другой язык, так сказать диалект. В этом прелесть скриптового языка, такого мощного, как Ruby.
Nerian
Я думаю, что важно увидеть разницу. AspectJ - это диалект Java, тогда как AspectR - это просто библиотека Ruby. Разница действительно в языке. Ruby был разработан для обеспечения такой гибкости и выразительности, а Java - нет. Оба могут считаться языками общего назначения, разница в том, что Ruby, как правило, достаточно выразителен, чтобы исключить необходимость использования реального DSL для каких-либо общих целей, а Java - нет, даже если, например, вы обычно используете представления, модели и контроллеры.
back2dos
1

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

SK-логика
источник
Извините за мое невежество - eDSL может быть препроцессором для другого языка, верно?
Майкл К
@ Майкл, да, таким способом можно реализовать eDSL, см., Например, CamlP4. Но чаще eDSL строится на собственных функциях языка (например, макросы Lisp, шаблоны C ++ и т. Д.).
SK-logic
1

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

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

glenatron
источник
Вы можете добавить в FoF, который используется для разработки драйверов для многоядерной системы Barrelfish. Язык для разработки DSL в :)
Matthieu M.
0

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

Kakungulu
источник