कार्यात्मक प्रोग्रामिंग: सात बार मापें, एक बार काटें

शुभ दोपहर हाल ही में, मैंने बहुत बार सुना है कि पीएलओ का सूर्यास्त आ गया है। आज, अधिक से अधिक लोग एक कार्यात्मक प्रतिमान पर जा रहे हैं। जल्द ही, C ++ / C # / Java में लिखने वाले लोगों को बिल्कुल भी नहीं छोड़ा जाएगा। क्या ऐसा है? मुझे ऐसा नहीं लगता। मेरी राय में, एफपी (कार्यात्मक प्रोग्रामिंग) का विचारहीन उपयोग समय लेने वाली और एक अतिरिक्त सिरदर्द बन सकता है, जो वर्तमान डिजाइन निर्णयों के साथ पूरी तरह से असंगत है। चलो यह सुनिश्चित करें!



मैं ध्यान देना चाहता हूं: यह जावा / पायथन में लैम्ब्डा अभिव्यक्तियों के बारे में नहीं है, बल्कि बिल्लियों / स्केलज़ के साथ एक अधिक उन्नत एफपी जैसे हास्केल या स्काला के बारे में है।

तो, मैं पुष्टि करता हूं कि:

1. वायुसेना हर जगह लागू होने से दूर है।
2. यह तैयार किए गए समाधानों के साथ एकीकृत होने पर सिरदर्द लाता है।
3. वायुसेना पर समय बिताना हमेशा बुद्धिमान नहीं होता है।

हम इन बिंदुओं का अधिक विस्तार से विश्लेषण करेंगे और त्रासदी के पैमाने का मूल्यांकन करेंगे।

1. वायुसेना हर जगह लागू होने से दूर है

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

ऐसा क्यों हो रहा है? तथ्य यह है कि उपरोक्त सभी लोहे के साथ सीधे काम करते हैं। उच्च आदेश के किसी भी कार्य को लोहा नहीं जानता है। आयरन रजिस्टरों का एक सेट है (जो पहले से ही एक परिवर्तनशील अवस्था है), बीच में (फिर से, जो राज्य को बदल देता है) को बाधित करता है और एक सेल से दूसरे में शून्य और एक को स्थानांतरित करने की आज्ञा देता है।

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

2. यह टर्नकी समाधान के साथ एकीकरण करते समय सिरदर्द लाता है

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

कोई भी हार्ड-कोर कार्यात्मक प्रोग्रामर कहेगा कि आपको इन समाधानों को फेंकने और उनके बिना काम करने की आवश्यकता है। ठीक है। आइए संदर्भ के लिए केवल यह समझें कि इस तरह के निर्णय से हम क्या खो देंगे:

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

वास्तव में, सूची लंबे समय तक चलती है। मेरी राय में, घाटे की समग्रता एएफ बनाती है, कम से कम, हर जगह नहीं और हमेशा उपयुक्त नहीं।

3. वायुसेना पर समय बिताना हमेशा बुद्धिमान नहीं होता है

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

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

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

निष्कर्ष

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

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

आपका ध्यान के लिए धन्यवाद!