कार्यात्मक भाषाओं में अतुल्यकालिक प्रोग्रामिंग


31

मैं ज्यादातर C / C ++ प्रोग्रामर हूं, जिसका अर्थ है कि मेरे अनुभव का अधिकांश भाग प्रक्रियात्मक और वस्तु-उन्मुख प्रतिमानों के साथ है। हालांकि, जैसा कि कई सी ++ प्रोग्रामर जानते हैं, सी ++ एक कार्यात्मक-एस्क स्टाइल के लिए वर्षों से जोर दिया गया है, आखिरकार लंबोदा और सी ++ 0x में बंद होने के अलावा इसका समापन हुआ।

भले ही, जबकि मेरे पास कार्यात्मक में कोडिंग का काफी अनुभव है C ++ का उपयोग करते हुए शैली है, लेकिन मुझे वास्तविक कार्यात्मक भाषाओं जैसे लिस्प, हास्केल आदि के साथ बहुत कम अनुभव है।

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

हालाँकि, C ++ बैकग्राउंड से आने के कारण मैं असमंजस में हूँ कि यह कैसे "कोई साइड-इफ़ेक्ट" नहीं है। फ़िल्सोफी अतुल्यकालिक प्रोग्रामिंग के साथ काम करता है। एसिंक्रोनस प्रोग्रामिंग से मेरा मतलब है कि कोई भी फ्रेमवर्क / एपीआई / कोडिंग शैली जो उपयोगकर्ता द्वारा प्रदान किए गए ईवेंट हैंडलर को उन घटनाओं को संभालने के लिए भेजती है जो एसिंक्रोनस रूप से होती हैं (प्रोग्राम के प्रवाह के बाहर।) इसमें एसिंक्रोनस लाइब्रेरी जैसे कि बूस्ट .ASIO, या यहां तक ​​कि सिर्फ सादे पुराने सी शामिल हैं। सिग्नल हैंडलर या जावा GUI इवेंट हैंडलर।

इन सभी में एक बात समान है कि अतुल्यकालिक प्रोग्रामिंग की प्रकृति को साइड-इफेक्ट्स (राज्य) के निर्माण की आवश्यकता होती है, ताकि प्रोग्राम के मुख्य प्रवाह के बारे में पता चल सके कि एक अतुल्यकालिक ईवेंट हैंडलर को आमंत्रित किया गया है। आमतौर पर, Boost.ASIO जैसे ढांचे में, एक ईवेंट हैंडलर किसी ऑब्जेक्ट की स्थिति को बदल देता है, ताकि ईवेंट हैंडलर फ़ंक्शन के जीवन-समय से पहले ईवेंट के प्रभाव का प्रचार हो। वास्तव में, एक इवेंट हैंडलर और क्या कर सकता है? यह कॉल बिंदु के लिए एक मूल्य "वापस" नहीं कर सकता है, क्योंकि कॉल बिंदु नहीं है। ईवेंट हैंडलर कार्यक्रम के मुख्य प्रवाह का हिस्सा नहीं है, इसलिए वास्तविक कार्यक्रम पर इसका कोई प्रभाव हो सकता है एकमात्र तरीका कुछ राज्य (या किसी longjmpअन्य निष्पादन बिंदु पर) को बदलना है ।

तो ऐसा लगता है कि अतुल्यकालिक प्रोग्रामिंग सभी अतुल्यकालिक रूप से साइड-इफेक्ट्स पैदा करने वाले हैं। यह पूरी तरह से कार्यात्मक प्रोग्रामिंग के लक्ष्यों के साथ बाधाओं पर लगता है। कार्यात्मक भाषाओं में इन दोनों प्रतिमानों को कैसे मिलाया जाता है (व्यवहार में)?


3
वाह, मैं बस एक सवाल लिखने के बारे में पसंद कर रहा था और यह नहीं पता था कि इसे कैसे रखा जाए और फिर सुझावों में यह देखा!
अमोघ तलपलीकर

जवाबों:


11

आपके सभी तर्क ध्वनि हैं, सिवाय इसके कि मुझे लगता है कि कार्यात्मक प्रोग्रामिंग की आपकी समझ थोड़ी बहुत चरम पर है। वास्तविक विश्व कार्यात्मक प्रोग्रामिंग में, ऑब्जेक्ट-ओरिएंटेड की तरह, या अनिवार्य प्रोग्रामिंग मानसिकता के बारे में है और आप समस्या का सामना कैसे करते हैं। आप एप्लिकेशन स्थिति को संशोधित करते हुए कार्यात्मक प्रोग्रामिंग की भावना में अभी भी प्रोग्राम लिख सकते हैं।

