कार्यात्मक प्रोग्रामिंग क्यों अच्छा है?

Question

मैंने देखा है कुछ मूल अवधारणाओं कि कार्यात्मक प्रोग्रामिंग कट्टरपंथियों का एक बहुत से चिपक देखते हैं कि:

• राज्य से बचना

• परिवर्तनशील डेटा

• को न्यूनतम दुष्प्रभाव

से बचना

• आदि ...

मैं सिर्फ यह नहीं सोच रहा हूं कि अन्य चीजें कार्यात्मक प्रोग्रामिंग कैसे करती हैं, लेकिन ये मूल विचार अच्छे क्यों हैं? राज्य से बचने के लिए अच्छा क्यों है, और बाकी?

Answer 1

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

स्टेटलेस कोड होने से थ्रेड किए गए प्रोग्राम भी आसान हो जाते हैं, क्योंकि आपको निष्पादन के दो धागे को एक ही समय में डेटा के साझा टुकड़े को संशोधित/पढ़ने के बारे में चिंता करने की आवश्यकता नहीं है। आपके धागे स्वतंत्र कोड चला सकते हैं, और यह विकास के समय के भार को बचा सकता है।

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

स्टेटलेस, "कार्यात्मक" कोड बनाने के कई अन्य कारण हैं, लेकिन वे सभी मेरे लिए सादगी के लिए उबालते हैं।

Answer 2

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

Purely functional data structures समान रहने की गारंटी है - यदि एक समारोह एक पेड़ लौटाता है, तो यह हमेशा एक ही पेड़ होगा, और सभी आगे के परिवर्तन इसकी नई प्रतियां बनाएंगे। डेटा संरचना के किसी भी पिछले संस्करण को इस तरह से बैकट्रैक करना बहुत आसान है, जो कई आवश्यक एल्गोरिदम के लिए महत्वपूर्ण है।

Answer 3

बहुत आम तौर पर, कार्यात्मक प्रोग्रामिंग का अर्थ है:

• (प्रथम श्रेणी) कार्यों
• (परिवर्तनशील) राज्य

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

Answer 4

एक सामान्य कार्यात्मक विशेषता "कोई उप-टाइपिंग" नहीं है।हालांकि यह एक सुविधा को कॉल करने के लिए थोड़ा अजीब लगता है, यह दो (किसी भी तरह से संबंधित) कारणों के लिए है:

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

बेशक

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