मेरी खुद की प्रोग्रामिंग भाषा बनाना कब उचित है?

48

क्या हत्यारे के आवेदन, एल्गोरिथम समस्याओं की कक्षाएं आदि हैं, जहां यह बेहतर है, लंबे समय में, अपनी भाषा बनाने के लिए?

पुनश्च: बस निश्चित होने के लिए, मेरा मतलब एक नई प्रोग्रामिंग भाषा और एक संकलक है, न कि किसी मौजूदा भाषा के लिए नया संकलक।

संपादित करें : उत्तर के लिए धन्यवाद। क्या आप कुछ उदाहरण प्रदान कर सकते हैं, जहां DSL या ऐसे मामले बनाना पूरी तरह से अनावश्यक है जिसमें एक DSL एक अच्छा विचार हो सकता है?

programming-languages  dsl 
— डैनियल रिकोव्स्की
स्रोत
8
मेरा मानना ​​है कि हर समस्या के लिए एक डीएसएल बनाना चाहिए ।
— एसके-तर्क
4
क्या यह LISP के लिए बहुत अच्छा नहीं है?
— डार्क नाइट
1
@ डर्कनाइट, जरूरी नहीं कि लिस्प - किसी भी भाषा में अच्छे मेटाप्रोग्रामिंग कैबिएबिलिटीज ठीक हों।
— तर्क
2
जब आप कंपाइलर इंटर्न के बारे में जानने की इच्छा रखते हैं।
— dan_waterworth
1
जब आपको लगता है कि यह मजेदार या शैक्षिक होगा। एक नई भाषा को डिजाइन करना जिसमें अपने स्वयं के संकलक की आवश्यकता होती है, कभी भी किसी उपयोगी उद्देश्य की पूर्ति नहीं करता है, इसमें शामिल प्रयास की मात्रा को देखते हुए। (बेशक, ऐसे लोग हैं, जो मेरी सलाह की अनदेखी करने के लिए पर्याप्त रूप से बुद्धिमान, शिक्षित और अनुभव करने के लिए जाने जाते हैं।)
— डेविड थोरले

जवाबों:

40

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

अपनी खुद की भाषा लिखने में:

  • आपकी समस्या में बहुत अधिक जटिलता है
  • नई भाषा और संकलक को लिखने और बनाए रखने में महत्वपूर्ण मात्रा में काम करना

इसलिए, यदि आप अपनी परियोजना के लिए अपनी भाषा लिखने की योजना बनाते हैं तो यह सुविधाएँ जो यह प्रदान करती हैं कि अन्य भाषाओं को उपरोक्त लागतों की भरपाई करने की आवश्यकता नहीं है।

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

— Simucal
स्रोत
13
मुझे यह उल्लेख करना होगा कि "द प्रोगैमैटिक प्रोग्रामर" में किसी कार्य में सहायता के लिए छोटी, डोमेन-विशिष्ट भाषाओं को लिखना अविश्वसनीय रूप से सहायक और प्रोत्साहित किया जाता है। मैं एक पूर्ण सामान्य प्रयोजन की भाषा लिखने की सलाह नहीं दूंगा, लेकिन एक मेटलंगेज जो कोड उत्पन्न करता है वह कई बार मददगार हो सकता है।
— जॉर्डन पार्लर
4
यह झूठ है। भाषा लिखना एक जटिलता को नहीं जोड़ता है - आम तौर पर यह जटिलता को काफी कम कर देगा। एक कंपाइलर को लागू करना और इसे बनाए रखना वैसे भी काम का एक छोटा टुकड़ा है।
— एसके-तर्क
3
@ एसके-तर्क, "एक कंपाइलर को लागू करना और इसे बनाए रखना वैसे भी काम का एक छोटा टुकड़ा है"। आपने कोशिश की है? किस प्रोसेसर के लिए?
1
@ थोरबजोरन राव एंडरसन, मैं इसे जीने के लिए कर रहा हूं। अब आपको सीधे किसी भी सीपीयू को लक्षित करने की आवश्यकता नहीं है - चूंकि एलएमवीएम, .NET, यहां तक ​​कि जेवीएम जैसे महान वीएम उपलब्ध हैं। और अगर आप बहुत अधिक महंगे ऑप्टिमाइज़ेशन नहीं करने जा रहे हैं, तो भी "वास्तविक" सीपीयू को लक्षित करना कोई बड़ी बात नहीं है - इस प्राइमिटिविस्टिक दृष्टिकोण के उदाहरण के लिए ओकेएमएल कंपाइलर देखें।
— एसके-तर्क
7
@ Thorbjørn रावन एंडरसन, परिभाषा संकलक द्वारा एक भाषा से दूसरी भाषा में अनुवाद कर रहे हैं। उस लक्ष्य भाषा का स्तर कुछ भी मायने नहीं रखता है। और कोई भी एक डीएनएस एक डीएसएल के लिए पूर्ण अनुकूलन संकलक बैक-एंड को लागू नहीं करेगा - मौजूदा एक का पुन: उपयोग करना बेहतर है। दरअसल, अधिकांश आधुनिक डीएसएल को सी में संकलित किया जाता है। असेंबलर और लिंकर के लिए - सिस्टम प्रोग्रामिंग के शुरुआती दिनों से ही उन्हें हमेशा संकलन से अलग माना जाता है।
— तर्क
24

