एक्शन में लैंग्वेज ओरिएंटेड प्रोग्रामिंग (LOP)

डोमेन ड्रिवेन डिज़ाइन पर पिछले प्रकाशन की निरंतरता में, जहां निकोलाई ग्रेबनेव ने डोमेन भाषा का उपयोग करने की आवश्यकता के लिए डीडीडी का उपयोग करने के लिए डिजाइनिंग के विषय को लगातार कम किया, इस प्रकाशन में स्वयं और उन दोनों भाषाओं को डिजाइन करने और विकसित करने के अभ्यास पर चर्चा होगी ( JetBrains अनुभव )।

मैक्सिम Mazin आवेदन डेवलपर्स दिनों सॉफ्टवेयर आर्किटेक्ट के पिछले साल के सम्मेलन से smax रिपोर्ट

रिपोर्ट वीडियो:

डाउनलोड

ftp.linux.kiev.ua/pub/conference/peers/addconf/2011/1a1-language-oriented-programming-mazin.avs.avi

प्रदर्शन

docs.google.com/present/view?id=dccwwvbq_729dxjj82gc

पाठ रिपोर्ट ( बेलोनॉक्स द्वारा किया गया)

आज मेरे पास अपनी पहली रिपोर्ट है, मैं प्रोग्रामिंग में भाषा विषय पर बात करूंगा।
मेरा नाम मैक्सिम माज़िन है, मैं जेटट्राइन्स में YouTrack प्रोजेक्ट में एक इंजीनियर के रूप में काम करता हूँ।
YouTrack एक बगट्रैकर है, और YouTrack के बारे में सबसे आकर्षक बात यह है कि यह भाषा रिकॉर्ड प्रोग्रामिंग का उपयोग करके लिखा गया है।
यह क्या है यह एक ऐसी अवधारणा है, जो मानती है कि जब प्रोग्राम लिखते हैं, तो सबसे पहले आप एक विशेष विषय-उन्मुख भाषा बनाते हैं, और फिर, इस विषय-उन्मुख भाषा में, आप वास्तविक प्रोग्राम कोड लिखना शुरू करते हैं।

यह किस लिए है? इस का उपयोग क्या है, और क्या सभी को ऐसा करने से रोकता है - मैं आज इस बारे में बात करूंगा।

देखिए, सार्वभौमिक प्रोग्रामिंग भाषाएं हैं। जब जावा, PHP या C # भाषा का उपयोग करते हुए प्रोग्रामिंग होती है, तो एक समस्या उत्पन्न होती है - आपके पास प्रोग्रामिंग करते समय बॉयलरप्लेट कोड की एक बड़ी मात्रा होती है, अर्थात। ऐसा कोड, जो समय-समय पर दोहराया जाएगा, लेकिन इसलिए नहीं कि यह कुछ सार्थक काम करता है, बल्कि बस इतना है कि कंपाइलर इस कोड को संकलित कर सकता है।
गोल कोष्ठक, बिंदु, ... आदि लिखें।
मामले में जब आप किसी प्रकार के ढांचे का उपयोग करते हैं, तो आपको अभी भी ढांचे से अतिरिक्त दर्द होता है।
आपको लाइब्रेरी को इनिशियलाइज़ करना होगा, विंडो खोलना होगा, कुछ प्रॉपर्टीज़ सेट करनी होंगी, जो आपके पास किस तरह की लाइब्रेरी है, इस पर निर्भर करता है।
सिद्धांत रूप में, कई आधुनिक प्रोग्रामिंग भाषाओं में, उदाहरण के लिए, C # में, भाषा में डोमेन-विशिष्ट निर्माणों को जोड़ने की प्रथा है।

जावा में, एक सिंक्रनाइज़ निर्माण होता है, जो किसी प्रकार का सामान्य उद्देश्य निर्माण नहीं होता है, यह समानांतर प्रोग्रामिंग के लिए एक विशेष, विषय-उन्मुख निर्माण है।

इसी तरह, C ++ में, ऑपरेटर ओवरलोडिंग है। यहां, तुलना करें।
एक सामान्य स्थिति में, यदि आपके पास एक सिंक्रनाइज़ निर्माण नहीं है, तो आपको इतना कोड लिखना होगा।
अंत में ब्लॉक और लॉक प्राप्त करने के लिए ब्लॉक बॉयलरप्लेट कोड हैं, जो हर समय लिखना दिलचस्प नहीं है।
इसके बजाय, एक "सिंक्रनाइज़" डीएसएल डिज़ाइन है जो आपको एक लॉक कैप्चर करने की अनुमति देता है और इसे जारी करने की चिंता नहीं करता है।

