भाषा डिजाइनर क्या तय करने या साबित करने के लिए करते हैं कि एक विशेष सुविधा सही ढंग से काम करती है?


11

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

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

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

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

जब भाषा डिजाइनर एक नई सुविधा डिज़ाइन करते हैं, तो यह तय करने के लिए कि वे किस पद्धति या प्रक्रिया का उपयोग करते हैं, यह सुविधा ठीक से काम करती है?

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

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

  • या वास्तव में (शब्द के गणितीय अर्थ में) साबित करने के लिए एक औपचारिक तरीका है कि आपकी सुविधा काम करती है और फिर उस प्रमाण का उपयोग आत्मविश्वास से शुरू करने के लिए सुविधा (या अधिकतर सही) प्राप्त करने के लिए है?

(मुझे यह उल्लेख करना चाहिए कि मेरे पास एक इंजीनियरिंग पृष्ठभूमि है, न कि कंप्यूटर विज्ञान। इसलिए यदि मुझे कुछ ऐसा याद आ रहा है जो सीएस लोगों के लिए स्पष्ट होगा, तो कृपया इसे इंगित करने के लिए स्वतंत्र महसूस करें।)


जब आप "भाषा डिजाइनर" कहते हैं, तो क्या आपका मतलब एक ऐसे व्यक्ति से है जो कंपाइलर, या सिंटैक्स या दोनों बनाता है?
स्नूप

6
@StevieV: भाषा डिजाइन कार्यान्वयन से अलग और स्वतंत्र है। उदाहरण के लिए, लिस्प को जॉन मैकार्थी ने λ-पथरी के विकल्प को समझने में आसान के रूप में डिजाइन किया था। हालाँकि, उन्होंने इसे लागू नहीं किया। वास्तव में, जब उनके छात्र स्टीव रसेल लिस्प को लागू करना चाहते थे, तो मैकार्थी ने उन्हें बताया कि उनका मानना ​​है कि लिस्प को लागू करना असंभव था! APL को गणित पढ़ाने के लिए एक भाषा के रूप में डिजाइन किया गया था। बाद में, आईबीएम ने औपचारिक रूप से सिस्टम / 360 के व्यवहार को निर्दिष्ट करने के लिए इसका उपयोग किया, जिसके लिए भाषा को कई एक्सटेंशन मिले। इस समय, यह अभी भी लागू नहीं किया गया था। प्लांकालुकल को कोनराड
जोर्ग डब्ल्यू

4
१ ९ ४२-१९ ४६ लेकिन केवल १ ९ 46५ में लागू किया गया। निकोलस विर्थ ने पहली बार अपनी भाषाओं को पूरी तरह से डिजाइन किया, और केवल डिजाइन के साथ समाप्त होने के बाद उन्हें लागू किया (और उन्होंने भाषा में पहला कंपाइलर लिखा कि कैसे भाषा अच्छी तरह से महसूस करें। डिज़ाइन किया गया - तब उन्होंने अपने छात्रों को बूटस्ट्रैपिंग के लिए संकलक को दूसरी भाषा में सौंप दिया)। बहुत अधिक अकादमिक भाषाएं कभी लागू नहीं की जाती हैं, वे केवल एक बिंदु साबित करने के लिए डिज़ाइन की जाती हैं या कुछ भाषा सुविधा के साथ एक अमूर्त तरीके से प्रयोग करती हैं। स्मॉलटॉक को एक पारस्परिक दांव के परिणाम के रूप में बनाया गया था: एलन के शर्त जो वह कर सकता था
जोर्ग डब्ल्यू मित्तग

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

3
अवश्य पढ़ें: गोडेल, Escher, बाख । यह कई बार थोड़ा अजीब होता है, लेकिन अंत में ट्यूरिंग और गोडेल के काम में शामिल हो जाता है जो भाषा डिजाइन की औपचारिकता को बहुत प्रभावित करता है।
रबड़डक

जवाबों:


6

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

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

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


2
मुझे लगता है कि आप जिस संदर्भ की तलाश कर रहे हैं वह "एडवेंचर्स इन टाइप्स इन हास्केल" श्रृंखला में से एक है , शायद इसने थंबनेल छवि में बोर्ड की सामग्री दी ...
जूल्स

8

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