मुझे सिर्फ VB संकलक के पूर्व मुख्य विकासकर्ता पॉल विक को उद्धृत करना और अब प्रोजेक्ट ओस्लो और एम भाषा पर काम करना है:

यह एक नई भाषा का निर्माण करने के लिए मन-झुकने वाला, मूर्खतापूर्ण रूप से मुश्किल है, यहां तक ​​कि एक मौजूदा एक पर काफी हद तक आधारित है। फिर भी कई प्रोग्रामर सोचते हैं, "अरे, मैं भाषाओं का उपयोग करता हूं , यह कितना कठिन हो सकता है?" और उस पर जाएं। ... शायद उनमें से 98% से अधिक कभी भी किसी भी कर्षण को प्राप्त करने में विफल होते हैं, लेकिन भगवान आशावादियों को आशीर्वाद देते हैं क्योंकि उनके बिना हम 2% भाषाओं को कभी भी सफल नहीं होंगे। मैं व्यक्तिगत रूप से उन भाषाओं पर बर्बाद हुए लाखों डॉलर और घंटों का बलिदान करने के लिए तैयार हूं जो कभी नहीं बनाते हैं ताकि हम C # और जावा और रूबी और पायथन जैसी भाषाओं को प्राप्त कर सकें।

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

DSLs: निश्चित रूप से एक बुरा विचार है!

— कोनराड रूडोल्फ
स्रोत
8
VB! = VBA। वैसे, क्या इस साइट पर VBA की आलोचना करना भी कानूनी है? आखिर, योएल ने इसे विकसित करने में मदद की, है ना?
— कोनराड रुडोल्फ
1
हालांकि व्यावहारिक प्रोग्रामर इतनी अच्छी किताब थी, लेकिन उस किताब में डीएसएल की सिफारिश सादी बेवकूफी थी। उसी तरह जिस तरह से उन्होंने हर साल एक नई भाषा सीखने की सिफारिश की, IMHO कि यह बहुत ही बेवकूफ है।
— डॉ। दुष्ट
2
मैंने Google कैश के बजाय पॉल विक के लेख को फिर से इंगित करने के लिए आपके उत्तर को संपादित किया । 2011 में उन्होंने "अपने ब्लॉग को रीसेट किया" और सभी VB सामग्री को हटा दिया, लेकिन 2012 में उन्होंने इसे अलग URL के साथ वापस रख दिया। लगता है जैसे वह व्यक्तिगत रूप से एक कठिन समय था जब उसने उस सामान को हटा दिया।
— MarkJ
2
@MarkJ बहुत बहुत धन्यवाद। और, वाह, यह लेख सुखद पढ़ने के लिए नहीं है । आशा है कि वह अब बेहतर कर रहे हैं।
— कोनराड रूडोल्फ
2
इस तरह की टिप्पणियों के लिए धन्यवाद, मैं वास्तव में अब जावास्क्रिप्ट पर काम कर रहा हूं और हां, चीजें काफी बेहतर हैं। :-) यह निश्चित नहीं है कि मूल लिंक काम क्यों नहीं कर रहा है, मैंने सभी पुराने लिंक शैलियों को काम करने की कोशिश की, मैं इसे देखूंगा।
— panopticoncentral
22

