वास्तव में प्रक्रियात्मक और कार्यात्मक के बीच अंतर को समझना


114

मुझे वास्तव में प्रक्रियात्मक और कार्यात्मक प्रोग्रामिंग प्रतिमानों के बीच के अंतर को समझने में कठिन समय हो रहा है ।

यहां कार्यात्मक प्रोग्रामिंग पर विकिपीडिया प्रविष्टि से पहले दो पैराग्राफ हैं :

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

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

पैरा 2 में जहां यह कहता है

इसके विपरीत, कार्यात्मक कोड में, एक फ़ंक्शन का आउटपुट मान केवल उन तर्कों पर निर्भर करता है जो फ़ंक्शन के लिए इनपुट हैं, इसलिए किसी फ़ंक्शन fको किसी तर्क के लिए समान मान के साथ दो बार कॉल xकरने से f(x)दोनों बार एक ही परिणाम उत्पन्न होगा ।

प्रक्रियात्मक प्रोग्रामिंग के लिए वही सटीक मामला नहीं है?

एक प्रक्रियात्मक बनाम कार्यात्मक के लिए क्या देखना चाहिए जो बाहर खड़ा है?


1
Abafei से "आकर्षक पायथन: कार्यात्मक प्रोग्रामिंग पायथन में" लिंक टूट गया था। : यहाँ लिंक का एक अच्छा सेट है ibm.com/developerworks/linux/library/l-prog/index.html ibm.com/developerworks/linux/library/l-prog2/index.html
क्रिस Koknat

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

जवाबों:


276

कार्यात्मक प्रोग्रामिंग

कार्यात्मक प्रोग्रामिंग से तात्पर्य मूल्यों के रूप में कार्यों के उपचार की क्षमता से है।

आइए "नियमित" मूल्यों के साथ एक समानता पर विचार करें। हम दो पूर्णांक मान ले सकते हैं और +नए पूर्णांक प्राप्त करने के लिए ऑपरेटर का उपयोग करके उन्हें जोड़ सकते हैं । या हम एक फ्लोटिंग पॉइंट नंबर प्राप्त करने के लिए एक फ्लोटिंग पॉइंट नंबर से एक पूर्णांक गुणा कर सकते हैं।

कार्यात्मक प्रोग्रामिंग में, हम रचना या लिफ्ट जैसे ऑपरेटरों का उपयोग करके एक नया फ़ंक्शन मान बनाने के लिए दो फ़ंक्शन मानों को जोड़ सकते हैं । या हम मानचित्र या गुना जैसे ऑपरेटरों का उपयोग करके एक नया डेटा मान उत्पन्न करने के लिए एक फ़ंक्शन मान और डेटा मान को जोड़ सकते हैं ।

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

प्रक्रियात्मक प्रोग्रामिंग

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

कंट्रास्ट

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

function allOdd(words) {
  var result = true;
  for (var i = 0; i < length(words); ++i) {
    var len = length(words[i]);
    if (!odd(len)) {
      result = false;
      break;
    }
  }
  return result;
}

मैं इसे एक उदाहरण के रूप में समझूंगा। अब, कार्यात्मक शैली:

function allOdd(words) {
  return apply(and, map(compose(odd, length), words));
}

अंदर से बाहर की ओर काम करना, यह परिभाषा निम्नलिखित बातें करती है:

  1. compose(odd, length)एक नए फ़ंक्शन का उत्पादन करने के लिए संयोजन oddऔर lengthफ़ंक्शन करता है जो निर्धारित करता है कि क्या स्ट्रिंग की लंबाई विषम है।
  2. map(..., words)प्रत्येक तत्व के लिए उस नए फ़ंक्शन को कॉल करता है words, अंततः बूलियन मानों की एक नई सूची लौटाता है, प्रत्येक यह दर्शाता है कि संबंधित शब्द में विषम संख्या में वर्ण हैं या नहीं।
  3. apply(and, ...)परिणामी सूची में "और" ऑपरेटर को लागू करता है, और सभी बूलियन को अंतिम परिणाम देने के लिए एक साथ लागू करता है।

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

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

आगे की पढाई

यह सवाल बहुत सामने आता है ... उदाहरण के लिए देखें:

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

प्रोग्रामिंग वॉन न्यूमैन शैली से मुक्त किया जा सकता है?

