कार्यात्मक प्रोग्रामिंग: समवर्ती और राज्य के बारे में सही विचार?

Question

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

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

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

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

मैं यह देखने में विफल रहा हूं कि मेरे उदाहरण में समसामयिकता कितनी उपयोगी है और यह मुद्दा हो सकता है। मैं किसी तरह दावे को गलत ठहरा सकता हूं।

क्या कोई इस दावे का बेहतर प्रतिनिधित्व कर सकता है?

Comments

आप साझा स्थिति की बात कर रहे हैं; साझा स्थिति हमेशा वह होगी जो हमेशा होती है और उसे हमेशा किसी न किसी तरह के सिंक्रोनाइज़ेशन की आवश्यकता होती है, शुद्ध FP लोगों के बीच thet पसंदीदा फॉर्म STM होता है जो आपको साझा मेमोरी को स्थानीय स्मृति के रूप में व्यवहार करने देता है, इसके ऊपर एक एब्सट्रैक्शन लेयर होता है जिससे एक्सेस ट्रांसेक्शनल हो जाता है। परिस्थितियों को स्वचालित रूप से नियंत्रित किया जाता है। साझा मेमोरी के लिए एक और तकनीक संदेश पासिंग है जहां साझा मेमोरी होने के बजाय, आपके पास स्थानीय मेमोरी और अन्य अभिनेताओं के ज्ञान के लिए अपनी स्थानीय मेमोरी के लिए पूछने के लिए है

— जिमी हॉफ

तो ... आप पूछ रहे हैं कि कैसे साझा-राज्य संगामिति आसान करने में मदद करता है एक एकल-थ्रेडेड एप्लिकेशन में राज्य का प्रबंधन? दूसरी ओर, आपका उदाहरण स्पष्ट रूप से कॉन्सेप्टिवली (प्रत्येक AI- नियंत्रित इकाई के लिए एक थ्रेड) है या नहीं, इस तरह से इसे लागू किया जाता है या नहीं। मैं उलझन में हूँ कि आप यहाँ क्या पूछ रहे हैं।

— सीए मैककैन

एक शब्द में, Zippers

— जे.के.

हर वस्तु का दुनिया के प्रति अपना दृष्टिकोण होगा। आखिरकार संगति होगी । यह शायद यह भी है कि तरंग फ़ंक्शन के पतन के साथ चीजें हमारे "वास्तविक दुनिया" में कैसे काम करती हैं ।

— हर्ज़ेमिस्टर

आपको "विशुद्ध रूप से कार्यात्मक रेट्रोगैम

— user802500

Answer 1

मैं उत्तर पर संकेत देने की कोशिश करूंगा। यह एक उत्तर नहीं है , केवल एक परिचयात्मक चित्रण है। @ jk का जवाब असली बात, zippers को इंगित करता है।

कल्पना कीजिए कि आपके पास एक अपरिवर्तनीय वृक्ष संरचना है। आप एक बच्चे को सम्मिलित करके एक नोड को बदलना चाहते हैं। नतीजतन, आपको एक नया पेड़ मिलता है।

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

ओकासाकी की किताब इस तरह के उदाहरणों से भरी है।

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

यह संभवतः डेटा गेम की विश्व संरचना को उपयुक्त तरीके से डिजाइन करने में कुछ विचार करता है। दुर्भाग्य से, मैं इन मामलों में कोई विशेषज्ञ नहीं हूं। निश्चित रूप से यह एक एनएक्सएम मैट्रिक्स की तुलना में कुछ और होना चाहिए, जो एक परिवर्तनशील डेटा संरचना के रूप में उपयोग करेगा। संभवतः इसमें छोटे टुकड़े (गलियारे? व्यक्तिगत कोशिकाएं?) शामिल होने चाहिए, जो एक दूसरे को इंगित करते हैं, जैसे कि पेड़ नोड्स करते हैं।

Comments