यह कब उचित है?

जब मन करे!

उन लोगों की बात न सुनें जिनके पास भद्दी टिप्पणी है जो मूल रूप से कहते हैं:

"ऐसा मत करो क्योंकि इसकी बहुत कठिन और एक्स भाषा किसी भी भाषा से बेहतर है जो आप के साथ आ सकते हैं"।

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

यदि "ऐसा नहीं करते" सही उत्तर था, तो हम सभी COBOL और फोरट्रान लिख रहे होंगे।

— अनजान
स्रोत
3
वास्तव में? मैं फ्रेमवर्क, मैक्रोज़ और फ़ंक्शंस पर विचार करूंगा, वे सभी चीजें हैं जो भाषा को स्वतंत्रता बनाए रखने में मदद करती हैं।
— कर्टनडॉग
3
@ कुरंटडॉग, यह भाषा का केवल एक हिस्सा बन जाता है यदि इसका मानक पुस्तकालय का हिस्सा है। अन्यथा यह भाषा की "बोली" है।
9

यदि आप अपनी भाषा लिखने की सोच रहे हैं, तो आप मार्टिन फाउलर की आगामी डीएसएल पुस्तक के कुछ हिस्सों को पढ़ना चाह सकते हैं ।

मैं वास्तव में खरोंच से एक भाषा बनाने के लिए एक जबरदस्त सीखने के अनुभव के अलावा एक व्यवसाय के मामले के बारे में सोच भी नहीं सकता।

संपादित करें: DSL के लिए बहुत सारे व्यावसायिक मामले हैं, लेकिन यहां कुंजी को दूर ले जाने और इसे सरल रखने के लिए नहीं है।

— रुबेन स्टीन
स्रोत
7

मेरा सुझाव है कि मुख्य प्रश्न हैं, "मैं किस समस्या को हल करने की कोशिश कर रहा हूं?" और "आरओआई किसे मिलता है?"

यदि आप अपने स्वयं के कौशल और अनुभव का निर्माण करने की कोशिश कर रहे हैं, तो आगे की पूरी गति, लेकिन उत्पादन प्रणाली में नहीं जो किसी और की समस्या को हल करने वाला है।

— joel.neely
स्रोत
7

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

लिस्प जैसी भाषा में क्यों न लिखें जो आपको नए पैटर्न खोजने के साथ ही भाषा का विस्तार करने देती है? फिर, आपको एक स्थापित भाषा के सभी लाभों के साथ एक नई भाषा की सारी शक्ति मिलती है।

— क्लिंट मिलर
स्रोत
6

भाषा डिजाइन और संकलक निर्माण के बारे में जानने के लिए इसे प्रयोग के रूप में बनाने का एक कारण हो सकता है।

एक और कारण एक स्क्रिप्टिंग भाषा को एक एप्लिकेशन में बनाना हो सकता है जब आपके पास तृतीय-पक्ष एपीआई जोड़ने का विकल्प नहीं होता है।

— सेबस्टियन डाइट्ज़
स्रोत
6

मुझे नहीं लगता कि आप एक नई भाषा बनाए बिना कार्यक्रम कर सकते हैं, इसलिए यह महसूस करना अच्छा है कि आप क्या कर रहे हैं और मुद्दों को समझ रहे हैं।

  • भाषा क्या है?
    शब्दावली, वाक्यविन्यास, और शब्दार्थ।

एक ऑफ-द-शेल्फ भाषा जैसे VB, Java, C #, आदि केवल एक आधार भाषा है। जैसे ही आप इसमें वर्गों, विधियों आदि को जोड़ते हैं, आपने शब्दावली और शब्दार्थ जोड़ दिए हैं। भाषाओं को लागू करने के कई तरीके हैं - एक मौजूदा भाषा के शीर्ष पर पार्सिंग और अनुवाद करना, पार्स करना और व्याख्या करना, मैक्रोज़ एक मौजूदा भाषा में कक्षाएं और विधियाँ जोड़ना।

  • आप एक भाषा क्या करना चाहते हैं?
    समस्याओं को स्पष्ट रूप से व्यक्त करने के लिए अच्छा हो।

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

  • सुघड़ता अच्छी क्यों है?
    क्योंकि यह बग को कम करता है।

