फ़ंक्शनल प्रोग्रामिंग लगातार डेटा संरचनाओं और अपरिवर्तनीय वस्तुओं को नियोजित करता है। मेरा सवाल यह है कि इस तरह की डेटा संरचनाएँ यहाँ होना क्यों ज़रूरी है? मैं एक निम्न स्तर पर समझना चाहता हूं कि यदि डेटा संरचना लगातार नहीं है तो क्या होगा? क्या प्रोग्राम अधिक बार क्रैश होगा?
जवाबों:
जब आप अपरिवर्तनीय डेटा ऑब्जेक्ट्स के साथ काम करते हैं, तो फ़ंक्शंस में संपत्ति होती है जो हर बार जब आप उन्हें एक ही इनपुट के साथ कॉल करते हैं, तो वे एक ही आउटपुट उत्पन्न करते हैं। इससे गणनाओं को अवधारणा करना और उन्हें सही करना आसान हो जाता है। इससे उन्हें परीक्षण करने में भी आसानी होती है।
यह सिर्फ एक शुरुआत है। चूंकि गणित ने लंबे समय तक कार्यों के साथ काम किया है, ऐसे बहुत सारे तर्क तकनीक हैं जो हम गणित से उधार ले सकते हैं, और कार्यक्रमों के बारे में कठोर तर्क के लिए उनका उपयोग कर सकते हैं। मेरे दृष्टिकोण से सबसे महत्वपूर्ण लाभ यह है कि कार्यात्मक कार्यक्रमों के लिए सिस्टम अच्छी तरह से विकसित हैं। इसलिए, यदि आप कहीं गलती करते हैं, तो संभावना बहुत अधिक है कि यह एक प्रकार की बेमेल के रूप में दिखाई देगा। इसलिए, टाइप किए गए कार्यात्मक कार्यक्रम अनिवार्य कार्यक्रमों की तुलना में बहुत अधिक विश्वसनीय होते हैं।
जब आप परस्पर डेटा ऑब्जेक्ट्स के साथ काम करते हैं, तो इसके विपरीत, आपके पास पहले कई राज्यों को याद करने और प्रबंधित करने का संज्ञानात्मक भार होता है जो ऑब्जेक्ट एक संगणना के दौरान गुजरता है। आपको सही क्रम में चीजों को करने के लिए ध्यान रखना होगा, यह सुनिश्चित करते हुए कि किसी विशेष कदम के लिए आपके लिए आवश्यक सभी गुण उस बिंदु पर संतुष्ट हैं। गलतियों को करना आसान है, और उन गलतियों को पकड़ने के लिए प्रकार सिस्टम पर्याप्त शक्तिशाली नहीं हैं।
गणित ने कभी भी परिवर्तनशील डेटा ऑब्जेक्ट के साथ काम नहीं किया। इसलिए, कोई तर्क तकनीक नहीं है कि हम उनसे उधार ले सकें। कंप्यूटर विज्ञान में हमारे अपने बहुत सारे तकनीक विकसित हैं, विशेष रूप से फ्लॉयड-होरे लॉजिक । हालांकि, ये मानक गणितीय तकनीकों की तुलना में मास्टर करने के लिए अधिक चुनौतीपूर्ण हैं, अधिकांश छात्र उन्हें संभाल नहीं सकते हैं, और इसलिए वे शायद ही कभी पढ़ाए जाते हैं।
दो प्रतिमान कैसे भिन्न होते हैं, इसके त्वरित अवलोकन के लिए, आप प्रोग्रामिंग लैंग्वेज के सिद्धांतों पर मेरे व्याख्यान नोट्स के पहले कुछ हैंडआउट्स से परामर्श कर सकते हैं ।
यह है आसान सही ढंग से लगातार डेटा संरचनाओं के साथ काम करने के लिए की तुलना में यह परिवर्तनशील डेटा संरचनाओं के साथ काम करने के लिए है। यह, मैं कहूंगा, मुख्य लाभ है।
निश्चित रूप से, सैद्धांतिक रूप से, कुछ भी जो हम लगातार डेटा संरचनाओं के साथ करते हैं, जो हम म्यूटेबल के साथ भी कर सकते हैं, और इसके विपरीत। कई मामलों में लगातार डेटा संरचनाएं अतिरिक्त लागत पैदा करती हैं, आमतौर पर क्योंकि उनके कुछ हिस्सों को कॉपी करना पड़ता है। इन विचारों ने 30 साल पहले लगातार डेटा संरचनाओं को बहुत कम आकर्षक बना दिया होगा जब सुपर कंप्यूटर में आपके मोबाइल फोन की तुलना में कम मेमोरी थी। लेकिन आजकल सॉफ़्टवेयर के उत्पादन में मुख्य अड़चनें विकास के समय और रखरखाव की लागत लगती हैं। इस प्रकार हम विकास में दक्षता के लिए निष्पादन में कुछ दक्षता का त्याग करने को तैयार हैं।
लगातार डेटा संरचनाओं का उपयोग करना आसान क्यों है? क्योंकि मानव वास्तव में एक प्रोग्राम के विभिन्न हिस्सों के बीच अलियासिंग और अन्य प्रकार के अप्रत्याशित इंटरैक्शन को ट्रैक करने में बुरा है । वे स्वचालित रूप से सोचते हैं कि क्योंकि दो चीजों को कहा जाता है xऔर y, फिर कुछ भी नहीं है। सभी का ध्यान रखें, यह पता लगाने का प्रयास करता है कि "सुबह का तारा" और "शाम का तारा" वास्तव में एक ही बात है। इसी तरह, यह भूलना बहुत आसान है कि एक डेटा संरचना बदल सकती है क्योंकि अन्य धागे इसके साथ काम कर रहे हैं, या क्योंकि हमने एक विधि कहा है जो डेटा संरचना को बदलने के लिए होता है, आदि। इन चिंताओं में से कई अभी मौजूद नहीं हैं जब हम साथ काम करते हैं लगातार डेटा संरचनाएं।
लगातार डेटा संरचनाओं के अन्य, तकनीकी फायदे भी हैं। यह आमतौर पर उन्हें अनुकूलित करने के लिए आसान है। उदाहरण के लिए, यदि आप चाहें तो अपने क्लाउड में किसी अन्य नोड पर लगातार डेटा संरचना की प्रतिलिपि बनाने के लिए हमेशा स्वतंत्र हैं, तो सिंक्रनाइज़ेशन की कोई चिंता नहीं है।
दूसरों के उत्तरों को जोड़ना, और एक गणितीय दृष्टिकोण को मजबूत करना, कार्यात्मक प्रोग्रामिंग में रिलेशनल बीजगणित और गैलोज कनेक्शन के साथ एक अच्छा तालमेल भी है।
यह औपचारिक तरीकों के क्षेत्र में अत्यंत उपयोगी है।
उदाहरण के लिए:
उदाहरण
यह दृष्टिकोण सबसे कमजोर पूर्व-स्थिति और सबसे मजबूत स्थिति के बाद की गणना की अनुमति देता है , जो कई स्थितियों में काम आता है।
मैं निम्न स्तर पर समझना चाहता हूं कि यदि डेटा संरचना लगातार नहीं होगी तो क्या होगा?
आइए डेटा संरचना के रूप में एक विशाल राज्य अंतरिक्ष ( 2450 बाइट्स वाले राज्य के साथ " मेर्सन ट्विस्टर ") के साथ एक छद्म आयामी संख्या जनरेटर को देखें । हम वास्तव में किसी भी यादृच्छिक संख्या का एक से अधिक बार उपयोग नहीं करना चाहते हैं, इसलिए इसे अपरिवर्तनीय स्थायी डेटा संरचना के रूप में कार्यान्वित करने का बहुत कम कारण प्रतीत होता है। अब चलो खुद से पूछें कि निम्नलिखित कोड में क्या गलत हो सकता है:
mt_gen = CreateMersenneTwisterPRNGen(seed)
integral = MonteCarloIntegral_Bulk(mt_gen) + MonteCarloIntegral_Boundary(mt_gen)
अधिकांश प्रोग्रामिंग भाषाओं जिस क्रम में निर्दिष्ट नहीं करते हैं MonteCarloIntegral_Bulkऔर MonteCarloIntegral_Boundaryमूल्यांकन किया जाएगा। यदि दोनों एक तर्क के रूप में एक उत्परिवर्ती mt_gen का संदर्भ लेते हैं, तो इस गणना का परिणाम प्लेटफॉर्म पर निर्भर हो सकता है। इससे भी बुरी बात यह है कि ऐसे प्लेटफ़ॉर्म हो सकते हैं जहाँ परिणाम अलग-अलग रनों के बीच बिल्कुल भी नहीं होता।
एक ऐसे mt_gen के लिए एक कुशल उत्परिवर्तनीय डेटा संरचना को डिज़ाइन कर सकता है जैसे कि निष्पादन के किसी भी interleaving MonteCarloIntegral_Bulkऔर MonteCarloIntegral_Boundary"सही" परिणाम देगा, लेकिन एक अलग interleaving सामान्य रूप से एक अलग "सही" परिणाम का नेतृत्व करेगा। यह गैर-प्रजनन योग्यता संबंधित कार्य को "अशुद्ध" बनाता है, और कुछ अन्य समस्याओं को भी जन्म देता है।
एक निश्चित अनुक्रमिक निष्पादन आदेश लागू करने से गैर-प्रजनन योग्यता से बचा जा सकता है। लेकिन उस स्थिति में कोड को इस तरह से व्यवस्थित किया जा सकता है कि किसी भी समय mt_gen के लिए केवल एक ही संदर्भ उपलब्ध हो। टाइप की गई कार्यात्मक प्रोग्रामिंग भाषा में, इस बाधा को लागू करने के लिए विशिष्टता प्रकारों का उपयोग किया जा सकता है, जिससे शुद्ध कार्यात्मक प्रोग्रामिंग भाषाओं के संदर्भ में भी सुरक्षित परिवर्तनशील अद्यतन सक्षम हो सकते हैं। यह सब अच्छा और नम्र लग सकता है, लेकिन कम से कम सिद्धांत में मोंटे कार्लो सिमुलेशन शर्मनाक रूप से समानांतर हैं, और हमारे "समाधान" ने इस संपत्ति को नष्ट कर दिया। यह सिर्फ एक सैद्धांतिक समस्या नहीं है, बल्कि एक बहुत ही वास्तविक व्यावहारिक मुद्दा है। हालांकि, हमें अपने छद्म आयामी संख्या जनरेटर और इसके द्वारा उत्पादित यादृच्छिक संख्याओं के अनुक्रम को संशोधित करना होगा (और कोई भी प्रोग्रामिंग भाषा हमारे लिए यह स्वचालित रूप से नहीं कर सकती है। (बेशक हम एक अलग छद्म आयामी संख्या पुस्तकालय का उपयोग कर सकते हैं जो पहले से ही आवश्यक कार्यक्षमता प्रदान करता है।)
निम्न स्तर पर, उत्परिवर्तनीय डेटा संरचनाएं आसानी से गैर-प्रजनन-क्षमता (और इसलिए अशुद्धता) की ओर ले जाती हैं, यदि निष्पादन क्रम अनुक्रमिक और निश्चित नहीं है। इन समस्याओं से निपटने के लिए एक विशिष्ट अनिवार्य रणनीति तय निष्पादन क्रम के साथ अनुक्रमिक चरण है, जिसके दौरान उत्परिवर्तनीय डेटा संरचनाएं बदली जाती हैं, और मनमाने ढंग से निष्पादन आदेश के साथ समानांतर चरण होते हैं, जिसके दौरान सभी साझा किए गए परिवर्तनशील डेटा संरचनाएं स्थिर रहती हैं।
लेडी बाउर ने उत्परिवर्तनीय डेटा संरचनाओं के लिए अलियासिंग का मुद्दा उठाया। दिलचस्प रूप से पर्याप्त है, फ़ॉर्टन और सी जैसी अलग-अलग अनिवार्य भाषाओं में फ़ंक्शन तर्कों की अनुमति के बारे में अलग-अलग धारणाएं हैं, और अधिकांश प्रोग्रामर इस बात से अनजान हैं कि उनकी भाषा में अलियासिंग मॉडल है।
अपरिवर्तनीयता और मूल्य शब्दार्थ थोड़ा अधिक हो सकता है। अधिक महत्वपूर्ण यह है कि आपकी प्रोग्रामिंग भाषा का प्रकार सिस्टम और लॉजिकल फ्रेमवर्क (एब्सट्रैक्ट मशीन मॉडल, अलियासिंग मॉडल, कंसीडर मॉडल या मेमोरी मैनेजमेंट मॉडल), "कुशल" डेटा के साथ "सुरक्षित रूप से" काम करने के लिए पर्याप्त समर्थन प्रदान करता है। संरचनाओं। C ++ 11 के लिए "चाल शब्दार्थ" की शुरुआत एक सैद्धांतिक दृष्टिकोण से शुद्धता और "सुरक्षा" के संदर्भ में एक विशाल कदम की तरह लग सकती है, लेकिन व्यवहार में यह विपरीत है। नए शब्दार्थ से जुड़े खतरे के बड़े हिस्से को हटाने के लिए टाइप सिस्टम और भाषा के तार्किक ढांचे को बढ़ाया गया है। (और यहां तक कि अगर किसी न किसी किनारों रहते हैं, इसका मतलब यह नहीं है कि यह "बेहतर" द्वारा सुधार नहीं किया जा सकता है
उदय रेड्डी ने यह मुद्दा उठाया कि गणित ने कभी भी परिवर्तनशील डेटा ऑब्जेक्ट्स के साथ काम नहीं किया है, और यह कि कार्यात्मक कार्यक्रमों के लिए प्रकार सिस्टम अपरिवर्तनीय डेटा ऑब्जेक्ट्स के लिए अच्छी तरह से विकसित होते हैं। इसने मुझे जीन-यवेस गिरार्ड के स्पष्टीकरण को याद दिलाया कि गणित का उपयोग अस्थिर वस्तुओं के साथ काम करने के लिए नहीं किया जाता है, जब वह रैखिक तर्क को प्रेरित करने की कोशिश करता है।
कोई यह पूछ सकता है कि कार्यात्मक प्रोग्रामिंग भाषाओं की प्रकार प्रणाली और तार्किक रूपरेखा को किस प्रकार "कुशल" परस्पर "गैर-स्थायी डेटा संरचनाओं" के साथ "सुरक्षित" काम करने की अनुमति दें। यहां एक समस्या यह हो सकती है कि शास्त्रीय तर्क और बूलियन बीजगणित परस्पर डेटा संरचनाओं के साथ काम करने के लिए सबसे अच्छा तार्किक ढांचा नहीं हो सकता है। शायद लीनियर लॉजिक और कम्यूटेटिव मोनॉयड उस कार्य के लिए बेहतर अनुकूल हो सकते हैं? शायद मुझे यह पढ़ना चाहिए कि फंक्शनल प्रोग्रामिंग लैंग्वेजेज के लिए टाइप लॉजिक के रूप में फिलिप वाडलर को लीनियर लॉजिक पर क्या कहना है ? लेकिन भले ही रैखिक तर्क इस समस्या को हल करने में सक्षम नहीं होना चाहिए, इसका मतलब यह नहीं है कि "सुरक्षित" और "कुशल" की अनुमति देने के लिए एक कार्यात्मक प्रोग्रामिंग भाषा के प्रकार और तार्किक ढांचे को बढ़ाया नहीं जा सकता है।