कार्यात्मक प्रोग्रामिंग के लिए पायथन बहुत अच्छा क्यों नहीं है? [बन्द है]


324

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


2
2018 - नारियल (एक कार्यात्मक प्रोग्रामिंग भाषा जो पायथन को संकलित करता है) पायथन में कार्यात्मक प्रोग्रामिंग को बढ़ाता है। भी से आईबीएम लेख की इस श्रृंखला देखें पृष्ठ 1 पृष्ठ 2 पृष्ठ 3
cssyphus

जवाबों:


393

आपके द्वारा संदर्भित प्रश्न पूछता है कि कौन सी भाषाएं ओओ और कार्यात्मक प्रोग्रामिंग दोनों को बढ़ावा देती हैं। पायथन कार्यात्मक प्रोग्रामिंग को बढ़ावा नहीं देता, भले ही यह काफी अच्छी तरह से काम करता हो

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

जो यह कहना नहीं है कि यह बुरा है, बस यह कि आपको उससे अधिक कठिन परिश्रम करना होगा यदि आप एक ऐसी भाषा पर स्विच करते हैं जो कार्यात्मक प्रोग्रामिंग को बढ़ावा देती है या OO पायथन को लिखने के लिए स्विच किया जाता है।

यहाँ पायथन में याद की जाने वाली कार्यात्मक चीजें हैं:


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

5
लापता पूंछ पुनरावृत्ति के लिए +1 - हालांकि लूपिंग निर्माणों ने इसे छोड़ दिया है, फिर भी पायथन और स्कीम के बीच लापता होने लायक कुछ है।
new123456

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

4
अच्छी बात; मुझे लगता है कि समाधान लिंक जोड़ना है। क्या मेरे उत्तर को संपादित करने के लिए आपके पास पर्याप्त प्रतिनिधि है? यदि ऐसा है तो विभिन्न अवधारणाओं से लिंक जोड़ने के लिए स्वतंत्र महसूस करें। मैं तब शुरू करूंगा जब मेरे पास समय होगा।
नाथन श्लीट-सैंडर्स

5
मुझे लगता है कि यह 5 साल पुराना है, लेकिन ... ऐसा लगता है कि यह उन चीजों के बारे में अधिक है जो आपको हास्केल से याद आती हैं , न कि कार्यात्मक भाषाओं से । उदाहरण के लिए, अधिकांश एमएल और लिस्प बोलियों और वंशजों में स्वचालित करी नहीं होती है, बिंदु मुक्त शैली को अत्यधिक क्रिया बनाते हैं, आलसी सूची नहीं होती है, आदि, इसलिए, यदि आलसी सूचियों के बजाय पुनरावृत्त पायथन को एक खराब भाषा बनाते हैं, तो ही CaML को एक भयानक कार्यात्मक भाषा बनाना चाहिए ?
अपहरण

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

102

गुइडो की यहाँ अच्छी व्याख्या है । यहाँ सबसे प्रासंगिक हिस्सा है:

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

...

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

अंत में, भले ही कई कार्यात्मक प्रोग्रामिंग सुविधाओं को पिछले कुछ वर्षों में पेश किया गया हो, लेकिन पायथन में अभी भी "वास्तविक" कार्यात्मक प्रोग्रामिंग भाषाओं में पाई गई कुछ विशेषताओं का अभाव है। उदाहरण के लिए, पायथन कुछ प्रकार के अनुकूलन (जैसे, पूंछ पुनरावृत्ति) नहीं करता है। सामान्य तौर पर, क्योंकि पायथन की अत्यंत गतिशील प्रकृति, हास्केल या एमएल जैसी कार्यात्मक भाषाओं से ज्ञात संकलन प्रकार का अनुकूलन करना असंभव है। और यह ठीक है।

मैं इसमें से दो चीजें खींचता हूं:

  1. भाषा का निर्माता वास्तव में पायथन को एक कार्यात्मक भाषा नहीं मानता है। इसलिए, "कार्यात्मक-एस्क" सुविधाओं को देखना संभव है, लेकिन आप निश्चित रूप से कार्यात्मक कुछ भी देखने की संभावना नहीं रखते हैं।
  2. पायथन की गतिशील प्रकृति आपके द्वारा अन्य कार्यात्मक भाषाओं में देखी गई कुछ अनुकूलन को रोकती है। दी, लिस्प केवल पायथन के रूप में गतिशील (यदि अधिक गतिशील नहीं है) है, तो यह केवल एक आंशिक स्पष्टीकरण है।

8
आप पायथन में टेल कॉल ऑप्टिमाइज़ेशन को ठीक कर सकते हैं। Guido समझ में नहीं आता है / नहीं है।
जूल्स

26
यह करने के लिए कि गुइडो van Rossum नीचे उबालने के लिए लगता है doesn't_like कार्यात्मक शैली।
स्वेन्ते

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

8
"दी, लिस्प बस गतिशील है" -> और बस के रूप में जरूरी है!
pyon