यदि यह 1 आवश्यकता को लागू करने के लिए एन कोड में परिवर्तन करता है, और आप कभी-कभी गलतियाँ करते हैं, तो आपके द्वारा लागू किए जाने वाले बगों की संख्या एन के लिए लगभग आनुपातिक होती है। उस सीमा में जहां एन = 1, बग की कोशिश किए बिना बग को पेश करना लगभग असंभव है।

ध्यान दें कि यह आजकल "कोड ब्लोट" के लिए एक सीधी चुनौती है जिसे हम देखते हैं।

जोड़ा गया: उदाहरण के लिए आपके अनुरोध के जवाब में, अंतर निष्पादन को देखें । मैं यह नहीं कहूंगा कि इसे जल्दी समझा जा सकता है, लेकिन यह यूआई कोड को काफी कम करता है।

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

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

यह एक दिलचस्प बौद्धिक चुनौती है।

— साइमन
स्रोत
ओह, माफ करना। गैर-देशी वक्ता ... :)
— डैनियल रिकोवस्की
ओह, यह नहीं पता था कि और आपकी पोस्ट उत्कृष्ट अंग्रेजी में है, इसलिए बताना मुश्किल है। व्याकरण पुलिस बनने की कोशिश नहीं कर रही है - माफी।
— साइमन
5

यदि आपकी टीम का मुख्य व्यवसाय भाषाओं की प्रोग्रामिंग है तो ही।

मैंने एक प्रोग्रामिंग भाषा पर काम किया है जो एक वित्तीय कंपनी में बनाई गई थी।

स्पष्ट रूप से, आर्किटेक्ट के लिए यह एक बड़ी चुनौती थी और अपने कौशल में सुधार किया।

अनिवार्य रूप से, भाषा कहीं भी उस दर के आस-पास विकसित या सुधार नहीं कर सकती है जो C # या Java जैसी कोई चीज हो सकती है - उनके पास ऐसा करने के लिए समर्पित टीम है।

भाषा जल्द ही स्थिर हो गई क्योंकि कोई भी नया व्यक्ति किसी और के पालतू प्रोजेक्ट को बेहतर बनाने का काम नहीं करना चाहता था।

मूल वास्तुकार छोड़ दिया। 10 साल बाद भाषा मुरझा गई और मर गई।

वे 10 साल किसी के लिए नरक थे जिन्हें मृत भाषा पर काम करने का दुर्भाग्य था।

इसलिए आगे बढ़ें, अपनी भाषा बनाएं लेकिन कृपया किसी और से वास्तव में इसका उपयोग करने के लिए न कहें। कृपया किसी और से इसके लिए धन्यवाद देने की उम्मीद न करें।

— जो आर
स्रोत
1
दिलचस्प केस स्टडी ... क्या जावा या .NET प्लेटफॉर्म के लिए किसी भाषा को लक्ष्य करके ऐसे ठहराव को रोका जा सकता है। इस तरह से भाषा 'विकसित' हो सकती है क्योंकि आधार पुस्तकालयों में अधिक जोड़ा जाता है।
— कर्टनडॉग
2
मुझे यकीन नहीं है कि आप एक ऐसी भाषा क्यों बनायेंगे जो जावा जैसी दूसरी को लक्षित करती है। शुरुआत करने के लिए सिर्फ जावा या सी # का उपयोग क्यों नहीं किया जाता?
4

डिजाइनिंग भाषाएँ मज़ेदार हो सकती हैं। लेकिन आपको प्रोग्रामिंग लैंग्वेज के लिए खुद को रिस्ट्रिक्ट नहीं करना है।

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

— तून Krijthe
स्रोत
4

यह पूरी तरह से उचित है अगर आपके कौशल का विस्तार करने और सीखने के लिए किया जाता है।

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

और आप इसके बारे में गलत भी हो सकते हैं, लेकिन आपको उसे समझाने के लिए एक दूसरे विशेषज्ञ की आवश्यकता होगी (या आपको यह दिखाने के लिए कि आप जो विशेषज्ञ हैं वह आपको नहीं लगता)। एक जीवंत चर्चा जो एक सरल क्यू-एंड-ए होगी, जैसा कि आप यहां पाएंगे।

