कब एक एपीआई को एक एम्बेडेड डीएसएल माना जाता है?

Question

API और एम्बेडेड डोमेन विशिष्ट भाषा (DSL) में क्या अंतर है?

क्या यह सिर्फ वाक्यविन्यास है?

OpenGL जैसे API पर विचार करें। कैसे एक ग्राफिक्स DSL से अलग है?

दूसरे शब्दों में, अगर एक एपीआई पर्याप्त रूप से जटिल है, तो क्या इसे एक एम्बेडेड डीएसएल माना जा सकता है?

Comments

एक डीएसएल का उद्देश्य चीजों को सरल बनाना है। क्या आपको यह नहीं पूछना चाहिए कि क्या एक पर्याप्त सरल एपीआई को डीएसएल माना जा सकता है?

— डोभाल

मुझे लगता है कि मैं क्या जानना / समझना चाहता हूं कि एपीआई और डीएसएल कैसे विभेदित हैं। मैं वहां जटिल लगाता हूं क्योंकि मुझे लगता है कि जब कोई लगातार एक एपीआई पर कॉल कर रहा है तो यह डोमेन विशिष्ट है, या कम से कम यह है कि मैंने मूल रूप से इसके बारे में कैसे सोचा था।

— फेलोस्टैचिस

सवाल यह है कि एपीआई और एंबेडेड डीएसएल में क्या अंतर है ?

— प्रोक्योर

Answer 1

भेद करना कठिन है, और प्रयुक्त भाषा पर निर्भर है। यह व्यक्तिपरक भी है।

क्लोजर में, आप एपीआई को परिभाषित कर सकते हैं जो डीएसएल की तरह दिखते हैं। छूट के लिए, हिचकी आपको html उत्पन्न करने की अनुमति देती है:

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

इसे लिस्प सिंटैक्स के साथ डीएसएल माना जा सकता है। तथ्य यह है कि htmlएक मैक्रो हो सकता है यह शक्ति का एक ही देता है जैसे कि आप एक html लिख रहे थे एस-भाव के साथ काम करना (देखें sxml )

अजगर में, एक ही एपीआई की तरह लग सकता है:

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

html एक फंक्शन है। इसके तर्क का मूल्यांकन पहले किया जाएगा, और फिर फ़ंक्शन कॉल होगा। तथ्य यह है कि अजगर वाक्यविन्यास अधिक विशिष्ट है, और अजगर शब्दार्थ अधिक सख्त हैं इसका मतलब यह है कि इस अभिव्यक्ति को भाषा के DSL स्वतंत्र के रूप में व्याख्या करना कठिन है।

एक क्लासिक भाषा का प्रतिनिधित्व डेटा संरचना की तरह एक पेड़ है और इसके नोड्स पर पुनरावर्ती नामक एक विकसित कार्य है। LISP भाषाएँ इस पेड़ की संरचना को बहुत स्पष्ट बनाती हैं, इसलिए किसी भी नेस्टेड फ़ंक्शन कॉल अंतर्निहित भाषा सुविधा से अप्रभेद्य है। यही कारण है कि LISP समुदाय लगभग हर चीज के लिए DSLs के बारे में बात करता है।

मेरा मानना ​​है कि प्रोग्रामिंग उपयोगी सार प्रदान करने के बारे में है। मुझे लगता है कि आप जो कुछ भी बनाते हैं, वह एक जटिल समस्या को हल करने में लोगों की मदद करने वाले भाषा तत्वों के रूप में आपके द्वारा बनाई गई (एक देयता या यहां तक ​​कि यूआई) अधिकांश चीजों को डिजाइन करने का एक प्रभावी तरीका है। इस दृष्टिकोण के साथ, मैं यह दावा करता हूं कि प्रत्येक पुस्तकालय डीएसएल हैं, लेकिन उनमें से कुछ खराब तरीके से डिज़ाइन किए गए हैं :-)

Answer 2

एपीआई और डीएसएल काफी अलग अवधारणाएं हैं और केवल कुछ क्षेत्र हैं जहां उन्हें ओवरलैप करने के लिए कहा जा सकता है।

सभी डीएसएल कंप्यूटर भाषाएं हैं । इनकी व्याख्या, संकलित, मार्क-अप, क्वेरी लैंग्वेज (जैसे SQL) या (JSON या XML के कुछ उपयोग) डेटा भाषाओं में की जा सकती है, जो कि किसी API पर दिए गए संदेशों में उपयोग की जा सकती हैं, लेकिन वे भाषाएं होनी चाहिए । शब्द प्रकृति का वर्णन करता है , उद्देश्य का नहीं।

