"प्रश्न" क्या है कि प्रोग्रामिंग भाषा सिद्धांत जवाब देने की कोशिश कर रहा है?

Question

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

विकिपीडिया इसका वर्णन इस प्रकार करता है:

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

यह "सब कुछ" कहने जैसा है जो वास्तव में विशिष्ट नहीं है।

विषयों की आम प्रगति आमतौर पर इस तरह होती है:

संयोजन तर्क> लैम्ब्डा कैलकुलस> मार्टिन लोफ टाइप थ्योरी> टाइप किए गए लैम्ब्डा कैलकुलस> (यहां कुछ होता है)> प्रोग्रामिंग भाषाओं का विकास हुआ - जिनका सीएल / साथ बहुत कम संबंध है।$\lambda$

मैं सीएल / जुड़े अंतर्निहित "गणित" को देख सकता हूं और दिलचस्प प्रमाण जो चर्च-रोसेर प्रमेय सहित परिणाम के रूप में सामने आते हैं और यह साफ है। हालाँकि, मैं इस सभी उपक्रम के "अंतिम लक्ष्य" को समझने के लिए संघर्ष कर रहा हूँ? यदि आप करेंगे तो पीएलटी की पवित्र कब्र क्या है ? अभी के लिए यह सिर्फ एक बौद्धिक खुजलाहट हो रहा है, लेकिन मैं वास्तव में अनुसंधान / सिद्धांत से कुछ भी व्यावहारिक करने के लिए पुल पार नहीं कर सकता।$\lambda$

नोट: मुझे यह तब तक नहीं मिलता जब तक कि अनिश्चयता प्रमाण के लिए -calc का उपयोग नहीं किया जाता । लेकिन "कम्प्यूटेबिलिटी" के लिए इसकी प्रयोज्यता से परे मुझे बस यह नहीं मिलता है और इस संकीर्ण पीओवी से पीएलटी में अनुसंधान की आवश्यकता को समझने में भी कठिन समय है। किसी भी मौजूदा किताबें, संदर्भ जो PLT की "बड़ी तस्वीर" पर प्रकाश डाल सकते हैं?$\lambda$

Comments

आप अपने "सामान्य प्रगति" में PLT के पूरे स्वैथ को पूरी तरह से अनदेखा कर रहे हैं। किसी कारण से आपका दृश्य -calculus और प्रकार के सिद्धांत से तिरछा प्रतीत होता है । आइए हम पीओएलएल 2019 के स्वीकृत कागजात पर एक नज़र डालें : समवर्ती यादृच्छिक प्रोग्रामिंग, संभाव्य प्रोग्रामिंग, वर्फ़िबिलिटी असेंबली, बीजगणितीय प्रभाव, तंत्रिका नेटवर्क को प्रमाणित करना, पीएल और हार्डवेयर कमजोर-मेमोरी मॉडल, क्वांटम प्रोग्रामिंग, आदि बहुत सारी चीजें जो "बस" नहीं हैं। सिद्धांत टाइप करें ", क्या आप नहीं कहेंगे? $\lambda$

— बाउर

आप 100% सही हैं। इसलिए मैंने अपने "संकीर्ण पीओवी" को बुलाया। मैं "अन्य विषयों" से परिचित हूँ केवल यहाँ पढ़कर और सिग्लन / POPL कार्यवाही की जाँच करके। मुझे अभी तक "समग्र संदर्भ / पुस्तक" नहीं मिली है जो पीएलटी का एक व्यापक ब्रश अवलोकन देता है जिसमें आपके द्वारा उल्लिखित विषय शामिल हैं । टाइप-थ्योरी बिट केवल "माय" पीओवी ऑफ (क्रिएट?) प्रोग्रामिंग लैंग्वेज से है। क्या आपके पास कुछ संकेत होंगे जो PLTto के विभिन्न क्षेत्रों में उच्च-स्तरीय परिचय प्रदान कर सकते हैं, एक बड़ा चित्र अवलोकन प्राप्त कर सकते हैं? मैं यह जानने के लिए उत्सुक हूं कि वे किस "अंतर्निहित मॉडल" का उपयोग करते हैं और कैसे? हर जगह? $\lambda$

