Языки, специфичные для домена, и библиотека функций

Ответ 1

• Ваша аудитория непрограммисты.
• Вы предназначенные для определенного поля.
• Они нужно выполнить работу.

Я бы выбрал DSL для языка общего назначения.

Ответ 2

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

Как и большинство вещей, это компромисс. DSL должен быть проще для вашей аудитории, но для вас может быть больше работы.

Ответ 3

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

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

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

Ответ 4

Я думаю, что это будет зависеть от написания языков DSL и функционального программирования, поскольку, по моему опыту, физики склонны быть достаточно компетентными в Fortan или Matlab.

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

Как упоминал Митч Пшеница, DSL хороши, когда вы хотите скрыть данные от пользователя.

Ответ 5

Я бы подумал, что цель DSL состоит в том, чтобы отвлечь детали и дать возможность программисту (или разработчику) быть продуктивным, так сказать, держать голову в домене.

Если вы хотите объяснить детали набора алгоритмов, я бы придерживался одного из обычных подозреваемых (С++?).

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

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

Ответ 6

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

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

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

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

То, что вам действительно понравилось бы в конце с DSL, - это то, где, скажем, 500-строчная программа может быть выражена как 50-100 строк вашего DSL, и это применимо для большинства "ожидаемых" алгоритмов. Я предполагаю, что это немного похоже на нормализацию в моделировании данных, где целью является удаление повторяющихся групп. Написание тех же 10-20 строк кода с небольшим изменением предлагает общую идиому.

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

Я бы подумал о библиотеке функций, как, например, набор математических функций, существующих в большинстве современных языков (sin, cos, square root и т.д.). Поэтому я предполагаю, что это сводится к:

• Пакеты кода → библиотека функций
• Общие идиомы → DSL

Ответ 7

Используйте psuedo-код для объяснения ваших алгоритмов. Это было бы более общим, чем использование языка программирования общего назначения с библиотечным API.

Насколько сложна ваша DSL-система? Потребуется ли для читателей многое узнать?

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

Ответ 8

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

Если вы используете DSL, готовы ли вы не только реализовать его, но и потратить большую часть своей жизни на сохранение? У вас есть ресурсы, выходящие за пределы собственно языка, и предоставляете инфраструктуру для того, чтобы она стала полезным инструментом разработки? Если он будет использоваться для реальной разработки, ему, вероятно, понадобится отладчик. Вы также можете рассмотреть либо новую IDE (если она действительно отличается), либо адаптировать существующий продукт для работы (например, создать специализированный режим для emacs или подключаемый модуль для Eclipse).

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