कार्यात्मक स्विफ्ट

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



डेनियल पोपोव: सभी को नमस्कार। आज, हमारे मेहमान धूप क्रास्नायार्स्क से एवगेनी एल्शेव है। यूजीन, मुझे बताएं कि आप क्या कर रहे हैं और आप कार्यात्मक प्रोग्रामिंग में कैसे आए?

एवगेनी एल्चेव: सभी को नमस्कार। मैं Redmadrobot में एक iOS डेवलपर हूं, बाकी सभी की तरह, मैं बटन पेंट करता हूं, कभी-कभी मैं बिजनेस लॉजिक लिखता हूं।

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

डेनियल पोपोव: तो, भिक्षु पहले ही जा चुके हैं।

एव्जेनी एलेव: पहले से ही मुश्किल है?

डेनियल पोपोव: मैंने उसी तरह जाने की कोशिश की, लेकिन मैंने लेख खोला, "करी", "मोनड" शब्दों को देखा और तुरंत यह सोचकर बंद कर दिया कि मैं अभी योग्य नहीं था। क्या मेरे पास एक मौका है?

एवगेनी एल्चेव: बिल्कुल। यह तो आप बिलकुल नहीं जानते होंगे।

कार्यात्मकता के बारे में सरल शब्दों में

डेनियल पोपोव: आइए उन लोगों के लिए एक सरल परिभाषा दें जिन्होंने कभी एक कार्यात्मक प्रतिमान के बारे में नहीं सुना है।

एवगेनी एल्चेव: हर कोई अपने तरीके से प्रतिमानों को समझता है। यदि हम विकिपीडिया से स्पष्टीकरण लेते हैं, तो यह गणितीय कार्यों का उपयोग है, जहां पूरे कार्यक्रम को गणितीय कार्य के रूप में व्याख्या की जाती है।

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

डेनियल पोपोव: ओओपी सामान्य प्रक्रियात्मक प्रोग्रामिंग की एक तार्किक निरंतरता थी और कक्षाओं में डेटा को इनकैप्सुलेट करने के मुद्दे को हल करती थी। कार्यात्मक प्रोग्रामिंग से क्या समस्याएं हल होनी चाहिए?

एवगेनी एल्चेव: गणितज्ञों ने कार्यात्मक प्रोग्रामिंग का आविष्कार किया। लोगों ने इकट्ठा किया और एक प्रतिमान बनाने का फैसला किया, जहां सब कुछ साबित हो सकता है। कोड है, इसे अभी तक लॉन्च नहीं किया गया है, लेकिन हम यह सब साबित करेंगे। कार्यक्रम के किसी भी बिंदु की गणना की जा सकती है, यह समझकर कि जब हम कुछ कार्रवाई की अनुमति देंगे तो हम कहां आएंगे।

यह सार लगता है, तो आइए एक शुद्ध कार्य के उदाहरण को देखें। हम एक राशि फ़ंक्शन लिखते हैं जो दो तर्क लेता है, इसमें 2 और 3 पास करें, 5 प्राप्त करें, और हम इसे साबित कर सकते हैं। यह हमेशा सच होता है। यदि हमारे पूरे कार्यक्रम में इस तरह के कार्य शामिल हैं, तो यह सब सिद्ध है।

भाषाओं का निर्माण करते समय, बुनियादी कार्यों को याद किया जाने लगा, और अतिरिक्त विशेषताएं दिखाई दीं: लंबदा, उच्च-क्रम के कार्य, मोनड, मोनॉयड।

कार्यात्मक प्रतिमान एक समस्या को हल नहीं करता है, यह संभव के रूप में सरल के रूप में अच्छा कोड लिखने के लिए एक ही इच्छा है ताकि कार्यक्रमों को स्थिर और बनाए रखने में आसान हो।

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

डेनियल पोपोव: FI अन्य प्रतिमानों से कैसे संबंधित है? क्या मैं OOP में कार्यात्मक रूप से लिख सकता हूँ? प्रतिमानों को कैसे मिलाया जाए, और क्या यह समझ में आता है?

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

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

एवगेनी एल्चेव: यदि आप I / O त्रुटियों को देखते हैं, तो हाँ। पहले, प्रोग्रामर समस्या से जूझ रहे थे: नेटवर्क से जुड़ा हुआ था, कोई नेटवर्क नहीं था, वापस लौटा, और सब कुछ गिर गया। समाधान के लिए, सबसे आसान तरीका यह था कि क्या आया - शून्य / शून्य नहीं, लेकिन यह जांचने के लिए जोखिम था कि सब कुछ ध्यान में नहीं रखा गया है, कार्यक्रम संकलन और दुर्घटना कर सकता है।

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

स्विफ्ट में कार्यात्मक दृष्टिकोण स्थान

अलेक्सेई कुद्र्यावत्सेव: स्विफ्ट को एक कार्यात्मक भाषा कितनी कहा जा सकता है?

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