+1: ओकासाकी की पुस्तक में इंगित करने के लिए। मैंने इसे नहीं पढ़ा है लेकिन यह मेरी सूची में है। मुझे लगता है कि आपने जो दर्शाया है वह सही समाधान है। एक विकल्प के रूप में, आप विशिष्ट प्रकारों पर विचार कर सकते हैं (स्वच्छ, en.wikipedia.org/wiki/Uniqueness_type ): इस प्रकार के प्रकारों का उपयोग करके आप संदर्भ पारदर्शिता को बनाए रखते हुए डेटा ऑब्जेक्ट्स को विनाशकारी रूप से अपडेट कर सकते हैं।

— जियोर्जियो

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

— मारियो टी। लैंज़ा

Answer 2

9000 का उत्तर आधा उत्तर है, लगातार डेटा संरचनाएं आपको अपरिवर्तित भागों का पुन: उपयोग करने की अनुमति देती हैं।

आप पहले से ही सोच रहे होंगे "अरे क्या होगा अगर मैं पेड़ की जड़ को बदलना चाहता हूं?" जैसा कि यह दिए गए उदाहरण के साथ खड़ा है कि अब सभी नोड्स को बदलने का मतलब है। यह वह जगह है जहाँ Zippers बचाव के लिए आते हैं। वे ओ (1) में ध्यान केंद्रित करने के लिए तत्व की अनुमति देते हैं, और फोकस को संरचना में कहीं भी स्थानांतरित किया जा सकता है।

ज़िपर के साथ अन्य बिंदु यह है कि एक Zipper आपके द्वारा इच्छित किसी भी डेटा प्रकार के लिए मौजूद है

Comments

मुझे डर है कि मुझे "ज़िपर" में खोदने में कुछ समय लगेगा क्योंकि मैं फ्रिंज पर हूं केवल किसी भी एफपी की खोज कर रहा हूं। हास्केल के साथ मेरा कोई अनुभव नहीं है।

— मारियो टी। लैंज़ा

मैं आज बाद में एक उदाहरण जोड़ने की कोशिश करूँगा

— jk।

Answer 3

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

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

func MakeMonsterDecision curWorldState monster =
    ...
    ...
    return monsterDecision

func NextWorldState curWorldState =
    ...
    let monsterMakeDecisionForCurrentState = MakeMonsterDecision curWorldState
    let monsterDecisions = List.map monsterMakeDecisionForCurrentState activeMonsters
    ...
    return newWorldState

आपके पास यह गणना करने के लिए एक फ़ंक्शन है कि एक राक्षस विश्व राज्य क्या देगा, और इसे अगले विश्व राज्य की गणना के भाग के रूप में हर राक्षस पर लागू करेगा। यह एक कार्यात्मक भाषा में करने के लिए एक स्वाभाविक बात है, और संकलक समानांतर में 'हर राक्षस के लिए इसे लागू' करने के लिए स्वतंत्र है।

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

Comments

जो काफी मदद करता है। मैं देख सकता हूँ कि कैसे एक खेल में राक्षसों को समवर्ती रूप से यह तय करने में बहुत लाभ होगा कि वे आगे क्या करेंगे।

— मारियो टी। लांजा

Answer 4

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

बैंकिंग एप्लिकेशन में हम कभी भी राज्य के स्नैपशॉट पर एक निर्णय को आधार नहीं बनाना चाहेंगे जो तब से नए सिरे से जारी किया गया है (एक वापसी हुई)।

यह सम्‍मिलन आसान है क्‍योंकि एफपी प्रतिमान परस्पर स्‍थिति से बचता है एक तकनीकी दावा है जो संभावित रूप से पुरानी स्थिति पर आधारित निर्णयों के तार्किक गुणों के बारे में कुछ भी कहने का प्रयास नहीं करता है। एफपी अभी भी अंततः मॉडल राज्य परिवर्तन। इसके आसपास कोई नहीं मिल रहा है।

Answer 5

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

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

सीरियल एल्गोरिदम

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

आसान संगति

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

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

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

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

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

दुष्प्रभाव

उन्होंने कहा, मैं अपने कार्यात्मक दोस्तों (जो मुझे लगता है कि सुपर कूल हैं) के लिए सभी सम्मान के साथ एक हिस्से से असहमत हैं:

[...] क्योंकि उनके प्रतिमान परस्पर स्थिति से बचते हैं।

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

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

Comments

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

— स्टीव

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

— स्टीव

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

— स्टीव

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

softwareengineering.stackexchange.com/questions/203134/…