Проблемно-ориентированные языки по сравнению с библиотекой функций

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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