उसी तरह, C ++ में ऑपरेटर ओवरलोडिंग के लिए एक तंत्र है जो आपको यह दिखावा करने की अनुमति देता है कि आपने विशेष संचालन को परिभाषित किया है, उदाहरण के लिए, जटिल संख्याओं पर।

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

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

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

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

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

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


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

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

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

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

ऐसा करने के लिए कई अलग-अलग प्रयास हैं, एक या दूसरे रूप में DSL का समर्थन करने के लिए, विषय बहुत गर्म है, यहां आप अभी भी नेमेर्ले जोड़ सकते हैं, और शायद OCaml, अब DSL बनाने के लिए बहुत सारे अलग-अलग उपकरण हैं।
एक्लिप्सा के भीतर, एक XText ढांचा है जो आपको एक व्याकरण लिखने और IDE समर्थन के साथ एक डीएसएल जैसा कुछ प्राप्त करने की अनुमति देता है।

उन सभी को समस्याएँ हैं। मुख्य समस्या इस तथ्य से उपजी है कि वे पाठ व्याकरण पर केंद्रित हैं।
और जब से वे पाठकीय व्याकरण पर केंद्रित होते हैं, तो उनके पास डिजाइन की संगतता की समस्या से बचने का कोई मौका नहीं होता है।

लेकिन सौभाग्य से, हमारी कंपनी JetBrains में, MPS वातावरण बनाया गया था।

MPS का अर्थ मेटा-प्रोग्रामिंग सिस्टम है, जो मुख्य रूप से भाषाओं के निर्माण और विस्तार के लिए है, और इस तरह के विस्तार के साथ कि इसके निर्माण के तुरंत बाद IDE के लिए समर्थन था।

मैंने कई बार कहा है कि पाठ व्याकरण अनिवार्य रूप से समस्याओं को जन्म देता है। इसलिए, प्राकृतिक समाधान सीधे एएसटी → सार सिंटैक्स ट्री के साथ काम करना है, और प्रोग्रामर को सीधे, सीधे सिंटैक्स ट्री बनाने के लिए मजबूर करना है।

प्रयास पहले किए गए हैं, और एक नियम के रूप में इस तरह के प्रयास संपादन आरेखों के लिए नीचे आते हैं।
एक आरेख खींचा जाता है, एक अर्थ में ... मेरा बच्चा गुणों पर एक बड़ी हद तक प्रोग्रामिंग कर रहा है, आप आरेख खींचते हैं, आपको चित्र मिलते हैं, फिर इन चित्रों को एकत्र किया जाता है, कोड प्राप्त किया जाता है।
एक समस्या है - इन चित्रों को खींचना असुविधाजनक है - माउस के साथ हड़पने, खींचें, असहज।
हम प्रोग्रामर को कोड लिखने की आदत है।
इसलिए, MPS में प्रोजेक्शन संपादकों की अवधारणा को लागू किया गया है।

आप किस बारे में बात कर रहे हैं? यहां आपके पास एक सार वाक्यविन्यास वृक्ष है। यानी यह उस कार्यक्रम का प्रतिनिधित्व है जो किसी भी मामले में प्राप्त किया जाता है, जब पार्सर कार्यक्रम को पार्स करता है।
उसी समय, आपके पास इसका प्रक्षेपण पाठ जैसी किसी चीज़ में होता है।

इस सिंटैक्स ट्री के प्रत्येक नोड के लिए एक संबंधित सेल है।
आप में से जो TeX से परिचित हैं, उनमें लगभग समान अवधारणाएं होनी चाहिए।
इसी तरह, प्रत्येक तत्व के लिए आपके पास एक सेल है, कोशिकाएं और भी बड़ी कोशिकाओं में विलीन हो जाती हैं, और इसी तरह।
इस मामले में, इन कोशिकाओं पर प्रभाव, जब आप इन कोशिकाओं को लिखते हैं, या किसी तरह से उन्हें प्रभावित करते हैं, तो तुरंत, तुरंत लकड़ी के इस टुकड़े को प्रभावित करते हैं।
उसी समय, हमारा लक्ष्य, MPS डेवलपर्स के रूप में, यह सुनिश्चित करना है कि आप यह बिल्कुल महसूस नहीं करते हैं कि आप पाठ के साथ नहीं, बल्कि सीधे लकड़ी के टुकड़े के साथ काम कर रहे हैं। यह निश्चित रूप से एक समस्या है, लेकिन आप में से जो लोग IDEA का उपयोग करते हैं, उन्हें यह समझना चाहिए कि जब आप IDEA, ग्रहण या अन्य जगहों पर पाठ संपादित करते हैं, तो आप पाठ को संपादित भी नहीं करते हैं - आप उस चीज़ को मिटा देते हैं जिसे IDEA अवशोषित करता है, और यह है किसी चीज में बदल जाता है।
ग्रहण के मामले में, यह अधिक पाठ संपादन है; IDEA के मामले में, यह पाठ संपादन भी कम है।

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