— एडम बेलेयर
स्रोत
4

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

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

यह निश्चित रूप से स्थिति पर निर्भर करता है। जैसा कि नोस्कोलो ने कहा - यदि आपके पास एक अच्छा विचार है, एक नई अवधारणा या ऐसा कुछ है जो मैं आपको ऐसा करने के लिए अत्यधिक सलाह दूंगा।

सामान्य तौर पर मैं स्थापित प्रौद्योगिकी पर भरोसा करने का सुझाव दूंगा।

लेकिन अगर आप अपनी खुद की "भाषा" बनाने में रुचि रखते हैं, तो आपको यह देखना चाहिए: YACC और Lex

— क्रिस
स्रोत
3

आप बस अपने आप को विरोधी पैटर्न "स्क्वायर व्हील को फिर से बनाना" में नहीं पकड़ सकते।

मतलब आप पहले से किए गए व्हाट्स को फिर से बना रहे हैं, केवल ओरिजिनल (ओं) से ज्यादा गरीब हैं।

— वाक्य - विन्यास
स्रोत
यदि पहियों को फिर से नहीं बनाया गया तो हम अभी भी रॉक पहियों का उपयोग कर सकते हैं। रॉक
— वोंग जिया हौ
3

अपनी भाषा कब बनाएं?

जब आप चाहते हैं, एक बड़े शौक परियोजना के रूप में।

एक डोमेन-विशिष्ट भाषा के लिए। ये काफी विस्तृत हो सकते हैं; संग्रह को देख कर इंटरएक्टिव फिक्शन (या टेक्स्ट एडवेंचर) समुदाय में क्या होता है, इसे देखें ।

जब आपके उद्देश्य बहुत महत्वाकांक्षी होते हैं, और आपको लगता है कि आप पॉल ग्रैहम के आर्क प्रोजेक्ट की तरह वास्तविक उन्नति कर सकते हैं ।

इसके अलावा, निम्न स्तर के निर्माणों को विकसित करने की प्रक्रिया में किसी भी पर्याप्त रूप से अनुकूलनीय भाषा (शायद सी ++, निश्चित रूप से कॉमन लिस्प) में।

जब आप इसे से बचने के लिए चाहते हैं, तो मुझे उम्मीद है, प्लेग की तरह इसे टालने से बचें।

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

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

— डेविड थॉर्नले
स्रोत
3

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

हालाँकि, यह हो सकता है कि आपकी ज़रूरतें इतनी कस्टम हों कि आपकी कंपनी के लिए DSL (न कि थोड़ा संशोधित gcc या लिस्प कार्यान्वयन) ही बेहतर हो। कई कंपनियां अपनी भाषा को लिखने / बनाए रखने के बिना, जो कुछ भी कर रही हैं उसे लक्षित करने वाली वर्तमान भाषाओं के ड्रॉप-इन का उपयोग करती हैं। जैसे, मैंने सुना है कि PHP में एक अच्छा ड्रॉप-इन है; लुआ को एक ड्रॉप-इन होने के लिए डिज़ाइन किया गया है, मॉडलव्यू पायथन का उपयोग करता है और ऑटोकैड के पास ऑटोकैस है।

— पॉल नाथन
स्रोत
3

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

मशीन कोड के लिए सभी तरह से जाने से पहियों का एक बहुत मजबूत हो रहा है ...

एक DSL के लिए एक बहुत अच्छा कारण एक संक्षिप्त तरीके से डोमेन डेटा का प्रतिनिधित्व करना है। यह डोमेन विशेषज्ञों को दूसरों के माध्यम से जाने के बजाय सीधे डेटा के साथ काम करने की अनुमति देता है। चाल तो एक आसान प्रक्रिया के रूप में परिणामी कार्यक्रमों के लिए है।

— user1249
स्रोत
3

आम तौर पर जवाब बोलना एक बड़ा नहीं होगा। सैकड़ों भाषाओं में से आमतौर पर एक है जो आपकी समस्या के अनुरूप होगी।

