आधुनिक मुख्यधारा की प्रोग्रामिंग भाषाओं में लैम्ब्डा कार्यों की लोकप्रियता क्या शुरू हुई?


112

पिछले कुछ वर्षों में अनाम फ़ंक्शंस (AKA lambda फ़ंक्शंस) एक बहुत ही लोकप्रिय भाषा निर्माण बन गए हैं और लगभग हर प्रमुख / मुख्यधारा प्रोग्रामिंग भाषा ने उन्हें पेश किया है या उन्हें मानक के आगामी संशोधन में पेश करने की योजना है।

फिर भी, अनाम कार्य गणित और कंप्यूटर विज्ञान में एक बहुत पुरानी और बहुत प्रसिद्ध अवधारणा है (1936 के आसपास गणितज्ञ अलोंजो चर्च द्वारा आविष्कार किया गया था, और 1958 से लिस्प प्रोग्रामिंग भाषा द्वारा उपयोग किया जाता है, उदाहरण के लिए यहां देखें )।

तो आज की मुख्यधारा की प्रोग्रामिंग भाषाओं (जिनमें से कई 15 से 20 साल पहले उत्पन्न हुई थीं) ने शुरुआत से ही लंबोदर कार्यों का समर्थन किया और केवल बाद में पेश किया?

और पिछले कुछ वर्षों में अनाम कार्यों के बड़े पैमाने पर अपनाने से क्या हुआ? क्या कोई विशिष्ट घटना, नई आवश्यकता या प्रोग्रामिंग तकनीक है जिसने इस घटना को शुरू किया है?

महत्वपूर्ण लेख

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

कृपया "कार्यात्मक प्रतिमान को अपनाने और इसके लाभों" के बारे में बोलकर अपने उत्तरों को अधिक न करें, क्योंकि यह सवाल का विषय नहीं है।


7
15-20 साल पहले लोग OO के बारे में एक ही सवाल पूछ रहे थे ... यह एक नई अवधारणा नहीं थी, लेकिन इसमें लोकप्रियता का विस्फोट था।
मैटवेवी

7
@MattDavey सबसे निश्चित रूप से असहमत होंगे, लेकिन फिर मुझे उन्हें याद दिलाना होगा कि "अधिकांश स्मॉलटाक डेवलपर्स" वास्तव में बहुत से लोग नहीं हैं; पी
यानिस

30
मुझे लगता है कि अधिक दिलचस्प सवाल यह है कि उनके निधन से क्या हुआ ! सब के बाद, वहाँ, एक समय था जब सबसे आधुनिक भाषाओं किया lambdas, तो जावा और सी ++ जैसी भाषाओं लोकप्रिय हो गया। (हालांकि मैं जावा को "आधुनिक" भाषा नहीं कहूंगा। जावा में सबसे आधुनिक अवधारणा जेनेरिक है, जो 60 के दशक के अंत / 70 के दशक की शुरुआत तक है। यहां तक ​​कि जावा के फीचर, पॉइंटर सेफ्टी, मेमोरी सेफ्टी, टाइप का संयोजन सुरक्षा, जीसी, सांख्यिकीय रूप से टाइप किए गए OO, जेनरिक सभी 1985 में एफिल में मौजूद थे ... और बहुत बेहतर, IMHO।)
जॉर्ग डब्ल्यू मित्तग

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

8
"एक छोटा सा" अक्सर 50% फ़ंक्शन, 50% शोर का मतलब है।
केविन क्लाइन

जवाबों:


86

कार्यात्मक प्रोग्रामिंग या इसके कम से कम कुछ पहलुओं के प्रति निश्चित रूप से ध्यान देने योग्य प्रवृत्ति है। कुछ लोकप्रिय भाषाएं जो कुछ बिंदु पर अपनाई गईं अनाम फ़ंक्शंस हैं C ++ ( C ++ 11 ), PHP ( PHP 5.3.0 ), C # ( C # v2.0 ), डेल्फी (2009 से), ऑब्जेक्टिव C ( ब्लॉक ) जबकि Java 8 लैम्बदास को भाषा के लिए समर्थन लाएगा । और ऐसी लोकप्रिय भाषाएं हैं जिन्हें आमतौर पर शुरू से ही कार्यात्मक या समर्थित अनाम कार्यों में नहीं माना जाता है, या कम से कम जल्दी, चमकदार उदाहरण जावास्क्रिप्ट है।

