परस्पर क्रियाशील अवस्था बनाए रखने वाली कार्यात्मक भाषा में कुछ भी गलत नहीं है। यहां तक कि "शुद्ध" कार्यात्मक भाषाओं जैसे हास्केल को वास्तविक दुनिया के साथ बातचीत करने के लिए राज्य बनाए रखने की आवश्यकता है। क्लॉजुर जैसी "प्रभावशाली" कार्यात्मक भाषाएं साइड इफेक्ट की अनुमति देती हैं जिसमें उत्परिवर्तन राज्य शामिल हो सकते हैं।
मुख्य बिंदु यह है कि कार्यात्मक भाषाएं उत्परिवर्तनीय स्थिति को हतोत्साहित करती हैं जब तक कि आपको वास्तव में इसकी आवश्यकता न हो । सामान्य शैली शुद्ध कार्यों और अपरिवर्तनीय डेटा का उपयोग करके प्रोग्राम करना है, और केवल आपके कोड के विशिष्ट भागों में "अशुद्ध" उत्परिवर्तित स्थिति के साथ बातचीत करना है। इस तरह, आप अपने बाकी कोड बेस को "शुद्ध" रख सकते हैं।
मुझे लगता है कि कार्यात्मक भाषाओं में एसटीएम अधिक सामान्य है, इसके कई कारण हैं:
- अनुसंधान : एसटीएम एक गर्म अनुसंधान विषय है, और प्रोग्रामिंग भाषा शोधकर्ता अक्सर कार्यात्मक लानुगेस (स्वयं में एक खोज विषय) के साथ काम करना पसंद करते हैं, साथ ही कार्यक्रम के व्यवहार के बारे में "प्रमाण" बनाना आसान है)
- लॉक कंपोज नहीं करें : एसटीएम को कॉन्टेक्स्ट के लॉक-आधारित एप्रोच के विकल्प के रूप में देखा जा सकता है, जो विभिन्न कंपोनेंट्स को कंपाइल करके जटिल सिस्टम को स्केल करने पर समस्याओं में आने लगता है। यह यकीनन एसटीएम के लिए मुख्य "व्यावहारिक" कारण है
- एसटीएम अपरिवर्तनीयता के साथ अच्छी तरह से फिट बैठता है : यदि आपके पास एक बड़ी अपरिवर्तनीय संरचना है, तो आप यह सुनिश्चित करना चाहते हैं कि यह अपरिवर्तनीय रहे, इसलिए आप नहीं चाहते कि कोई अन्य धागा अंदर आए और कुछ उप-तत्व को बदल दे। इसी तरह, यदि आप उक्त डेटा संरचना की अपरिवर्तनीयता की गारंटी दे सकते हैं, तो आप अपने एसटीएम सिस्टम में एक स्थिर "मूल्य" के रूप में विश्वास कर सकते हैं।
मैं व्यक्तिगत रूप से क्लोजर को अनुमति देने के दृष्टिकोण के बारे में पसंद करता हूं, लेकिन केवल कड़ाई से नियंत्रित "प्रबंधित संदर्भ" के संदर्भ में जो एसटीएम लेनदेन में भाग ले सकता है। भाषा में बाकी सब कुछ "विशुद्ध रूप से कार्यात्मक" है।
;; define two accounts as managed references
(def account-a (ref 100))
(def account-b (ref 100))
;; define a transactional "transfer" function
(defn transfer [ref-1 ref-2 amount]
(dosync
(if (>= @ref-1 amount)
(do
(alter ref-1 - amount)
(alter ref-2 + amount))
(throw (Error. "Insufficient balance!")))))
;; make a stranfer
(transfer account-a account-b 75)
;; inspect the accounts
@account-a
=> 25
@account-b
=> 175
ध्यान दें कि उपरोक्त कोड पूरी तरह से लेन-देन और परमाणु है - एक बाहरी पर्यवेक्षक जो दूसरे लेनदेन के भीतर दो शेष राशि को पढ़ता है, उसे हमेशा एक सुसंगत परमाणु स्थिति दिखाई देगी, अर्थात दो शेष राशि हमेशा 200 के योग होंगी। लॉक-आधारित संगामिति के साथ, यह आश्चर्यजनक रूप से कठिन समस्या है। कई जटिल संस्थाओं के साथ एक बड़ी जटिल प्रणाली में हल करने के लिए।
कुछ अतिरिक्त ज्ञानोदय के लिए, रिच हिकी इस वीडियो में क्लजुरे के एसटीएम को समझाने का एक उत्कृष्ट काम करता है