एपीआई एक इंटरफेस है जो एक सॉफ्टवेयर घटक को अन्य घटकों द्वारा उपयोग करने की अनुमति देता है। शब्द उद्देश्य का वर्णन करता है , प्रकृति का नहीं। उदाहरण के लिए, एक एपीआई ऑब्जेक्ट विधियों का एक सेट हो सकता है - जो कि डीएसएल नहीं है। एक वेब एपीआई एक डीएसएल उपयोग कर सकते हैं (या, अगर यह आरामदायक है, तो आप तर्क कर सकता है कि यह है एक डीएसएल) लेकिन एक साझा, डोमेन विशिष्ट भाषा परिभाषा का हिस्सा नहीं है। एक डिवाइस के लिए एक सॉफ्टवेयर ड्राइवर सी में लिखा जा सकता है, एपीआई एक संकलित पुस्तकालय के रूप में वितरित किया जाता है, प्रोटोकॉल पूरी तरह से द्विआधारी और किसी भी भाषा जो पुस्तकालय का उपयोग कर सकता है ग्राहक बनाने के लिए उपयोग किया जा सकता है। उस एपीआई में कुछ भी डीएसएल नहीं कहा जा सकता है (एपीआई कार्यों के लिए प्रतीकात्मक नामों की सूची में कटौती नहीं होती है)।

मैं थोड़ा भ्रमित हूं कि आप केवल समानताओं को क्यों देख सकते हैं, परिभाषाएं दी गई हैं।

Comments

जैसा कि एक टिप्पणीकार ने बताया, मुझे केवल एम्बेडेड डीएसएल पर विचार करना चाहिए था। फोर्थ की तरह कुछ पर विचार करें जहां एक शब्द का एक शब्दकोश बनाता है। मैंने पढ़ा है कि एक डीएसएल के निर्माण के रूप में एक के पास एक सुविधा पूर्ण अनुप्रयोग होने के करीब हो जाता है, लेकिन यह एपीआई की तरह लगता है।

— फीलोस्टैचिस

जो वास्तव में मेरे उत्तर को प्रभावित नहीं करता है। अगर यह एक भाषा है, अपने स्वयं के वाक्यविन्यास आदि के साथ, यह एक डीएसएल है। एक जटिल इंटरफ़ेस जिसमें उन भाषा सुविधाओं का अभाव है, वह डीएसएल नहीं है। आपको शायद अपने प्रश्न को अपडेट करना चाहिए और मैं अपने उत्तर को अपडेट करने पर विचार करूंगा।

— इसका जुलुस

एक उप भाषा अभी भी एक भाषा है। इसका अपना "सिंटैक्स" होना आवश्यक नहीं है, यह मेजबान भाषा से इसे "उधार" ले सकता है।

— प्रोफ़ेसर

तो जब वे बस के बारे में कर रहे हैं (यानी सामान्य प्रोग्रामिंग भाषाओं अंततः DSLs हैं) तो सभी अपने स्वयं के DSL प्रोजेक्ट नहीं कर रहे हैं? सामान्य से डोमेन विशिष्ट प्रकार की एक निरंतरता।

— फीलोस्टैचिस

Answer 3

सामान्य तौर पर, नहीं। कुछ कार्यों को अधिक सुविधाजनक बनाने के उद्देश्य से एक डीएसएल को जानबूझकर गैर-सामान्य बनाया जाता है । HTML या Logo जैसी चीजें मूल रूप से डोमेन-विशिष्ट भाषाएं थीं।

सामान्य तौर पर, आप सबसे शक्तिशाली एपीआई के साथ भी एक डीएसएल को दूसरी भाषा में एम्बेड नहीं कर सकते हैं; जो भी आप उस API के खिलाफ प्रोग्राम करते हैं, वह अभी भी होस्ट भाषा में अभिव्यक्तियों की एक श्रृंखला की तरह दिखाई देगा और एक विशेष उद्देश्य वाली भाषा का उपयोग करने के लिए उतना सुविधाजनक नहीं होगा।

अपवाद वे भाषाएं हैं जो एक लाइब्रेरी के माध्यम से वाक्य रचना को संचालित करने के लिए असाधारण अवसर प्रदान करती हैं (ऑपरेटर सी + + की तरह ओवरलोडिंग, स्कैला जैसे नए ऑपरेटरों का आविष्कार करना, या यहां तक ​​कि स्रोत फिल्टर के साथ पर्ल की तरह पूरी तरह से अलग रीड सिंटैक्स की भविष्यवाणी करना)। जब आप ऐसी भाषा का उपयोग करते हैं और उनके द्वारा दिए जाने वाले लचीलेपन का पूरा फायदा उठाते हैं, तो परिणाम एक नई, विशेष उद्देश्य वाली भाषा की तरह दिख सकता है (लेकिन शब्दार्थ अक्सर उस से बहुत अलग होगा जो आप उम्मीद करेंगे कि क्या वास्तव में भाषा का आविष्कार किया गया था अपने सिरों की सेवा के लिए जमीन से)।

Comments