सभी रुझानों के साथ, किसी एक घटना की तलाश करने की कोशिश करना, जो उन्हें उकसाता है, शायद समय की बर्बादी है, यह आमतौर पर कारकों का एक संयोजन है, जिनमें से अधिकांश मात्रात्मक नहीं हैं। 2005 में प्रकाशित प्रैक्टिकल कॉमन लिस्प , ने संभवतः प्रैक्टिकल लैंग्वेज के रूप में लिस्प पर नया ध्यान लाने में महत्वपूर्ण भूमिका निभाई होगी , क्योंकि कुछ समय के लिए लिस्प ज्यादातर एक अकादमिक सेटिंग, या बहुत विशिष्ट आला बाजारों में मिलने वाली भाषा थी । जावास्क्रिप्ट की लोकप्रियता ने अनाम कार्यों पर नया ध्यान लाने में भी महत्वपूर्ण भूमिका निभाई हो सकती है, जैसा कि उनके उत्तर में शानदार बताते हैं ।

बहुउद्देश्यीय भाषाओं से कार्यात्मक अवधारणाओं को अपनाने के अलावा, कार्यात्मक (या अधिकतर कार्यात्मक) भाषाओं की ओर भी ध्यान देने योग्य बदलाव है। Erlang (1986), Haskell (1990), OCaml (1996), Scala (2003), F # (2005), Clojure (2007), और यहां तक ​​कि R (1993) जैसी डोमेन विशिष्ट भाषाओं जैसी भाषाओं का जोरदार ढंग से अनुसरण किया गया लगता है उनके परिचय के बाद। सामान्य प्रवृत्ति ने पुरानी कार्यात्मक भाषाओं पर ध्यान दिया है, जैसे स्कीम (1975), और जाहिर तौर पर कॉमन लिस्प।

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

जोएल स्पोलस्की ने एक बहुत ही दिलचस्प ब्लॉग पोस्ट, द पेरिल्स ऑफ़ जावास्कूल , लिखा है , जहाँ वह (तब) विश्वविद्यालयों की प्रवृत्ति के खिलाफ जावा को दूसरे के पक्ष में करने के लिए तर्क देता है, शायद भाषा सीखने में अधिक मुश्किल है। यद्यपि ब्लॉग पोस्ट का कार्यात्मक प्रोग्रामिंग के साथ बहुत कम संबंध है, यह एक प्रमुख मुद्दे की पहचान करता है:

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

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

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

संबंधित सवाल:

आगे की पढाई:


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


2
@YannisRizos: पर्ल की अनाम रिलीज़ 5 (1994) की पहली रिलीज़ के बाद से थी, लेकिन वे 5.004 (1997) तक पूरी तरह से "सही" नहीं थे।
ब्लरफ्ल

1
: @penartur यही कारण है कि मैं भी सोचा, लेकिन एक दोस्ताना संपादक मुझे मुझे यहाँ इंगित करके सही किया है msdn.microsoft.com/en-us/library/0yw3tz5k%28v=vs.80%29.aspx
yannis

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

32

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

मुझे आश्चर्य है कि अगर यह जावास्क्रिप्ट के अचानक वृद्धि के लिए नहीं था तो लोकप्रिय कार्यात्मक भाषाएं / विशेषताएं कैसे होंगी।


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

8
@ जियोर्जियो - कई अन्य कार्यात्मक प्रोग्रामिंग भाषाएं हो सकती हैं, लेकिन (अपेक्षाकृत) कोई भी उनका उपयोग नहीं करता है। जेएस का उपयोग और यह देखने में वृद्धि हुई कि फंक्शनलर्स बनाने का C ++ / Java तरीका दर्दनाक है और कष्टप्रद है, वास्तव में मुख्य धारा की ड्राइविंग ताकतें हैं, भले ही अधिक अकादमिक भाषाएं इस बात से प्रभावित हों कि उन्हें कैसे लागू किया जाना चाहिए।
तेलस्टिन