भाषा कार्यान्वयन के लिए , यह किसी भी अन्य की तरह कोड है। आप यूनिट टेस्ट लिखते हैं। आप एकीकरण परीक्षण लिखते हैं। आप कोड समीक्षा करते हैं।

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

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


4
The only thing that makes languages special is that they are (almost always) infinite. You literally cannot test all inputs.क्या यह वाकई इतना खास है? यह मेरे लिए सामान्य मामला लगता है। उदा। एक फ़ंक्शन जो एक तर्क के रूप में एक सूची लेता है, उसमें अनंत संख्या में इनपुट होते हैं। आपके द्वारा चुने गए किसी भी आकार n के लिए, आकार n + 1. की सूची है
डोभाल

@ डोवाल - और तार भी, मुझे लगता है। एक अच्छा बिंदु।
तेलस्तीन

4

पहली और सबसे कठिन बात एक भाषा डिजाइनर को नई विशेषताओं को पेश करते समय ध्यान रखना चाहिए, अपनी भाषा को सुसंगत रखना है:

  • मौजूदा कोड को तोड़े बिना इसे भाषा व्याकरण में कैसे एकीकृत किया जा सकता है (यह गणितीय रूप से सिद्ध किया जा सकता है)
  • यह मौजूदा सुविधाओं के साथ कैसे संबंधित है (उदाहरण के लिए, यदि आपने तय किए गए सरणियों को 0..n-1 के साथ जोड़ा है, तो आप एक नया चर सरणी विशेषता अनुक्रमित 1.।n) का परिचय नहीं देंगे (जो कि डिजाइन का कलात्मक हिस्सा है)
  • इस सुविधा को पूरे टूलकिन के पार कैसे लागू किया जा सकता है ताकि पारिस्थितिकी तंत्र, टूलमेकर और प्रोग्रामर द्वारा नई सुविधा को अवशोषित किया जा सके (अवधारणा के प्रमाण के साथ व्यवहार्यता का प्रदर्शन किया जा सकता है, लेकिन पूर्ण कार्यान्वयन प्रोग्रामिंग के समान एक दृष्टिकोण है)

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

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


4

प्रोग्रामिंग भाषा सुविधाओं का परीक्षण कैसे करें? यह एक बहुत अच्छा सवाल है, और मुझे यकीन नहीं है कि कला की स्थिति नौकरी तक है।

प्रत्येक नई सुविधा अन्य सभी सुविधाओं के साथ बातचीत कर सकती है। (यह भाषा, डॉक्स, कंपाइलर, एरर मैसेज, आईडीई, लाइब्रेरी आदि को प्रभावित करता है) क्या फीचर्स एक खामियों को खोलने के लिए गठबंधन करते हैं? गंदे किनारे के मामले बनाने के लिए?

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

"ठीक से काम करता है" से मेरा मतलब है कि फीचर सही ढंग से समस्या का हल करता है, और यह उचित रूप से बुलेटप्रूफ है।

विश्वसनीय उत्पादन सॉफ्टवेयर बनाने के लिए कई प्रोग्रामर द्वारा उपयोग की जाने वाली उत्पादन भाषाओं का इरादा भाषाओं के लिए , "ठीक से काम करता है" का मतलब आगे चलकर इच्छित दर्शकों के लिए सही ढंग से समस्या का समाधान करना होगा।

दूसरे शब्दों में, प्रयोज्य भाषा के डिजाइन के लिए उतना ही महत्वपूर्ण है जितना कि अन्य प्रकार के डिजाइन के लिए। यह प्रयोज्य (उदाहरण के लिए अपने दर्शकों को जानने), और (2) प्रयोज्य परीक्षण के लिए (1) डिजाइन की आवश्यकता है।

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

इस विषय पर एक उदाहरण एसई प्रश्न है कि क्या किसी प्रोग्रामिंग भाषा की वाक्य रचना का परीक्षण किया गया है?

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

स्मॉलटॉक, पायथन और डार्ट जैसी भाषाओं को प्रयोज्यता पर जोर देने के साथ डिजाइन किया गया था। स्पष्ट रूप से हास्केल नहीं था।


हास्केल वास्तव में बहुत उपयोगी है। यह केवल सीखना मुश्किल है क्योंकि यह पायथन / सी / जावा आदि के लिए एक बिल्कुल अलग प्रतिमान है, लेकिन एक भाषा के रूप में इसका उपयोग करना बहुत आसान है।
अर्धविराम
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.