वास्तव में, आपको वास्तव में कुछ भी करने के लिए एप्लिकेशन स्थिति को संशोधित करना होगा । हास्केल लोग आपको बताएंगे कि उनके कार्यक्रम 'शुद्ध' हैं क्योंकि वे एक मोनाड में अपने राज्य के सभी परिवर्तनों को लपेटते हैं। हालांकि, उनके कार्यक्रम अभी भी बाहरी दुनिया के साथ बातचीत करते हैं। (नहीं तो बात क्या है!)

कार्यात्मक प्रोग्रामिंग जोर "कोई साइड इफेक्ट" जब यह समझ में आता है। हालांकि, वास्तविक दुनिया की प्रोग्रामिंग करने के लिए, जैसा आपने कहा था, आपको दुनिया की स्थिति को संशोधित करने की आवश्यकता है। (उदाहरण के लिए, घटनाओं पर प्रतिक्रिया, डिस्क पर लिखना और इसी तरह।)

कार्यात्मक भाषाओं में अतुल्यकालिक प्रोग्रामिंग के बारे में अधिक जानकारी के लिए, मैं आपसे F # के अतुल्यकालिक वर्कफ़्लोज़ प्रोग्रामिंग मॉडल को देखने का आग्रह करता हूँ । यह आपको एक पुस्तकालय के भीतर धागा संक्रमण के सभी गड़बड़ विवरणों को छिपाते हुए कार्यात्मक कार्यक्रम लिखने की अनुमति देता है। (एक तरह से हास्केल शैली के साधुओं के समान।)

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


5
इसके अलावा: एर्लैंग को देखने से मदद मिलती है। भाषा बहुत सरल है, शुद्ध है (सभी डेटा अपरिवर्तनीय है), और सभी अतुल्यकालिक प्रसंस्करण के बारे में है।
9000

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

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

8

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

http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey

मूल रूप से प्रस्तावित "समाधान" इस प्रकार है:

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

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


6

एक नोट: एक कार्यात्मक भाषा शुद्ध है, लेकिन इसका रनटाइम नहीं है।

उदाहरण के लिए, हास्केल रनटाइम में कतारें, थ्रेड मल्टीप्लेक्सिंग, कचरा संग्रह आदि शामिल हैं ... ये सभी शुद्ध नहीं हैं।

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


2

मैं उलझन में हूँ कि यह कैसे "कोई साइड-इफेक्ट्स" नहीं है फ़िस्लोफी अतुल्यकालिक प्रोग्रामिंग के साथ काम करता है। अतुल्यकालिक प्रोग्रामिंग से मेरा मतलब है ...

यह तो बात होगी।

एक ध्वनि, कोई साइड-इफेक्ट शैली उन रूपरेखाओं के साथ असंगत नहीं है जो राज्य पर निर्भर करती हैं। एक नया ढांचा खोजें।

उदाहरण के लिए, पायथन का WSGI मानक, हमें बिना किसी साइड-इफ़ेक्ट एप्लिकेशन के निर्माण की अनुमति देता है।

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


"कोई साइड-इफ़ेक्ट एप्लिकेशन बनाने की अनुमति देता है" मुझे लगता है कि वहाँ एक शब्द कहीं गायब है।
क्रिस्टोफर महान

1

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

विशेष रूप से प्रतिमानों का कठोरता से पालन करने से, उदाहरण के लिए, लचकदार अमूर्तता से निपटने में असुविधा होती है। JRE, DirectX, .net टारगेट ऑब्जेक्ट ओरिएंटेड प्रूफ़र्स फॉरमोस्ट जैसे व्यावसायिक रनटाइम। असुविधा को रोकने के लिए, भाषाएँ या तो हास्सेल जैसे विद्वानों के परिष्कृत मोनड्स का चयन करती हैं, या F # जैसे लचीले बहु-प्रतिमान समर्थन प्राप्त करती हैं। जब तक कुछ अलग-अलग वंशानुक्रम उपयोग के मामले से एनकैप्सुलेशन उपयोगी नहीं होता है, बहु-प्रतिमान दृष्टिकोण कुछ, कभी-कभी जटिल, प्रतिमान-विशिष्ट प्रोग्रामिंग पैटर्न के लिए बेहतर विकल्प हो सकता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.