6
@ जूल्स, क्या आपको पायथन में टेल कॉल ऑप्टिमाइज़ेशन के उपयोग के लिए एक दिशानिर्देश साझा करने का मन है? कुछ स्रोत के लिए एक सूचक उपयोगी होगा।
डेविड शेख

52

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

  1. अपंग मेमदास। चूंकि लैम्ब्डा में केवल एक अभिव्यक्ति हो सकती है, और आप एक अभिव्यक्ति के संदर्भ में सब कुछ आसानी से नहीं कर सकते हैं, इसका मतलब है कि जिन कार्यों को आप "मक्खी पर" परिभाषित कर सकते हैं वे सीमित हैं।

  2. यदि कथन कथन हैं, तो भाव नहीं। इसका मतलब है, अन्य चीजों के अलावा, अगर आपके अंदर यह एक लैम्ब्डा नहीं हो सकता है। (यह अजगर 2.5 में टर्नरीज़ द्वारा तय किया गया है, लेकिन यह बदसूरत दिखता है।)

  3. गुइडो ने एक बार में ही नक्शे को हटाने, फ़िल्टर करने और हर बार कम करने की धमकी दी

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


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

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

7
मानचित्र और फ़िल्टर को सूची समझ से बदल दिया जाता है। कम - लगभग हमेशा - यह इतना अक्षम है कि इसे जनरेटर फ़ंक्शन के साथ बदल दिया जाना चाहिए।
S.Lott

13
@ S.Lott कैसे आप एक जनरेटर के साथ कम की जगह है?
एंटीमनी

17
@ जेकब बी लिस्ट की समझ कार्यात्मक भाषाओं में उपलब्ध थी पायथन का आविष्कार होने के लगभग 15 साल पहले और पाइथन के 25 साल पहले फीचर को लागू करने से पहले। यह विचार कि पायथन ने उनके प्रसार को प्रभावित किया है, या कि fp ने पायथन से यह सीखा है, या यहां तक ​​कि यह कि यह fp दुनिया में लोकप्रियता है, जो पायथन के कार्यान्वयन के बाद की तारीखों में गलत है। पायथन का कार्यान्वयन सीधे हास्केल से लिया गया था। हो सकता है कि मैंने आपको गलत समझा हो और आपका मतलब यह नहीं था, लेकिन मैं "कार्यात्मक लोगों को सूची बोध की अजीबता के लिए जागना शुरू कर रहा हूं" से हैरान हूं ।
इसका जुलूस 14:18 बजे

23

मैं पायथन को कभी भी "कार्यात्मक" नहीं कहूंगा, लेकिन जब भी मैं पायथन में कार्यक्रम करता हूं तो कोड लगभग पूरी तरह कार्यात्मक हो जाता है।

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


17

मुझे SO पर "कार्यात्मक" पायथन प्रश्न के उत्तर से लिए गए कोड के एक टुकड़े के साथ प्रदर्शित करें

अजगर:

def grandKids(generation, kidsFunc, val):
  layer = [val]
  for i in xrange(generation):
    layer = itertools.chain.from_iterable(itertools.imap(kidsFunc, layer))
  return layer

हास्केल:

grandKids generation kidsFunc val =
  iterate (concatMap kidsFunc) [val] !! generation

यहां मुख्य अंतर यह है कि हास्केल के मानक पुस्तकालय में कार्यात्मक प्रोग्रामिंग के लिए उपयोगी कार्य हैं: इस मामले iterateमें concat, और(!!)


7
यहाँ grandKids()जनरेटर अभिव्यक्ति के साथ शरीर के लिए एक-पंक्ति प्रतिस्थापन है return reduce(lambda a, v: concat((x for x in kidsFunc(v)) for v in a), xrange(generation), [val]):।
ललकी

6
और यहाँ एक है जिसकी concatया तो आवश्यकता नहीं है :return reduce(lambda a, v: (x for v in a for x in kidsFunc(v)), xrange(generation), [val])
ललकी

9
@Lloeki: iterate उस कोड को काफी सरल करेगा, और बच्चों के लिए x में v के लिए x (v) बच्चों के लिए funMap (KidsFunc) के रूप में अधिक स्पष्ट है। पायथन की अच्छी उच्च-ऑर्डर बिल्डिंग्स की कमी हस्केल की तुलना में समतुल्य कोड क्रिप्टिक और वर्बोज़ बनाती है।
फोब

2
कॉनकैट द्वारा प्रतिस्थापित किया जा सकता हैitertools.chain.from_iterable
एंटीमनी

@Antimony: अच्छा पता है। thx
yairchu

14

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

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

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