1
सामान्य रूप में गतिशील भाषाओं की लोकप्रियता हास्केल की लोकप्रियता के लिए एक स्पष्टीकरण के रूप में की ओर संकेत किया गया है: book.realworldhaskell.org/read/...
Yannis

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

@ जियोर्जियो - वे जावा शैली के फंक्शनलर्स के विपरीत लागू करने के लिए अधिक परेशान करने वाले हैं। ज्ञान / गोद की कमी के साथ संयोजन करें और यह एक बहुत स्पष्ट डिजाइन विकल्प है।
तेलस्टिन

27

जावास्क्रिप्ट और डोम इवेंट हैंडलर का मतलब था कि लाखों प्रोग्रामर को वेब पर किसी भी तरह की अन्तरक्रियाशीलता करने के लिए प्रथम श्रेणी के कार्यों के बारे में कम से कम कुछ सीखना था

वहाँ से, यह गुमनाम कार्यों के लिए एक अपेक्षाकृत छोटा कदम है । क्योंकि जावास्क्रिप्ट बंद नहीं होता है this, यह आपको दृढ़ता से भी बंद के बारे में जानने के लिए प्रोत्साहित करता है। और फिर तुम सुनहरे हो: तुम अनाम प्रथम श्रेणी के कार्यों को समझते हो जो कि शल्कीय परिधि को घेरते हैं।

एक बार जब आप इसके साथ सहज हो जाते हैं, तो आप इसे हर उस भाषा में चाहते हैं जिसका आप उपयोग करते हैं।


7
+1 यह केवल अनाम कार्यों के बारे में नहीं है। एक अस्थायी फ़ंक्शन इनलाइन को परिभाषित करने की तुलना में क्लोज़र एक बहुत व्यापक अवधारणा है।
फकहलर

@ फकहलर: आप सही कह रहे हैं और इस अर्थ में, जावा में पहले से ही क्लोजर हैं (और जो आपको एक फ़ंक्शन शाब्दिक के साथ मिलता है उससे भी अधिक शक्तिशाली) लेकिन इसमें एक-विधि अनाम वर्ग के सामान्य मामले के लिए एक संक्षिप्त अंकन का अभाव है।
जियोर्जियो

17

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

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

लेकिन ब्लॉक सिंटैक्स और जिस तरह से यह .each, .map, .reduce और इसके साथ एकीकृत होता है, एक अनाम फ़ंक्शन के विचार को पॉप्युलेट करता है, भले ही यह वास्तव में एक सिंटैक्टिक निर्माण हो जो कोरटाइन की तरह व्यवहार करता है। और के माध्यम से एक खरीद के लिए आसान रूपांतरण और यह कार्यात्मक प्रोग्रामिंग के लिए एक प्रवेश द्वार दवा बनाता है।

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

टीएल; डीआर: रूबी, रेल्स, जावास्क्रिप्ट, ब्लॉगिंग, और रेडिट / हैकर न्यूज़ / स्टैक ओवरफ्लो ने कार्यात्मक विचारों को एक बड़े बाजार में धकेल दिया, इसलिए हर कोई मौजूदा दोषों को रोकने के लिए उन्हें मौजूदा भाषाओं में चाहता था।


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

2
मैं वास्तव में यही कारण है कि हाल के वर्षों में ज्यादातर भाषाओं ने ब्लॉक सिंटैक्स को लागू किया है। लेकिन यह सुनिश्चित करने का एकमात्र तरीका है कि वह भाषा डेवलपर्स से पूछें कि उनके उद्देश्य क्या थे। हम केवल imo का अनुमान लगा सकते हैं।
SpoBo

मेरे लिए, रूबी वह भाषा है जिसने पहले ब्लॉक रॉक और बहुत आकर्षक बनाया, इसलिए +1। हास्केल का भी प्रभाव हो सकता है।
रोज़गारपैक

13

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