तो शायद कोई ऐसा काम कर सकता है जो एक स्ट्रिंग (डीएसएल) को पार करता है जो एक बड़े एपीआई के लिए एक साधारण आवरण के रूप में कार्य करता है। मैं इस बात से डीएसएल के पृथक्करण को मानता हूं कि डीएसएल को अलग करना अलग बात है।

— फेलोस्टैचिस

हां, जिसे "इंटरप्रेटर" डिज़ाइन पैटर्न कहा जाता है, और यह अच्छा अभ्यास माना जाता है: आप दुभाषिया कोड को एक बार लिखते हैं, और उसके बाद से आप अपने डोमेन-विशिष्ट सामग्री को बहुत आसान व्यक्त कर सकते हैं।

— किलन फ़ॉथ

"ग्रूवी जैसे नए ऑपरेटरों का आविष्कार करना" शायद आपका मतलब स्काला था; ग्रूवी में ऑपरेटर सेट को ठीक किया गया है लेकिन इसे C ++ की तरह ओवरलोड किया जा सकता है।

— वोर्ग वान गीर सेप

@VorgvanGeir क्षमा करें, ठीक किया गया।

— किलन फ़ॉथ

Answer 4

इधर, मार्टिन फॉलर द्वारा DslBoundary से

लेख से, मेरी समझ मूल रूप से डीएसएल एम्बेडेड है और एपीआई इतने अंतर नहीं हैं। लेकिन फिर भी, यहाँ थोड़ा अंतर है।

1. एपीआई एक नई सुविधा प्रदान करने पर जोर देती है।
2. DSL आपको न केवल एक नई सुविधा प्रदान करता है बल्कि आपको एक नया वाक्यविन्यास और कोडिंग का नया तरीका भी प्रदान करता है।

लेकिन अगर बाहरी DSL की बात करें तो यह एक और कहानी होगी। बाहरी DSL एक छोटी प्रोग्रामिंग भाषा की तरह है, लेकिन निश्चित रूप से, यह एक सामान्य उद्देश्य वाली भाषा नहीं है, जिसका अर्थ है कि यह सभी समस्याओं को हल नहीं कर सकती है बल्कि विशिष्ट समस्या को हल कर सकती है।

Answer 5

मुझे लगता है कि हर एपीआई एक एम्बेडेड डीएसएल है, लेकिन इसका कायल सही नहीं है: हर एम्बेडेड डीएसएल एक एपीआई नहीं है। केवल जब भाषा का उपयोग घटकों को एकीकृत करने के साधन के रूप में किया जाता है तो इसे एपीआई कहा जा सकता है।

एपीआई को एम्बेडेड डीएसएल क्यों माना जा सकता है? सबसे पहले, यह एक भाषा बनाता है: इसमें आदिम तत्व (प्रकार और संचालन) होते हैं जिन्हें संयुक्त किया जा सकता है (मेजबान भाषा के माध्यम से) सार बनाने और जटिल समस्याओं को हल करने के लिए। उदाहरण के लिए, ओपनजीएल एपीआई का उपयोग वास्तविक समय में 3 डी-दृश्यों को प्रस्तुत करने के लिए किया जा सकता है। संग्रह API का उपयोग एल्गोरिदम बनाने के लिए किया जा सकता है जो वस्तुओं के सेट आदि पर काम करते हैं। दूसरा, यह स्पष्ट रूप से डोमेन विशिष्ट है; उदाहरण के लिए, कलेक्शंस API का डोमेन ऑब्जेक्ट्स के सेट को हैंडल कर रहा है, और OpenGL API का डोमेन 3D रेंडरिंग है। इसलिए एक एपीआई एक डोमेन विशिष्ट भाषा है।

लेकिन हर DSL एक API नहीं है। उदाहरण के लिए, कुछ डीएसएल को एक निर्दिष्ट घटक द्वारा लागू नहीं किया जाना है। सभी प्रणालियां कुछ अमूर्तताओं को परिभाषित करती हैं, और कुछ विशिष्ट डोमेन के साथ व्यवहार करने वाले अमूर्त को एक डीएसएल माना जा सकता है, लेकिन इसका मतलब यह नहीं है कि इन अमूर्त का कार्यान्वयन "स्वैपेबल" होना चाहिए, दूसरे शब्दों में, उन्हें एपीआई बनाने की आवश्यकता नहीं है। । वे कर सकते थे, लेकिन यह हमेशा आवश्यक नहीं है। हालांकि, ऐसे मामलों में जब कार्यान्वयन "कलपुर्जे" (एक बेहतर अवधि की कमी के लिए खेद है), डीएसएल वास्तव में एक एपीआई बन जाता है।

Comments

क्या यह केवल आपकी राय है या आप इसे किसी तरह वापस कर सकते हैं?

— गनत

@gnat मैंने अपनी बात को और स्पष्ट करने के लिए अपना उत्तर बढ़ाया।

— २०:०४ पर पूर्ववर्ती ज़ूल