Коли API вважається вбудованим DSL?

У чому різниця між API і вбудованим мовою, що відповідає певним доменам (DSL)?

Це просто синтаксис?

Розглянемо API, як OpenGL. Як це відрізняється від графічного DSL?

Іншими словами, якщо API достатньо складний, чи можна його вважати вбудованим DSL?

8
Суть DSL полягає в спрощенні речей. Чи не слід запитувати, чи можна вважати достатньо простий API DSL?
додано Автор Doval, джерело
Я вважаю, що я хочу знати/розуміти, як API і DSL диференційовані. Я поставив комплекс в тому, що я вважаю, що коли людина постійно робить дзвінки в API, то це досить специфічно домен, або принаймні, як я спочатку думав про це.
додано Автор VassiaAlk, джерело
Питання в тому, яка різниця між API і Вбудованим DSL ?
додано Автор proskor, джерело

5 Відповіді

Важко розрізняти та залежати від використовуваної мови. Це також суб'єктивно.

У clojure можна визначити API, які виглядають як DSL. Наприклад, hiccup дозволяє генерувати html:

(html [:span {:class "foo"} "bar"])

Це може розглядатися як DSL з великим синтаксисом. Той факт, що html може бути макросом, дає йому те ж саме, що ви пишете html шаблонизирующий lib з s-expressions (див. sxml )

У python такий самий API може виглядати так:

html(["span", {"class" : "foo"}, "bar"])

html - функція. Його аргумент буде оцінюватися спочатку, а потім відбудеться виклик функції. Той факт, що синтаксис пітона є більш конкретним, а семантика пітона є більш суворим, означає, що цей вираз важче інтерпретувати як DSL незалежно від мови.

Класичне мовне представлення - це деревоподібна структура даних і функція eval, яка рекурсивно викликається на своїх вузлах. Мови LISP роблять цю структуру дерева дуже очевидною, тому будь-який виклик вкладеної функції не відрізняється від вбудованої мовної функції. Саме тому спільнота LISP говорить про DSL для майже всього.

Я вважаю, що програмування йде про надання корисних абстракцій. Я вважаю, що, дивлячись на все, що ви будуєте (бібліотека або навіть інтерфейс вашої програми) як мовні елементи, які допомагають людям вирішувати складну проблему, це ефективний спосіб розробки більшості речей. З цієї точки зору, я стверджую, що кожна бібліотека є DSL, але деякі з них погано розроблені :-)

7
додано

API та DSL є зовсім різними поняттями, і існують лише деякі області, в яких їх можна перекривати.

Усі DSL є мовами комп'ютера. Вони можуть інтерпретуватися, компілюватися, розмічуватися, мовами запитів (наприклад, SQL) або (наприклад, JSON або деяким використанням XML) мовами даних, які можуть використовуватися в повідомленнях, переданих через API, але вони повинні бути мовами . Термін описує природу , а не мету.

API - це інтерфейси, що дозволяють використовувати один компонент програмного забезпечення іншими компонентами. Термін описує мету , а не природу. API може бути набором об'єктних методів, наприклад - це не DSL. Веб-API може використовувати DSL (або, якщо це корисно, можна стверджувати, що це є DSL), але спільний, специфічний для домену мова не є частиною цього визначення. Драйвер програмного забезпечення для пристрою може бути написаний на С, API, що поширюється як складена бібліотека, протокол повністю двійковий і будь-яка мова, яка може використовувати бібліотеку, може використовуватися для створення клієнта. Ніщо в цьому API не можна назвати DSL (список символічних імен для функцій API не вирізає його).

Я трохи заплутався, чому можна бачити лише подібності, враховуючи визначення.

4
додано
Що насправді не впливає на мою відповідь. Якщо це мова, з власним синтаксисом тощо, це DSL. Складний інтерфейс, якому не вистачає цих мовних функцій, не є DSL. Можливо, ви повинні оновити своє запитання, і я розгляну можливість оновити свою відповідь.
додано Автор Stella Biderman, джерело
Як зауважив коментатор, я, мабуть, розглядав лише вбудовані DSL. Розглянемо щось на зразок Forth, де створюється словник слів. Я читав, що, будучи DSL, як один наближається до того, що функція завершення програми, але здається багато, як API.
додано Автор VassiaAlk, джерело
Тож, чи не всі проекти мають власний DSL, коли вони робляться (наприклад, загальні мови програмування в кінцевому рахунку DSL)? Континуум від загального до домену.
додано Автор VassiaAlk, джерело
Підмовою все ще є мова. Не потрібно мати свій "власний" синтаксис, він може "запозичити" його з мови господаря.
додано Автор proskor, джерело