कार्यात्मक प्रोग्रामिंग का नक्शा / फ़िल्टर / कम करने की शैली समानांतरकरण के लिए बहुत अनुकूल है, जिससे प्रोग्रामर आसानी से कई कोर का उपयोग कर सकता है, बिना किसी स्पष्ट थ्रेडिंग कोड को लिखे।

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

समवर्ती प्रोग्रामिंग को सरल बनाने के लिए एक भाषा में उच्च-क्रम के कार्यों को जोड़ना एक महत्वपूर्ण कदम है।

अपडेट करें

लोकी द्वारा बताई गई चिंताओं को दूर करने के लिए मैं कुछ और विस्तृत उदाहरण जोड़ूंगा।

निम्नलिखित सी # कोड पर विचार करें जो विजेट्स के संग्रह का पता लगाता है, जो विजेट की कीमतों की एक नई सूची बनाता है।

List<float> widgetPrices;
    float salesTax = RetrieveLocalSalesTax();
foreach( Widget w in widgets ) {
    widgetPrices.Add( CalculateWidgetPrice( w, salesTax ) );
}

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

एक बार उच्च-क्रम वाले कार्यों को C # में शामिल करने पर समाधान पर विचार करें:

var widgetPrices = widgets.Select( w=> CalculateWidgetPrice( w, salesTax ) );

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

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

Linq के विकल्प के रूप में PLINQ प्रदान करके C # इसे संबोधित करता है। ऐसा लगेगा:

var widgetPrices = widgets.AsParallel().Select(w => CalculateWidgetPrice( w, salesTax) );

जो उन तंत्रों के स्पष्ट प्रबंधन के बिना आपके सिस्टम के सभी कोर का पूर्ण उपयोग करता है।


मैं अधिक समानांतर और समवर्ती प्रसंस्करण की इच्छा की ओर इशारा करता हूं, यह "ए हिरांग का इतिहास" एसीएम लेख में चर्चा कर रहा हूं जिसे मैं चौथे पैराग्राफ में लिंक कर रहा हूं। लेकिन यह बहुत अच्छी बात है, और मुझे शायद इस पर थोड़ा और विस्तार करना चाहिए था। +1 क्योंकि अब मेरे पास नहीं है, पी
यानिस

आप ठीक कह रहे हैं, मैंने ध्यान से नहीं देखा। मैंने अपनी टिप्पणी संपादित की।
बेन

ओह, आपको वास्तव में ऐसा नहीं करना था, मैं शिकायत नहीं कर रहा था;)
yannis

4
आप जो भी ऊपर वर्णित करते हैं, उनमें से किसी को भी लंबोदर की आवश्यकता नहीं है। नामांकित कार्यों के साथ ही कार्यक्षमता आसानी से प्राप्त की जाती है। यहाँ आप केवल एक causeऔर perceived affectबिना बताए दस्तावेज़ कर रहे हैं correlation। अंतिम पंक्ति IMO वह है जो प्रश्न के बारे में है; लेकिन आपने इसका जवाब नहीं दिया। यह समवर्ती प्रोग्रामिंग को सरल क्यों करता है।
मार्टिन यॉर्क

@ बान: सावधान रहें कि आपका उदाहरण उच्च-क्रम वाले कार्यों की चिंता करता है जिन्हें उपयोग किए जाने वाले अनाम कार्यों की आवश्यकता नहीं है। आपके उत्तर में दिलचस्प विचार हैं (एक अन्य प्रश्न के लिए) लेकिन अभी विषय बंद हो रहा है।
जियोर्जियो

9

मैं यहां कई उत्तरों से सहमत हूं, लेकिन यह दिलचस्प है कि जब मैंने लंबोदर के बारे में सीखा और उन पर कूद गया, तो यह उन कारणों में से किसी के लिए नहीं था जिनके बारे में दूसरों ने उल्लेख किया है।

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

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

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


1
बहुत अच्छी व्याख्या (+1)। लिस्प प्रोग्रामर्स को 1958 से इन सब के बारे में पता है। ;-)
जियोर्जियो