विचार यह है। भाषा बनाते समय, आप भाषाओं का एक मेटा-मॉडल लिखते हैं, इसका अमूर्त सिंटैक्स, एक प्रकार की प्रणाली निर्दिष्ट करते हैं, एक विशिष्ट सिंटैक्स का वर्णन करते हैं, और संकलक के साथ-साथ भाषा प्राप्त करते हैं, साथ ही उस भाषा में कोड के साथ काम करने के लिए एक एमपीएस टेस्ट भी।

एमपीएस के साथ, एमपीएस के अंदर, कई तैयार एक्सटेंशन दिए जाते हैं, क्योंकि हम अंततः जावा में प्रोजेक्ट लिखते हैं, अर्थात्। हम सभी जावा में उत्पन्न होते हैं, फिर हमारे पास भाषाओं का एक ढेर है जो कि जावा के लिए अंत में है।
MPS के साथ मिलकर, इसके अंदर, विभिन्न भाषा एक्सटेंशन की आपूर्ति की जाती है, क्लोजर के साथ काम करने के लिए, संग्रह के साथ ... और इसी तरह। और XML के साथ काम करने के लिए भाषाओं की एक निश्चित संख्या काम करने के लिए बेवकूफ है। यानी आप XML में प्रवेश कर सकते हैं, और सबसे महत्वपूर्ण बात, अपने कोड से XML उत्पन्न करें।

वैसे, भाषाओं को बनाने के लिए डिज़ाइन की गई कई भाषाएँ भी हैं।
भाषा बनाने के मामले में एमपीएस काफी ईमानदार है (??? 16:20)
एक प्रदर्शन के बजाय - यह कुछ इस तरह दिखता है -।
मैं अपने कंप्यूटर से नहीं दिखाता हूं, इसलिए हर कोई जो प्रदर्शन में रुचि रखता है, मैं आपको दालान में एक स्टैंड पर आमंत्रित करता हूं।
फिर देखें कि भाषा निर्माण के लिए DSL समर्थन को जोड़ना और जोड़ना कितना आसान है।

वास्तव में, वह सब जो मैं बताना चाहता था, कुछ महत्वपूर्ण चीजें बाकी हैं।

MSP न केवल भाषा एक्सटेंशन बनाने के लिए उपयुक्त है, अर्थात न केवल जावा में आप उन निर्माणों को जोड़ सकते हैं जो उनसे गायब हैं, लेकिन आप अपने स्वयं के डीएसएल भी बना सकते हैं।
उदाहरण के लिए, मार्टिन फाउलर ने अपने वित्तीय वक्तव्यों का वर्णन करने के लिए एक भाषा बनाई।

इसके अलावा, एमपीएस की मदद से, हमने YouTrack लिखा, इतना बड़ा बग ट्रैकर बड़ा है, इस अर्थ में बहुत सारे कोड (उत्पन्न) के साथ। लेकिन मेरा पिछला विकास अनुभव मुझे बताता है कि हम जो कोड लिखते हैं और संपादित करते हैं वह सार्थक है, यह कोड काफी छोटा है।
रुचि फिर से, हम आउटपुट पर दिखा सकते हैं कि संपादक में कोड कैसा दिखता है, कितने टेबल हैं।
कोड काफी छोटा है, इस तथ्य के कारण कि अमूर्त का स्तर काफी ऊंचा उठाया गया है।
YouTrack के विकास के लिए भाषाओं का एक सेट बनाया गया है, इनमें से कुछ भाषाएं खुली हैं, और कुछ बंद हैं।
हम उन्हें अभी तक नहीं देते हैं, क्योंकि वे अभी तक बिक्री की गुणवत्ता तक नहीं पहुंचे हैं।

यहां, एप्लिकेशन वास्तविक है, लाइव।

एमपीएस में एक सकारात्मक विशेषता है। यह अपाचे 2.0 लाइसेंस है, वाणिज्यिक उपयोग के लिए भी पूरी तरह से मुक्त है।

आप इसे यहाँ डाउनलोड कर सकते हैं।
www.jetbrains.com/mps

एमपीएस ब्लॉग:
blogs.jetbrains.com/mps

अब यदि आपके कोई प्रश्न हैं, तो मेरा सुझाव है कि आप उनसे पूछें। (18:46)