मैं कार्यात्मक प्रोग्रामिंग की सबसे महत्वपूर्ण विशेषताओं के रूप में निम्नलिखित को रैंक करूंगा: ए) संदर्भात्मक पारदर्शिता - यदि आप किसी अन्य समय और स्थान पर एक ही कथन का मूल्यांकन करते हैं, लेकिन समान चर मूल्यों के साथ, इसका मतलब अभी भी समान होगा। बी) कोई साइड इफेक्ट नहीं - जब तक आप व्हाइटबोर्ड को घूरते नहीं हैं, तो एक और आदमी जो दूसरे व्हाइटबोर्ड को देख रहा है, वह दुर्घटना परिवर्तन नहीं करेगा। c) फ़ंक्शन भी मान हैं। जिसे चारों ओर से पारित किया जा सकता है और अन्य चर के साथ या उसके साथ लागू किया जा सकता है। d) फंक्शन कंपोजिशन, आप h = g · f कर सकते हैं और इस प्रकार एक नए फंक्शन h (..) को परिभाषित करते हैं, जो कि कॉलिंग g (f (..)) के बराबर है।

यह सूची मेरे प्राथमिकता वाले क्रम में है, इसलिए संदर्भात्मक पारदर्शिता सबसे महत्वपूर्ण है, जिसके बाद कोई साइड इफेक्ट नहीं है।

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


2
पायथन में फ़ंक्शंस प्रथम श्रेणी के हैं।
कार्ल स्मिथ

@CarlSmith वह एक, लेकिन पायथन के पास 3/4 नहीं है। : - \
आर्य

1
मुझे नहीं लगता कि कार्यात्मक प्रोग्रामिंग के लिए पायथन एक अच्छी भाषा है। मुझे अब यकीन भी नहीं हो रहा है कि उस टिप्पणी से मेरा क्या मतलब है। यह उत्तर के लिए प्रासंगिक नहीं लगता है। मैं इसे हटा दूंगा, लेकिन तब आपकी टिप्पणी संदर्भ से बाहर होगी।
कार्ल स्मिथ 14

1
प्रासंगिक पारदर्शिता और अपरिवर्तनशीलता वास्तव में भाषा की विशेषताएं नहीं हैं। हां, कुछ भाषाएं (हास्केल) उन पर जोर देती हैं और उन्हें न करने के लिए कठिन बनाती हैं, लेकिन आप अनिवार्य रूप से किसी भी भाषा में एक संदर्भित पारदर्शी फ़ंक्शन या एक अपरिवर्तनीय वस्तु बना सकते हैं। आपको बस मानक पुस्तकालय के आसपास काम करना होगा, जो अक्सर उनका उल्लंघन करेगा।
केविन

इसके अलावा, पायथन को करी और रचना दोनों के लिए समर्थन है, लेकिन भाषा के स्तर पर नहीं, यह इसके बजाय मानक पुस्तकालय में है।
केविन

10

अजगर लगभग एक कार्यात्मक भाषा है। यह "कार्यात्मक लाइट" है।

इसकी अतिरिक्त विशेषताएं हैं, इसलिए यह कुछ के लिए पर्याप्त शुद्ध नहीं है।

इसमें कुछ विशेषताओं का भी अभाव है, इसलिए यह कुछ के लिए पर्याप्त नहीं है।

लापता सुविधाओं को लिखना आसान है। पायथन में एफपी पर इस तरह की पोस्ट देखें ।


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

8
-1 क्षमा करें, नहीं। मेरा मतलब है, बस, नहीं। कार्यात्मक भाषाएं ऐसे निर्माण प्रदान करती हैं जो औपचारिक तर्क की सुविधा प्रदान करते हैं: आगमनात्मक (एमएल), समान (हास्केल)। क्लोजर और अनाम फ़ंक्शन अकेले रणनीति पैटर्न के लिए सिंटैक्टिक चीनी हैं।
pyon

8

ऊपर उल्लेखित एक अन्य कारण यह नहीं है कि अंतर्निहित प्रकार के कई अंतर्निहित फ़ंक्शन और विधियाँ किसी ऑब्जेक्ट को संशोधित करती हैं, लेकिन संशोधित ऑब्जेक्ट को वापस नहीं करती हैं। यदि उन संशोधित वस्तुओं को वापस कर दिया गया, तो यह कार्यात्मक कोड क्लीनर और अधिक संक्षिप्त बना देगा। उदाहरण के लिए, अगर some_list.append (some_object) some_list लौट आए, जिसमें कुछ_object जोड़ा गया है।


4

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

वैसे भी यह पता चला है कि के map( foo() , x ) * map( foo(), y )रूप में ही है map( foo(), x * y )। उत्तरार्द्ध मामला वास्तव में पूर्व की तुलना में तेज है क्योंकि पूर्व दो प्रतियां करता है जहां बाद वाला एक प्रदर्शन करता है।

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


map( foo() , x ) * map( foo(), y ) == map( foo(), x * y )सभी कार्यों के लिए सही नहीं है। उदाहरण के लिए, fooएक व्युत्पन्न की गणना करते समय मामले पर विचार करें ।
एली कोरविगो

1
मुझे लगता है कि वह +इसके बजाय मतलब था *
user1747134

आप मान रहे हैं फू () रैखिक है?
जुआन इज़ाज़ा

यह गुण foo (x) = x + 1 के लिए सही नहीं है। जैसे (x + 1) * (y + 1)! = X * y + 1.
juan Isaza
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.