4
@ जिओर्जियो: ज़रूर, लेकिन लिस्प प्रोग्रामर्स को भी प्रबलित खुली / बंद कोष्ठक कुंजी के साथ विशेष कीबोर्ड खरीदना था :)
DXM

@DXM: कीबोर्ड नहीं, उन्हें अतिरिक्त इनपुट डिवाइस मिलती है जो कोष्ठक खोलने और बंद करने के लिए पियानो पैडल की तरह होती है ;-)
vartec

@DXM, vartec: हाल ही में कुछ स्कीम कर रहा हूं और मुझे कोष्ठक ठीक लगा। कुछ C ++ कोड बहुत अधिक गूढ़ हो सकते हैं (और मुझे योजना की तुलना में C ++ का अधिक अनुभव है)। :-)
जियोर्जियो

9

यहाँ हाल के इतिहास में थोड़ा सा शामिल होने के बाद, मेरा मानना ​​है कि एक कारक जावा और .NET के लिए जेनरिक का अतिरिक्त था। यह स्वाभाविक रूप से फंक < , > और अन्य दृढ़ता से टाइप किए गए कम्प्यूटेशनल एब्स्ट्रक्शन (टास्क < >, एसिंक्स < > आदि) की ओर जाता है।

.NET की दुनिया में हमने एफपी का समर्थन करने के लिए इन सुविधाओं को ठीक से जोड़ा है। इससे कार्यात्मक प्रोग्रामिंग, विशेष रूप से C # 3.0, LINQ, Rx और F # से संबंधित भाषा के काम का एक व्यापक सेट शुरू हो गया। उस प्रगति ने अन्य पारिस्थितिक तंत्रों को भी प्रभावित किया और अभी भी C #, F # और टाइपस्क्रिप्ट में आज भी जारी है।

यह निश्चित रूप से MSR पर हास्केल काम करने में मदद करता है :)

बेशक कई अन्य प्रभाव भी थे (जेएस निश्चित रूप से) और ये कदम बदले में कई अन्य चीजों से प्रभावित थे - लेकिन इन भाषाओं में जेनेरिक को जोड़ने से सॉफ्टवेयर की दुनिया के बड़े हिस्सों में 90 के दशक के अंत में कठोर OO रूढ़िवादियों को तोड़ने में मदद मिली। एफपी के लिए दरवाजा।

डॉन Syme

ps F # 2003 था, 2005 नहीं - हालांकि हम कहेंगे कि यह 2005 तक 1.0 तक नहीं पहुँचा। हमने 2001-02 में एक Haskell.NET प्रोटोटाइप भी किया।


स्वागत हे! मैंने एफ # के लिए 2005 का उपयोग किया, क्योंकि उस वर्ष को एफ # विकिपीडिया लेख में पहली स्थिर रिलीज के वर्ष के रूप में बताया गया है। क्या आप मुझे इसे 2003 में बदलना चाहेंगे?
yannis

4

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

"लैम्ब्डा को रिश्तेदार अस्पष्टता के लिए फिर से आरोपित किया जाता है जब तक कि जावा उन्हें नहीं होने से लोकप्रिय बना देता है।"


सुनहरा मुहावरा :)
pistache

4

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

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

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


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

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

@ जियोर्जियो: हाँ, वर्तमान में उपयोग की जाने वाली अधिकांश अवधारणाएँ बहुत, बहुत लंबे समय से हैं। अभी तक वे जिस तरह से उपयोग नहीं किए गए हैं, वे अब उपयोग किए जाते हैं।
vartec

1

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

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


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

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

ख़ूब कहा है। परिवर्तनशील स्थिति से दूर हटना संगामिति को आसान बना देता है और कैस्केलॉग और स्पार्क जैसी तकनीकें आसानी से कंप्यूटर के क्लस्टर में कार्यात्मक प्रोग्रामिंग को वितरित करती हैं। कैसे और क्यों के रूप में अधिक विस्तार के लिए glennengstrand.info/analytics/distributed/functional/… देखें ।
ग्लेन

1