अलेक्सेई कुद्रेवत्सेव: दूसरे या तीसरे स्विफ्ट में, एक शुद्ध संशोधक था, लेकिन यह केवल संकलन स्तर पर काम करता था ताकि वैश्विक मूल्यों में बदलाव न हो। आपने उनमें कुछ लिखा, लेकिन संकलक ने सब कुछ काट दिया।

एवगेनी एल्चेव: हां, आईओएस में कंपाइलर इसका पालन नहीं करेगा। सब कुछ पूरी तरह से हमारे विवेक पर है: जैसा कि आप लिखते हैं, ऐसा होगा।

अलेक्सेई कुद्रेवत्सेव: आप कहते हैं कि आईओएस अनुप्रयोगों में बहुत सारे राज्य हैं, लेकिन यदि आप एक कार्यात्मक शैली में लिखते हैं तो उनके साथ कहां और क्या करना है?

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

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

अलेक्सेई कुद्र्यावत्सेव : हास्केल में, कंपाइलर बहुत मदद करता है। यदि राज्य कहीं से आता है, तो पूरी कॉल श्रृंखला को गंदा माना जाएगा और आपको सब कुछ मठों में लपेटने की आवश्यकता होगी। यदि फ़ंक्शन शुद्ध है, तो परिणामों का कैशिंग काम करता है - एक ही आउटपुट हमेशा एक ही आउटपुट होता है। स्विफ्ट में, आपको नक्शे को स्वयं लागू करना होगा और यदि यह पहले से ही कैश है तो परिणाम वापस करने का प्रयास करें।

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

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

लेकिन मैं विशिष्ट कार्यात्मक चीजों को नहीं जानता। पहले स्विफ्ट में करंट हुआ करता था, लेकिन इसे काट दिया गया था। अब हम खुद को करीने के लिए एक फ़ंक्शन लिख सकते हैं, या एक फ़ंक्शन लिख सकते हैं ताकि यह एक दूसरे में बंद हो जाए, लेकिन यह बिल्कुल सही नहीं है।

हमारे पास कोई बॉक्सिंग फंक्शनलर्स या मोनाड्स नहीं हैं। उन्हें लिखा भी नहीं जा सकता स्विफ्ट 5.1 में नई सुविधाओं को ऐसा करने में मदद करनी चाहिए, लेकिन मैंने ऐसा कोड लिखने की कोशिश की, और xCode गिर गया।

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

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

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

एक गतिशीलता के लिए कार्यात्मकता की आवश्यकता क्यों है?

डेनियल पोपोव: एक कार्यात्मक दृष्टिकोण मोबाइल विकास के लिए कैसे उपयोगी है? क्या कोई समस्या है जिसे वह हल करता है?

एवगेनी एल्चेव: कोई विशिष्ट समस्या नहीं है जिसे कार्यात्मक प्रोग्रामिंग की मदद से ठीक से हल किया जा सकता है।

सबसे महत्वपूर्ण बात यह है कि इन सिद्धांतों का पालन करते हुए, भले ही यह काम नहीं करता है, हमें शर्तों को छोड़ देना चाहिए, क्योंकि वे मुख्य दर्द हैं।

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

कार्यात्मक प्रतिमान के बाद, आपको प्रेरणा का एक अतिरिक्त स्रोत मिलता है।

डेनियल पोपोव: अगर मैं ओओपी भाषा में ऐसी अपरिवर्तनीय कक्षाएं लिखना शुरू कर देता हूं और अपरिवर्तनीय विधियों का उपयोग कर रहा हूं, तो क्या मैं कह सकता हूं कि मैं कार्यात्मक रूप से लिखता हूं?

एव्जेनी एलचेव: हाँ, जब आप पेशेवरों को देखना शुरू करते हैं। वैश्विक स्थिति की कमी के कारण तरीकों का परीक्षण करना आसान हो रहा है, तरीकों से गणना की एक श्रृंखला बनाना आसान है।

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

अलेक्सेई कुद्रेवत्सेव: यदि आप एक कार्यात्मक भाषा में हैं, तो एक तरफ आपके लिए कोड लिखना आसान है, लेकिन दूसरी तरफ, आपको यह समझना होगा कि अब आप किस तरह के मोनाड हैं।

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

दूसरी ओर, ओपीपी में कक्षाओं के विपरीत, जो कोड को ossified और रचना के लिए कठिन बनाते हैं, फ़ंक्शन अधिक लचीले हो सकते हैं। आप एक फ़ंक्शन लिख सकते हैं, बंद होने की मदद से स्वतंत्रता जोड़ सकते हैं, ऐसे कार्यों को फेंक सकते हैं और उन्हें जंजीरों में जोड़ सकते हैं।

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

डेनियल पोपोव: यह मुझे आरएक्स दृष्टिकोण की याद दिलाता है, जहां वे विशाल श्रृंखला लिखते हैं।

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

डेनियल पोपोव: क्या बहु-प्रतिमान भाषाएं अच्छी हैं, यह कितना सुविधाजनक और उपयोगी है, कि भाषा यह और ऐसा कर सकती है?