हालांकि ऐसी परिस्थितियां हैं जहां यह एक नई भाषा विकसित करने के लिए एक तर्कसंगत विकल्प है: -

  • जब आपका एक प्रतियोगी अब आपके मुख्य विकास प्लेटफार्मों में से एक का मालिक है। मैं जावा पर गोगल्स की वर्तमान निर्भरता और "गो" के उनके विकास के बारे में सोच रहा हूं, (यह मदद करता है यदि आपके पास पेरोल पर कभी सबसे सफल भाषा का लेखक है!)।
  • जब आपको एक नया प्लेटफ़ॉर्म के लिए एक टन कोड लिखना होता है और मौजूदा भाषाएं क्रिया और त्रुटि प्रवण होती हैं - जैसे वेब विकास के लिए php।
  • जब आप पैमाने और समानांतरवाद की समस्याओं के सामने आते हैं, जो पहले कभी सामने नहीं आए थे, क्योंकि इससे पहले किसी के पास इस डेटा को संसाधित करने के लिए इतना हार्डवेयर नहीं था - जैसे स्काला और (एक निश्चित सीमा तक)।
— जेम्स एंडरसन
स्रोत
2

रचना किस भाषा में अच्छी है या समान घटकों को अलग-अलग तरीकों से एक साथ रखना।

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

OTOH, यदि आपका कॉन्फ़िगरेशन वास्तविक भाषा जैसे है। क्रियाओं और संज्ञाओं को कई अलग-अलग (और उपन्यास) संयोजनों में जटिलता की किसी भी डिग्री के लिए एक साथ रखा जा सकता है, फिर एक भाषा लगभग अपरिहार्य होने जा रही है, क्योंकि किसी भी अन्य विधि से आप जो चाहते हैं उसे निर्दिष्ट करने की कोशिश के दहनशील विस्फोट।

— INTERSTAR
स्रोत
1

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

— डेव शेरोहमान
स्रोत
1

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

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

एक कारण शैक्षिक उद्देश्यों के लिए है, जैसा कि पहले ही कहा गया है। लेकिन और भी हैं। उदाहरण के लिए, जैसे कई अनुसंधान भाषाएं हैं Sing#पर विलक्षणता ऑपरेटिंग सिस्टम और BitCपर Coyotos कि क्योंकि मौजूदा भाषाओं (एक भाषा स्तर पर उदाहरण के सत्यापन के लिए) के लिए आवश्यक सुविधाओं की पेशकश नहीं करते डिजाइन किया गया है।

— sakisk
स्रोत
1

टॉम वान कट्सम ने हाल ही में इस प्रश्न का एक निबंध लिखा है:

http://soft.vub.ac.be/~tvcutsem/whypls.html

बुलेट सारांश (उस पृष्ठ से):

  • वाक्यविन्यास अमूर्त तंत्र के रूप में भाषा: दोहराए जाने वाले "बॉयलरप्लेट" कोड को कम करने के लिए जो किसी अन्य भाषा के अंतर्निहित अमूर्त तंत्र का उपयोग करने से अमूर्त नहीं किया जा सकता है।
  • सोचा शेपर के रूप में भाषा: कैसे एक संरचना सॉफ्टवेयर ("कम से कम प्रतिरोध का रास्ता बदल") में एक प्रतिमान बदलाव प्रेरित करने के लिए।
  • भाषा को एक सरलीकृत के रूप में: एक मौजूदा प्रतिमान को केवल अपने आवश्यक भागों तक उबालने के लिए, अक्सर समझ और अंतर्दृष्टि बढ़ाने के लिए।
  • भाषा को कानून के प्रवर्तक के रूप में: महत्वपूर्ण गुणों या अपरिवर्तकों को लागू करने के लिए, संभवतः कार्यक्रमों से अधिक उपयोगी गुणों का अनुमान लगाना आसान बनाने के लिए।
— ऐदन कलली
स्रोत
0

शायद कभी नहीं।

यदि आप मूल रूप से किसी अन्य भाषा में भाषा को एम्बेड करना चाहते हैं तो Lua सबसे अच्छा विकल्प है।

छोटे डोमेन Specifc भाषाएँ वर्तमान में हैं, और यह कुछ अनुप्रयोगों में समझ में आता है।