— पीएचडी

@PhD PLT के विभिन्न क्षेत्रों के लिए कोई उच्च-स्तरीय परिचय नहीं है जो आप चाहते हैं, c'est la vie ! शायद एक दिन यह बदल जाएगा। लेकिन अपनी सांस को रोककर न रखें। क्षेत्र तेजी से विकसित हो रहा है, और उप-क्षेत्रों में खुद को अलग कर रहा है। अन्य लोकप्रिय सरल मॉडल में -calculus, संरचनात्मक परिचालनात्मक शब्दार्थ, सरल अनिवार्य गणना (WHILE भाषा की तरह) और कई अन्य शामिल हैं। अक्सर कोई एक खिलौना कैलकुलस को किसी के आवेदन डोमेन के अनुरूप बनाता है। $\pi$

— मार्टिन बर्गर

Answer 1

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

गणित में शामिल होने के कुछ कारण:

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

• PLT में उपयुक्त अनुभवजन्य विधियों का अभाव है, जो कि अच्छा / बेहतर होगा, इसलिए गणित को विकल्प के रूप में किया जाता है।

• मैथ्स सुंदर और गहरी है।

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

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

 Every successful programming language ends up being ML! Either because 
 it was designed by a PL theorist as ML from the start, or because a 
 decade of painful evolution removes all the obvious flaws, leaving ML. ;-)

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

Comments

@MartinBerger: क्या कॉम्पैकर्ट वास्तविक दुनिया की प्रोग्रामिंग भाषा को "सैद्धांतिक रूप से संभालने में सक्षम होने के उदाहरण के रूप में गिना जाता है?" यदि नहीं, तो आप बार को कितना ऊंचा सेट कर रहे हैं, क्योंकि CompCert बहुत प्रभावशाली है।

— बाउर

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

— बाउर

@PhD: टाइप थ्योरी की तुलना में PLT में बहुत अधिक है। यह सिर्फ उस प्रकार का सिद्धांत है जो पहली चीज है जिसे आप नोटिस करते हैं क्योंकि यह पीएलटी के मुख्य उपकरणों में से एक है।

— बाउर

@AndrejBauer CompCert, CakeML आदि प्रभावशाली हैं, लेकिन वे एलएलवीएम, जीसीसी आदि जैसे व्यापक रूप से उपयोग किए जाने वाले कंपाइलरों से बहुत दूर हैं। इसके अलावा, कंपाइलर, किसी भी वास्तविक विश्व सॉफ्टवेयर के विपरीत, एक (तरह / तरह का) विनिर्देश है, जो आपको सामान्य औद्योगिक सॉफ्टवेयर इंजीनियरिंग में नहीं मिलता है। यह उल्लेख नहीं करने के लिए कि कॉम्पैर्ट पर ज़ेवियर के शुरुआती काम का एक बड़ा हिस्सा विनिर्देश को शामिल करने में शामिल था।

— मार्टिन बर्जर

@PhD के बारे में> "गैर-पीएलटी सी / सी ++, जावा, सी #" की तुलना में "मौलिक रूप से अधिक उत्पादक", कृपया ध्यान रखें कि यदि आप उन भाषाओं को देखते हैं, अधिक विशेष रूप से, समय के साथ उनका विकास, लगभग सब कुछ जो उन्होंने हासिल कर लिया है। समय, उदाहरण के लिए लैम्ब्डा, मोनड्स (LINQ), पैटर्न मिलान, आंशिक प्रकार का अनुमान PLT से आता है। C # टीम के पास PLT PhD है। वास्तव में उन्होंने मुझे किसी बिंदु पर रखने की कोशिश की। नौकरी के लिए इंटरव्यू मुझे एंडर्स हाइजेल्सबर्ग को समझाने की कोशिश कर रहा था कि सी # को जेनरिक की जरूरत है, जो उस समय पसंद नहीं आया ...

— मार्टिन बर्जर