एवगेनी एल्चेव: यदि आप किसी प्रकार के प्रतिमान का सख्ती से पालन करते हैं, तो हमेशा ऐसी चीजें होंगी जो करने में असुविधाजनक हैं। ऐसी चीजें हैं जो एक कार्यात्मक शैली में प्राप्त करना मुश्किल है, उदाहरण के लिए, राज्य को संग्रहीत करना और कैश बनाना।

जब एक उपकरण चुनना संभव होता है जो किसी विशिष्ट कार्य के लिए अधिक उपयुक्त होता है - यह अच्छा है।

आप एक वर्ग बना सकते हैं, इसके अंदर एक कार्यात्मक शैली में कई तरीके बनाते हैं और कोड को जंजीरों में व्यवस्थित रूप से व्यवस्थित करते हैं, या कक्षा को पूरी तरह से छोड़ देते हैं, आवश्यक कार्य करते हैं और उनका उपयोग करते हैं।

नकारात्मक पक्ष यह है कि पसंद की एक दुविधा है और जितने अधिक विकल्प हैं, उतना ही मुश्किल यह चुनना है। यह समझना और भी कठिन होता जा रहा है: जितने अधिक विकल्प, उतने अधिक कठिन कोड को पढ़ना।

मोनाद जाम के बारे में

अलेक्सेई कुद्रेवत्सेव: वापस कार्यात्मकता के लिए, एक साधु क्या है?

एवगेनी एल्चेव: मैं इसे एक कंटेनर कहूंगा जिसमें आप गणना की श्रृंखलाओं को जोड़ सकते हैं। सबसे सरल तरीका एक कंटेनर है जिसमें आप फ़ंक्शन को लागू कर सकते हैं और इसे संशोधित मूल्य के साथ एक नए कंटेनर में बदल सकते हैं।

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

यह प्रत्यक्ष अर्थों में राज्य नहीं है, क्योंकि राज्य अलग से संग्रहीत किया जाता है, लेकिन यहां मूल्य के साथ संदर्भ (बॉक्स) है और आप एक से दूसरे में जाते हैं। यह एक गणना से दूसरे में जानकारी का स्थानांतरण है।

अलेक्सेई कुद्रेवत्सेव: यह पता चला है कि एक कार्यात्मक दृष्टिकोण में, जाम बनाने के लिए, आपको एक बॉक्स प्राप्त करना होगा ...

एवगेनी एल्चेव: सुंदरता यह है कि आपको बॉक्स में चढ़ना नहीं है। आप एक बॉक्स फेंक सकते हैं।

अभिजात वर्ग के लिए कार्यक्षमता?

डेनियल पोपोव: एक राय है कि गणित में डॉक्टरेट के बिना कार्यात्मक प्रोग्रामिंग का अभ्यास नहीं किया जा सकता है। क्या यह सच है?

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

अलेक्सई कुद्र्यावत्सेव: एक कार्यात्मक दृष्टिकोण के लिए कितना शौक उत्पाद विकास में हस्तक्षेप कर सकता है? यदि कोड का हिस्सा पहले से ही कार्यात्मक रूप से लिखा गया है, तो क्या इसके साथ काम करने में कोई कठिनाई है?

एवगेनी एलचेव: बिल्कुल नहीं। यदि आप एक पागल नहीं हैं और आप सज्जाकारों के साथ एक विशाल पारिस्थितिकी तंत्र नहीं लिखेंगे, तो आप उसी पैटर्न के मिलान का उपयोग कर सकते हैं।

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

कहाँ से शुरू करें?

डेनियल पोपोव: कार्यात्मक प्रोग्रामिंग को समझने के लिए एक शुरुआतकर्ता को क्या पढ़ना चाहिए?

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

डेनियल पोपोव : सबसे कठिन बात यह है कि प्रतिमान को अपने ही सिर में तोड़ना है।

एवगेनी एल्चेव: कार्यात्मक प्रोग्रामिंग में तेजी से डुबकी लगाने की आवश्यकता नहीं है। बहुत से लोग सोचते हैं कि वे दोनों बैठ जाएंगे और कार्यात्मक रूप से लिखना शुरू कर देंगे - यह गलत है।

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

यदि कार्यात्मकता का प्राथमिक डर पास हो गया है, तो स्प्रिंग एप्सकॉन्फ़ से विटाली ब्रिगिलेव्स्की की रिपोर्ट पर एक नज़र डालें। हालाँकि, AppsConf के पतझड़ के मौसम में हम ऐसे विषयों पर बात करेंगे जो कम दिलचस्प नहीं हैं - IOS समुदाय ब्लूटूथ रिवर्स इंजीनियरिंग पर डेनियल गोंचारोव की एक रिपोर्ट की प्रतीक्षा कर रहा है, और एंड्रॉइड डेवलपर्स एक साथ अलेक्जेंडर स्मिरनोव एनिमेशन के निर्माण के लिए वर्तमान दृष्टिकोणों पर चर्चा करेंगे।