अगर मैं अपना € 0.02 जोड़ सकता हूं, हालांकि मैं अवधारणा को पेश करने वाले जावास्क्रिप्ट के महत्व से सहमत हूं, मुझे लगता है कि समवर्ती प्रोग्रामिंग की तुलना में मैं अतुल्यकालिक प्रोग्रामिंग के मौजूदा फैशन को दोषी ठहराऊंगा। एसिंक्स कॉल करते समय (वेबपेजों के साथ आवश्यक), सरल अनाम फ़ंक्शन इतने स्पष्ट रूप से उपयोगी होते हैं, कि हर वेब प्रोग्रामर (यानी, प्रत्येक प्रोग्रामर) को अवधारणा से बहुत परिचित होना था।


1

अनाम फ़ंक्शंस / लैम्ब्डस के समान कुछ और पुराना उदाहरण अल्गोल 60 में कॉल-बाय-नेम है। ध्यान दें कि कॉल-बाय-नाम सही कार्य करने की तुलना में मैक्रोज़ को मापदंडों के रूप में पारित करने के करीब है, और यह अधिक नाजुक या कठिन है। परिणामस्वरूप समझें।


0

यहाँ मेरे ज्ञान का सबसे अच्छा वंश है।

  • 2005: जावास्क्रिप्ट ने हाल ही में लैम्बदास के साथ उच्च-क्रम प्रोग्रामिंग को मुख्यधारा में वापस लाया है। विशेष रूप से पुस्तकालयों में जैसे अंडरस्कोर।जेएस और जेकरी । इन पुस्तकालयों में से एक प्रोटोटाइप था। जेएस जो लगभग एक साल के बाद jquery से पहले होता है। प्रोटोटाइप रूबी के अनगिनत मॉड्यूल पर आधारित है, जो हमें…
  • 1996: रूबी के एन्युमरेबल मॉड्यूल ने स्पष्ट रूप से स्मॉलटाक के संग्रह ढांचे से प्रेरणा ली। जैसा कि Matz ने कई साक्षात्कारों में बताया है, जो हमें…
  • 1980: स्मॉलटाक उच्च-क्रम प्रोग्रामिंग का बहुत उपयोग करता है और एक संग्रह एपीआई प्रदान करता है जो उच्च-क्रम प्रोग्रामिंग (जैसे, जीएनयू स्मॉलटॉक के Iterable वर्ग ) का भारी उपयोग करता है । मुहावरेदार Smalltalk कोड में आपको लूप के लिए कोई भी नहीं मिलेगा, लेकिन केवल उच्च-क्रम के एन्यूमरेशन। दुर्भाग्य से जब जावा ने स्मॉलटाक के संग्रह ढांचे को 1998 में जावा में पोर्ट किया था तो उच्च-क्रम की गणना को छोड़ दिया गया था। इस तरह उच्च-स्तरीय प्रोग्रामिंग को आने वाले दस वर्षों के लिए मुख्यधारा से बाहर कर दिया गया! स्मालटाक के कई वंश हैं, लेकिन ओपी के प्रश्न के लिए प्रासंगिक LISP है, जो हमें…
  • 1958: LISP, जाहिर है, इसके मूल में उच्च-क्रम प्रोग्रामिंग है।

निस्संदेह, एमिस पूरे एमएल वंश है। एमएल, एसएमएल, ओकेमेल, हास्केल, एफ #। कि कुछ के लिए गिनती करने के लिए मिला ..
मुहम्मद अल्करौरी

-1

अनाम कार्य अच्छे हैं क्योंकि नामकरण कठिन है, और यदि आप केवल एक बार किसी फ़ंक्शन का उपयोग करते हैं, तो उसे नाम की आवश्यकता नहीं है।

लैम्ब्डा फ़ंक्शन केवल हाल ही में मुख्यधारा बन गए हैं क्योंकि हाल ही में, अधिकांश भाषाओं ने बंद का समर्थन नहीं किया।

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


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

मुझे पता है कि पाइथन में मेमनों का सबसे अच्छा कार्यान्वयन नहीं है। लेकिन लोकप्रियता के मामले में, यह संभवतः हास्केल की तुलना में अधिक योगदान देता है।
मुहम्मद अलकरौरी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.