В чем разница между API и встроенным предметно-ориентированным языком (DSL)?
Это просто синтаксис?
Рассмотрим такой API, как OpenGL. Чем это отличается от графического DSL?
Другими словами, если API является достаточно сложным, можно ли считать его встроенным DSL?
Ответы:
Трудно провести различие и зависит от используемого языка. Это тоже субъективно.
В clojure вы можете определить API, которые выглядят как DSL. Например, hiccup позволяет генерировать html:
Это можно рассматривать как DSL с синтаксисом lisp. Тот факт, что это
htmlможет быть макрос, дает ему такую же мощность, как если бы вы писали HTML- шаблонную библиотеку с s-выражениями (см. Sxml )В Python тот же API может выглядеть так:
HTML это функция. Сначала будет оценен его аргумент, а затем произойдет вызов функции. Тот факт, что синтаксис python является более конкретным, а семантика python более строгим, означает, что это выражение труднее интерпретировать как DSL, независимый от языка.
Классическое представление языка - это древовидная структура данных и функция eval, вызываемая рекурсивно в его узлах. Языки LISP делают эту древовидную структуру очень очевидной, поэтому любой вызов вложенной функции неотличим от встроенной языковой функции. Вот почему сообщество LISP говорит о DSL практически для всего.
Я считаю, что программирование - это предоставление полезных абстракций. Я считаю, что рассмотрение всего, что вы создаете (библиотека или даже пользовательский интерфейс вашего приложения) как языковых элементов, помогающих людям решать сложные проблемы, является эффективным способом проектирования большинства вещей. С этой точки зрения я утверждаю, что все библиотеки являются DSL, но некоторые из них плохо спроектированы :-)
источник
API и DSL - это совершенно разные понятия, и есть только некоторые области, в которых они могут перекрываться.
Все DSL являются компьютерными языками . Они могут быть интерпретированными, скомпилированными, разметками, языками запросов (например, SQL) или (например, JSON или некоторые виды использования XML) языков данных, которые могут использоваться в сообщениях, передаваемых через API, но они должны быть языками . Термин описывает природу , а не цель.
API - это интерфейсы, позволяющие использовать один программный компонент другими компонентами. Термин описывает цель , а не природу. Например, API может быть набором объектных методов - это не DSL. Веб - API может использовать DSL (или, если это успокоительное, вы могли бы утверждать , что это DSL) , но общий домен конкретного языка не является частью определения. Программный драйвер для устройства может быть написан на C, API распространяется как скомпилированная библиотека, протокол полностью двоичный, и любой язык, который может использовать библиотеку, может быть использован для создания клиента. Ничто в этом API не может быть названо DSL (список символических имен для функций API не обрезает его).
Я немного озадачен тем, почему вы можете видеть только сходства, учитывая определения.
источник
В общем нет. DSL преднамеренно сделан необщим, чтобы сделать некоторые операции более удобными. Такие вещи, как HTML или логотип, изначально были языками, специфичными для предметной области.
В общем, вы не можете встроить DSL на другой язык даже с самым мощным API; что бы вы ни программировали для этого API, оно все равно будет выглядеть как серия выражений на языке хоста и будет не таким удобным, как использование языка специального назначения.
Исключениями являются языки, которые предоставляют исключительные возможности деформировать синтаксис через библиотеку (перегрузка операторов, например C ++, изобретение новых операторов, таких как Scala, или даже предварительное объявление совершенно другого синтаксиса чтения, такого как Perl, с фильтрами исходного кода). Когда вы используете такой язык и в полной мере используете гибкость, которую они предлагают, тогда результат может выглядеть скорее как новый, специализированный язык (но семантика часто будет немного отличаться от той, которую вы ожидаете, если бы язык был действительно изобретен). с нуля, чтобы служить вашим целям).
источник
Здесь от DslBoundary Мартина Фаулера
Из статьи я понимаю, что в основном встроенные DSL и API не так уж отличаются. Но, тем не менее, здесь есть небольшая разница.
Но если говорить о внешних DSL, то это будет другая история. Внешний DSL подобен небольшому языку программирования, но, безусловно, это не язык общего назначения, что означает, что он может решить не все проблемы, а конкретную проблему.
источник
Я думаю, что каждый API является встроенным DSL, но обратное утверждение неверно: не каждый встроенный DSL является API. Только когда язык используется как средство интеграции компонентов, его можно назвать API.
Почему API можно считать встроенным DSL? Прежде всего, он формирует язык: он имеет примитивные элементы (типы и операции), которые можно комбинировать (посредством основного языка) для формирования абстракций и решения сложных задач. Например, API OpenGL можно использовать для рендеринга 3D-сцен в режиме реального времени. API коллекций можно использовать для создания алгоритмов, которые работают с наборами объектов и т. Д. Во-вторых, он явно зависит от предметной области; например, домен API коллекций обрабатывает наборы объектов, а домен API OpenGL - 3D-рендеринг. Следовательно, API - это предметно-ориентированный язык.
Но не каждый DSL является API. Например, некоторые DSL не должны быть реализованы назначенным компонентом. Все системы определяют некоторые абстракции, и абстракции, которые имеют дело с какой-то конкретной областью, могут рассматриваться как DSL, но это не означает, что реализации этих абстракций должны быть «заменяемыми», другими словами, они не должны формировать API , Могли, но это не всегда необходимо. Однако в тех случаях, когда реализация является «компонентной» (извините за отсутствие лучшего термина), DSL действительно становится API.
источник