मुझे वास्तव में उस पेपर का वर्तमान संदर्भ में उल्लेख नहीं करना चाहिए क्योंकि यह बहुत तकनीकी, बहुत जल्दी हो जाता है। मैं सिर्फ इसलिए विरोध नहीं कर सका क्योंकि मुझे लगता है कि यह वास्तव में मूलभूत है।


परिशिष्ट - २०१३

टीकाकार बताते हैं कि लोकप्रिय समकालीन भाषाएं प्रक्रियात्मक और कार्यात्मक से ऊपर और ऊपर प्रोग्रामिंग की अन्य शैलियों की पेशकश करती हैं। ऐसी भाषाएँ अक्सर निम्नलिखित प्रोग्रामिंग शैलियों में से एक या अधिक प्रस्तुत करती हैं:

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

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

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


1
वास्तव में अच्छा जवाब है, लेकिन क्या आप कोड को थोड़ा सा सरल कर सकते हैं, उदाहरण के लिए: "फ़ंक्शन allOdd (शब्द) {foreach (शब्दों में ऑटो शब्द) {विषम (लंबाई) (वापस लौटें;} गलत;} वापस लौटें?}"
Dainius

कार्यात्मक शैली में अजगर में "कार्यात्मक शैली" की तुलना में पढ़ने में काफी कठिन है: def odd_words (शब्द): वापसी [x को शब्दों में x के लिए यदि विषम (len (x))]
बॉक्सिंग करें

@ बॉक्सिंग: आपकी odd_words(words)परिभाषा उत्तर की तुलना में कुछ अलग करती है allOdd। फ़िल्टरिंग और मैपिंग के लिए, सूची समझ अक्सर पसंद की जाती है, लेकिन यहाँ फ़ंक्शन allOddको शब्दों की सूची को एकल बूलियन मान को कम करना है।
शिननोयर

@WReach: मैंने आपके कार्यात्मक उदाहरण इस तरह लिखे होंगे: फ़ंक्शन allOdd (शब्द) {वापसी और विषम (लंबाई (पहले (शब्द))), allOdd (बाकी (शब्द))); } यह आपके उदाहरण से अधिक सुरुचिपूर्ण नहीं है, लेकिन एक पूंछ-पुनरावर्ती भाषा में यह अनिवार्य शैली के समान प्रदर्शन विशेषताओं होगा।
मिशू

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

46

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

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


किसी भी तरह से आप कोड उदाहरण स्निपेट का उपयोग करके दो विपरीत कर सकते हैं? वास्तव में इसकी सराहना
Philoxopher

1
@KerxPhilo: यहाँ एक बहुत ही सरल कार्य है (1 से n में संख्याएँ जोड़ें)। इंपीरियल: वर्तमान संख्या को संशोधित करें, अब तक की राशि को संशोधित करें। कोड: int i, sum; योग = 0; for (i = 1; i <= n; i ++) {sum + = i; }। कार्यात्मक (हास्केल): संख्याओं की एक आलसी सूची लें, उन्हें शून्य में जोड़ते हुए एक साथ मोड़ें। कोड: foldl (+) 0 [1..n]। क्षमा करें, टिप्पणियों में कोई प्रारूपण नहीं है।
dirkt

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

12
     Isn't that the same exact case for procedural programming?

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

इसने कहा, ऐसे कोड लिखना संभव है जो प्रक्रियात्मक मानी जाने वाली भाषाओं में इस बाधा को संतुष्ट करते हैं। और ऐसा कोड लिखना भी संभव है जो कार्यात्मक मानी जाने वाली कुछ भाषाओं में इस बाधा को तोड़ता है।


1
क्या आप एक उदाहरण और तुलना दिखा सकते हैं? यदि आप कर सकते हैं तो सचमुच इसकी सराहना करें।
दार्शनिक

8
सी में रैंड () फ़ंक्शन हर कॉल के लिए एक अलग परिणाम प्रदान करता है। यह कॉल के बीच स्थिति संग्रहीत करता है। यह संदर्भित रूप से पारदर्शी नहीं है। इसकी तुलना में, C ++ में std :: max (a, b) हमेशा एक ही तर्क दिए गए परिणाम को लौटाएगा, और इसका कोई साइड-इफ़ेक्ट (जो मुझे पता है ...) है।
एंडी थॉमस

11

मैं WReach के जवाब से असहमत हूं। आइए उनके जवाब को थोड़ा विचलित करते हुए देखें कि असहमति कहां से है।

सबसे पहले, उसका कोड:

function allOdd(words) {
  var result = true;
  for (var i = 0; i < length(words); ++i) {
    var len = length(words[i]);
    if (!odd(len)) {
      result = false;
      break;
    }
  }
  return result;
}

तथा

function allOdd(words) {
  return apply(and, map(compose(odd, length), words));
}

ध्यान देने वाली पहली बात यह है कि वह कबूल कर रहा है:

  • कार्यात्मक
  • अभिव्यक्ति उन्मुख और
  • इटरेटर सेंट्रिक

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

आइये जल्दी इन पर बात करते हैं।

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

lengths: map words length
each_odd: map lengths odd
all_odd: reduce each_odd and

यह बहुत पहले के रूप में ही दिया गया है, कार्यों को छोड़कर शुद्ध रूप से बयानों और बाइंडिंग की श्रृंखला के माध्यम से जंजीर है।

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

def all_odd(words):
    lengths = (len(word) for word in words)
    each_odd = (odd(length) for length in lengths)
    return all(each_odd)

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

बेशक, आप इसे संपीड़ित कर सकते हैं:

def all_odd(words):
    return all(odd(len(word)) for word in words)

अब इम्पीरियल इतना बुरा नहीं दिखता है, एह? :)

अंतिम बिंदु अधिक स्पष्ट नियंत्रण प्रवाह के बारे में था। आइए इसका उपयोग करने के लिए मूल कोड को फिर से लिखें:

function allOdd(words) {
    for (var i = 0; i < length(words); ++i) {
        if (!odd(length(words[i]))) {
            return false;
        }
    }
    return true;
}

पुनरावृत्तियों का उपयोग आप कर सकते हैं:

function allOdd(words) {
    for (word : words) { if (!odd(length(word))) { return false; } }
    return true;
}

यदि अंतर हो तो एक कार्यात्मक भाषा का क्या मतलब है:

return all(odd(len(word)) for word in words)
return apply(and, map(compose(odd, length), words))
for (word : words) { if (!odd(length(word))) { return false; } }
return true;


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

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

जब आपके पास एक कार्यात्मक भाषा होती है, तो नए कार्य करना आम तौर पर निकट-संबंधित कार्यों की रचना के रूप में सरल होता है।

all = partial(apply, and)

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


तुम्हें पता है, मुझे पूरा यकीन है कि applyयह काफी समान ऑपरेशन नहीं है foldया reduce, हालांकि मैं बहुत सामान्य एल्गोरिदम की अच्छी क्षमता से सहमत हूं।
बेनेडिक्ट ली

मैंने कभी applyइसका मतलब नहीं सुना है foldया reduce, लेकिन यह मुझे इस तरह दिखता है कि इसे इस संदर्भ में होना चाहिए ताकि यह एक बूलियन वापस कर सके।
विड्राक

आह, ठीक है, मैं नामकरण से भ्रमित हो गया। इसे क्लीयर करने के लिए शुक्रिया।
बेनेडिक्ट ली

6

प्रक्रियात्मक प्रतिमान में (क्या मैं इसके बजाय "संरचित प्रोग्रामिंग" कहूंगा?), आपने पारस्परिक स्मृति और निर्देशों को साझा किया है जो इसे कुछ अनुक्रम में पढ़ते / लिखते हैं (एक के बाद एक)।

कार्यात्मक प्रतिमान में, आपके पास चर और कार्य होते हैं (गणितीय अर्थ में: चर समय के साथ भिन्न नहीं होते हैं, कार्य केवल उनके इनपुट के आधार पर कुछ गणना कर सकते हैं)।

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


2

चार्मिंग पायथन: आईबीएम डेवलपरवर्क से पायथन में कार्यात्मक प्रोग्रामिंग ने मुझे अंतर को समझने में मदद की।

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


2

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

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


1

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


0

दो प्रोग्रामिंग प्रतिमानों के बीच एक स्पष्ट अंतर राज्य है।

कार्यात्मक प्रोग्रामिंग में, राज्य से बचा जाता है। सीधे शब्दों में कहें, तो कोई ऐसा चर नहीं होगा जिसे एक मान दिया जाए।

उदाहरण:

def double(x):
    return x * 2

def doubleLst(lst):
    return list(map(double, action))

हालाँकि, प्रक्रियात्मक प्रोग्रामिंग राज्य का उपयोग करता है।

उदाहरण:

def doubleLst(lst):
    for i in range(len(lst)):
        lst[i] = lst[i] * 2  # assigning of value i.e. mutation of state
    return lst
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.