मुझे डोमेन विशिष्ट भाषा का उपयोग कब करना चाहिए?

Question

मुझे कुछ व्यावहारिक मार्गदर्शन चाहिए जब मुझे Domain Specific Language का उपयोग करना चाहिए। मुझे फायदे और नुकसान के बारे में संसाधन मिल गए हैं, लेकिन किस तरह की परियोजना इसके उपयोग की गारंटी देगी?

ऐसा लगता है कि डीएसएल बनाने और बनाए रखने के लिए समय में एक बड़ा निवेश है, इसलिए मेरे समय के निवेश पर मुझे किस उत्पाद स्थान पर उत्पादकता वापसी मिल जाएगी?

संपादित करें: ऐसा लगता है कि डीएसएल का सबसे आम उपयोग स्थायी डेटा स्थिति के लिए फ़ाइल स्वरूपों के लिए है, प्रोग्राम तर्क और संरचना (शायद कोड पीढ़ी) के लिए डीएसएल का उपयोग करने के बारे में क्या है? यह व्यवहार्य कब है?

संपादित करें # 2 मैं मुख्य रूप से एक विशिष्ट डीएसएल सार्थक बनाने के बारे में पूछ रहा हूं। बेशक हमें समय बचाने के लिए जितना संभव हो सके मौजूदा डीएसएल का उपयोग करना चाहिए।

Answer 1

अभी तक एक और डीएसएल बनाने के बहुत कम अच्छे कारण हैं। दुनिया विशेष उद्देश्य वाली भाषाओं के साथ वसा है।

इन पंक्तियों के साथ सोचें।

1. सामान्य प्रयोजन भाषा जैसे पायथन, जावा, सी ++ के साथ समस्या हल करें .. जो कुछ भी हो।

2. सामान्य सुविधाओं को कारक बनाने और वास्तव में अच्छी, वास्तव में सुरुचिपूर्ण, वास्तव में विस्तारणीय कक्षा पुस्तकालय बनाने का समाधान अनुकूलित करें।

3. उस कक्षा पुस्तकालय को "ऑर्थोगोनैलिटी" पर जोर देने के लिए अनुकूलित करें। सुनिश्चित करें कि सभी सुविधाएं किसी भी समस्या के बिना अच्छी तरह से मिलकर काम करती हैं।

4. यदि आपको केवल वाक्यविन्यास के सरलीकरण की आवश्यकता है, तो अपनी अच्छी कक्षा पुस्तकालय के चारों ओर एक स्क्रिप्टिंग रैपर बनाएं। यह आपका डीएसएल है। पायथन के लिए, यह आसान है - यह पहले से ही एक गतिशील भाषा है। जावा के लिए, ऐसी चीजें हैं जिनका आप लाभ उठा सकते हैं। सी ++ के लिए यह लचीली पटकथा पर्यावरण बनाने के लिए थोड़ा सा काम हो सकता है।

5. यदि आपको अभी भी अधिक अनुकूलन की आवश्यकता है, तो अपने डीएसएल के लिए एक कंपाइलर लिखने पर विचार करें।

Answer 2

सबसे पहले

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

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

उदाहरण के लिए, यदि आपका व्यवसाय कर अनुप्रयोगों के निर्माण में गली है, तो कर प्रणाली डीएसएल बनाने का अच्छा विचार हो सकता है। यह आपकी भाषा को आपके विभिन्न कर अनुप्रयोगों में न केवल आपके द्वारा उपयोग करने योग्य होने की अनुमति देगा, बल्कि यह आपके उद्योग के अन्य व्यवसायों द्वारा विपणन योग्य (उपयोग योग्य) भी होगा जो आप पूरा कर रहे हैं।

बेशक, आपको पहले से मौजूद भाषा के शीर्ष पर एक ढांचा बनाम एक डीएसएल बनाने की लागत/लाभों का भार उठाना होगा।

Answer 3

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

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

मुझे यूआईएल विशेष रूप से जीयूआई विकास के लिए एक बड़ा लाभ मिलता है क्योंकि एक यूआईएल कंपाइलर जीयूआई विनिर्देश में त्रुटियों को पा सकता है जो कि सी ++ कंपिल्टर को सामान्य सामान्य संकलित कोड जैसा दिखता है। तथ्य यह है कि यह अच्छी तरह से समर्थित है इसका मतलब है कि प्लेटफार्मों और यहां तक ​​कि जीयूआई बिल्डरों के बीच कोड बंद करना आसान है।

Answer 4

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

उदाहरण के लिए एक कार असेंबली "हाथ" लेता है, विभिन्न फैक्ट्री कॉन्फ़िगरेशन का समर्थन करने के लिए कॉन्फ़िगरेशन मॉडल प्रदान करना असंभव होगा। (इसका पता लगाएं, ऐसा न करें, जब ऐसा होता है ... आदि)

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

एक असली दुनिया उदाहरण जो दिमाग में आता है वह है याहू पाइप्स (आप इसे डीएसएल के रूप में सोच सकते हैं) या उदाहरण के लिए स्वचालित वेब क्रॉलर के लिए robots.txt निर्देश। वे एक पूर्ण उड़ाए गए डीएसएल नहीं हो सकते हैं लेकिन वे दिखाते हैं कि डीएसएल उपयोगी हो सकता है।

Answer 5

एसीएम कंप्यूटिंग सर्वेक्षण लेख When and How to Develop Domain-Specific Languages मार्टिन फाउलर की 2010 की पुस्तक Domain-Specific Languages जैसा ही इस विषय पर सलाह प्रदान करता है।

लिस्प किसी भी डोमेन के लिए डोमेन विशिष्ट भाषा के रूप में कुछ लोगों द्वारा माना जाता है:

Answer 6

ठीक है, किसी को चला जाता है यह कहना चाहता है, इसलिए यहाँ। उस पर एक अच्छी तरह से समर्थित और बहुत विस्तार योग्य डीएसएल।

कुछ मामलों में, लिस्प (या इसी तरह की भाषा जैसे हास्केल) से डीएसएल बनाना वास्तव में कम से कम प्रयास के साथ बहुत सारी शक्ति प्रदान कर सकता है, और इस तरह यह काफी सार्थक होगा। डीएसएल को हमेशा बड़े रखरखाव के बोझ होने की आवश्यकता नहीं होती है।