Загалом, немає. DSL навмисно зроблено не загальним для того, щоб зробити операції деякими більш зручними. Такі речі, як HTML або логотип, були спочатку мовами, що стосуються домену.

Загалом, ви не можете вбудувати DSL на іншу мову навіть з найпотужнішим API; що б ви не програмували з цим API, все одно буде виглядати як серія виразів на мові вузла і не буде такою зручною, як використання спеціальної мови.

Виняток становлять мови, які надають виняткові можливості деформувати синтаксис через бібліотеку (перевантаження оператора, як C ++, винайдення нових операторів, таких як Scala, або навіть попередня класифікація абсолютно іншого синтаксису читання, наприклад Perl з вихідними фільтрами). Коли ви користуєтеся такою мовою і в повній мірі використовуєте гнучкість, яку вони пропонують, результат може виглядати як новий, спеціальний мова (але семантика часто буде тонко відрізнятися від того, що ви очікували б, якщо мова була дійсно винайдений з нуля, щоб служити вашим кінцям).

4
додано
Так, це називається шаблоном дизайну "Інтерпретатор", і це вважається гарною практикою: ви пишете код інтерпретатора один раз, і з цього моменту ви можете набагато простіше висловити свій зміст конкретного домену.
додано Автор sigirisetti, джерело
@VorgvanGeir Вибачте, виправлено.
додано Автор sigirisetti, джерело
Таким чином, можливо, можна було б зробити те, що аналізує рядок (DSL), який діє як простий обгортка для великого API. Я вважаю, що розділення DSL від того, що розбирає DSL, є диференціацією.
додано Автор VassiaAlk, джерело
"винаходити нових операторів, як Groovy" Можливо, ви мали на увазі Scala; в Groovy набір операторів фіксований, але може бути перевантажений, як у C ++.
додано Автор Vorg van Geir, джерело

Тут, з DslBoundary від Martin Fowler

Зі статті я розумію, що в основному вбудовані DSL і API не є такою різницею. Але тут є трохи різниця.

  1. API emphasises on providing a new facility.
  2. DSL does not just provide you a new facility but provide you a new syntax and the new way to coding also.

Але якщо говорити про зовнішній DSL , це буде інша історія. Зовнішній DSL подібний до маленької мови програмування, але, звичайно, це не загальноприйнята мова, що означає, що вона не може вирішити всі проблеми, а конкретну проблему.

2
додано

Я думаю, що кожен API є вбудованим DSL, але зворотне не відповідає дійсності: не кожен вбудований DSL є API. Тільки тоді, коли мова використовується як засіб інтеграції компонентів, його можна назвати API.

Чому API може вважатися вбудованим DSL? Перш за все, вона формує мову: вона має примітивні елементи (типи і операції), які можуть бути об'єднані (за допомогою мови господаря) для формування абстракцій і вирішення складних задач. Наприклад, API OpenGL може використовуватися для відображення 3D-сцен у режимі реального часу. API Колекцій може використовуватися для створення алгоритмів, які працюють на множинах об'єктів і т.д. По-друге, воно є специфічним для домену; наприклад, домен API колекцій обробляє набори об'єктів, а домен API OpenGL - це 3D-рендеринг. Отже, API є мовою, що відповідає певній області.

Але не кожен DSL є API. Наприклад, деякі DSL не повинні бути реалізовані призначеним компонентом. Усі системи визначають деякі абстракції, а абстракції, які мають справу з певним доменом, можуть розглядатися як DSL, але це не означає, що реалізації цих абстракцій слід "замінювати", іншими словами, вони не повинні формувати API . Вони могли, але це не завжди необхідно. Однак у тих випадках, коли реалізація є "компонентною" (вибачте за відсутність кращого терміна), DSL дійсно стає API.

1
додано
це просто ваша думка, або ви можете якось підтримати її?
додано Автор gnat, джерело
@gnat Я розширив свою відповідь, щоб ще більше пояснити свою точку зору.
додано Автор proskor, джерело