अन्य तो यह है कि, कारण मुख्य रूप से अकादमिक हैं।

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

— majkinetor
स्रोत
लुआ है स्लो-ओओओ। लेकिन, दूसरी ओर, कुछ अच्छे मेटाप्रोग्रामिंग क्षमताओं के साथ मेटाला है।
— तर्क
0

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

  1. आपका उपयोगकर्ताबेस कुछ लोगों की तुलना में बड़ा है, आम तौर पर गैर-तकनीकी और / या प्रतिबंधित सिस्टम एक्सेस के साथ (इसलिए उन्हें मौजूदा सामान्य प्रयोजन भाषा सीखने / उपयोग करने की अपेक्षा करना अनुचित है)। यदि यह आपकी देव टीम या सॉफ़्टवेयर संगठन के भीतर है, तो आप इसके बजाय "बस एक स्क्रिप्ट लिख सकते हैं"।
  2. आपके उपयोगकर्ताओं को इसे पर्याप्त रूप से अक्सर उपयोग करने की आवश्यकता होती है, जिसमें पर्याप्त रूप से विविध और बदलते व्यवहार की आवश्यकता होती है (यानी आप केवल आपके द्वारा कार्यों का एक निश्चित पुस्तकालय प्रदान नहीं कर सकते हैं)
  3. उपयोगकर्ता जो व्यवहार निर्दिष्ट कर सकता है वह डेटा के रूप में निर्दिष्ट करने के लिए बहुत जटिल है (उदाहरण के लिए, आप इसे डेटाबेस तालिका, या उपयोगकर्ता-इनपुट मैट्रिक्स, या कार्यों की सूची या कुंजी-मूल्य संग्रह का उपयोग करके प्राप्त नहीं कर सकते हैं ... ध्यान से सोचें क्योंकि आप इनसे बहुत जटिलता प्राप्त कर सकते हैं)। यदि आप डीएसएल के बजाय डेटा इनपुट या कॉन्फ़िगरेशन का उपयोग करके व्यवहार को प्राप्त कर सकते हैं तो आपको शायद ऐसा करना चाहिए क्योंकि यह बहुत कम काम होगा। किसी प्रकार की सशर्तता, या रचनाशीलता / एक साथ जंजीर, या कुछ अलग-अलग अमूर्तताओं का मॉडलिंग करना संकेत हो सकता है कि आपके द्वारा आवश्यक व्यवहार सादे डेटा / कॉन्फ़िगरेशन के लिए बहुत जटिल है।
  4. लेकिन व्यवहार अभी भी पर्याप्त प्रतिबंधित है कि आप इसे संक्षिप्त डीएसएल में निर्दिष्ट कर सकते हैं। एक बड़ा खतरा 'प्लेटफ़ॉर्म ब्लोट' है, जैसे यदि उपयोगकर्ता अनुरोध करना शुरू करते हैं "क्या आप बस जोड़ सकते हैं ...?"। यदि उन्हें इंटरनेट से कनेक्ट करने की आवश्यकता है, या फ़ाइल सिस्टम से पढ़ना और लिखना है, या खुली और बंद प्रक्रियाएं - तो यह अब डीएसएल नहीं है। (मैंने इसे वास्तविक रूप से देखा है ... उपयोगकर्ताओं को छोटे अजगर कॉल एम्बेड करने की अनुमति दी, धीरे-धीरे अजगर लिपियों के लिए बढ़ रहा है, और अंततः किसी भी सीमा / प्रतिरूपता / प्रदर्शन को नष्ट कर रहा है)

अगर ये सब सच है तो एक डीएसएल उपयुक्त हो सकता है।

— उपयोगकर्ता 967543 को दर्शाता है
स्रोत
0

क्या हत्यारे के आवेदन, एल्गोरिथम समस्याओं की कक्षाएं आदि हैं, जहां यह बेहतर है, लंबे समय में, अपनी भाषा बनाने के लिए?

निर्भर करता है।

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

सामान्यतया, ऐसे जटिल विषय अभी भी हैं जो अन्य रणनीतियों को जन्म दे सकते हैं जिसमें एक निश्चित परिदृश्य के लिए एक 'बेहतर' भाषा भी शामिल होगी।

— फेबियन बिगलर
स्रोत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.