वृद्धि पर कार्यात्मक प्रोग्रामिंग?


42

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

और काफी समय से ऐसा ही है। कार्यात्मक प्रोग्रामिंग बस अन्य मॉडल (यानी, वस्तु-उन्मुख प्रोग्रामिंग) के रूप में लोकप्रिय नहीं हुई है।

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

मैं इस तथ्य को बहुत दिलचस्पी के साथ देखता हूं कि उनकी महत्वपूर्ण सामुदायिक स्वीकृति की कमी के बावजूद, इस तरह की अधिक से अधिक भाषाएँ उभरती रहती हैं। क्लोजर (2007), स्काला (2003), एफ # (2002) हाल के पिछले दशक के सिर्फ तीन उदाहरण हैं।

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

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

मैं जो पूछना चाहता हूं वह है:

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

आगे के शोध के लिए कोई भी सिफारिश स्वागत से अधिक होगी।

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

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

अग्रिम में धन्यवाद!


4
यह अर्लंग है, अर्लंग नहीं (मैंने आपकी पोस्ट संपादित कर दी है, लेकिन सिस्टम 1-अक्षर के संपादन की अनुमति नहीं देता है)।
quant_dev

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

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

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

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

जवाबों:


24

किसी कार्य को करने के लिए मुझे किन कार्यात्मक प्रोग्रामिंग भाषाओं पर बेहतर तरीके से विचार करना चाहिए? समानांतर प्रोग्रामिंग की इतनी हालिया लोकप्रिय मल्टीकोर समस्या के अलावा।

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

अनिवार्य रूप से, "स्प्रेडशीट समस्या"। आपके पास उस डेटा को लागू करने के लिए कुछ प्रारंभिक डेटा और पंक्ति-दर-पंक्ति गणना का सेट है।

हमारे उत्पादन अनुप्रयोग डेटा के सांख्यिकीय सारांश के एक नंबर करते हैं; यह सब कार्यात्मक रूप से सबसे अच्छा है।

एक सामान्य बात जो हम करते हैं वह तीन राक्षसी डेटा सेटों के बीच मेल-मिलाप है। SQL जॉइन के समान है, लेकिन सामान्यीकृत नहीं है। इसके बाद व्युत्पन्न आंकड़ों की गणना की जाती है। यह सब सिर्फ कार्यात्मक परिवर्तन है।

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

यहाँ एक कार्यात्मक रचना का एक ठोस उदाहरण है।

for line in ( l.split(":") for l in ( l.strip() for l in someFile ) ):
    print line[0], line[3]

यह एक तरीका है कि कार्यात्मक प्रोग्रामिंग पायथन जैसी भाषाओं को प्रभावित करता है।

कभी-कभी इस तरह की बात लिखी जाती है:

cleaned = ( l.strip() for l in someFile )
split = ( l.split(":") for l in cleaned )
for line in split:
     print line[0], line[3]

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

अपरिवर्तनीय वस्तुएं सबसे कठिन बाधा है।

अक्सर आप मौजूदा मानों को अपडेट करने के बजाय नए ऑब्जेक्ट बनाने वाले मानों की गणना करेंगे। यह विचार कि यह एक वस्तु का एक परस्पर गुण है, तोड़ने के लिए एक कठिन मानसिक आदत है।

एक व्युत्पन्न संपत्ति या विधि फ़ंक्शन एक बेहतर दृष्टिकोण है। स्टेटफुल ऑब्जेक्ट्स को तोड़ना एक कठिन आदत है।

वहाँ कई कार्यात्मक प्रोग्रामिंग भाषाओं के साथ, आप अपनी आवश्यकताओं के अनुसार बेहतर सूट का चयन कैसे करेंगे?

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

मैंने हास्केल पर सिर्फ पायथन की कमी को समझने के लिए पढ़ा है।


5
@edalorzo: पायथन कमजोर रूप से टाइप नहीं किया गया है। यह बहुत, बहुत दृढ़ता से टाइप किया गया है। कोई कास्ट ऑपरेटर नहीं है, इसलिए यह जावा या सी ++ की तुलना में अधिक दृढ़ता से टाइप किया गया है।
एस.लॉट।

5
@ S.Lott - स्थिर प्रकार जाँच आईडीई उपकरण और intellisense प्रकार सामान refactoring के साथ मदद नहीं करता है? यदि आपके पास पृष्ठभूमि संकलन है, और आप सांख्यिकीय रूप से जाँच कर रहे हैं, तो इसका मतलब यह नहीं है कि आप अपने टूल में अधिक स्वचालित कर सकते हैं? मैं इस बात से सहमत हूं कि यदि आपके परीक्षणों में 100% कोड कवरेज है, तो इसे पकड़ लेंगे। आपको एहसास होना चाहिए कि उद्यम में उत्पादन कोड का शायद 50% से कम वास्तव में यूनिट टेस्ट कवरेज है, हालांकि? :) वहाँ एक असली दुनिया है वहाँ हम में रहना है।
स्कॉट व्हिटलॉक

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

3
@ S.Lott "पायथन कमजोर रूप से टाइप नहीं है। यह बहुत, बहुत दृढ़ता से टाइप किया गया है।" पायथन का अनुमान संख्यात्मक प्रकारों के बीच होता है, जिसे कमजोर प्रकार से टाइप किया जा रहा है।
जॉन हैरोप

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

23

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

अचल स्थिति

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

प्रथम श्रेणी के प्रकार के रूप में कार्य

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

कार्यों की रचना करने में सक्षम होना (उदाहरण के लिए Action<T>सिर्फ एक में बदलना Actionभी कुछ परिदृश्यों में काफी उपयोगी है।

हमें यहाँ लैम्ब्डा सिंटैक्स भी नोट करना चाहिए, क्योंकि आप केवल लैम्ब्डा सिंटैक्स प्राप्त करते हैं जब आप फ़र्स्ट क्लास के प्रकारों को प्रोमोट करते हैं। लैम्ब्डा सिंटैक्स बहुत अभिव्यंजक और संक्षिप्त हो सकता है।

monads

बेशक, यह मेरी कमजोर जगह है, लेकिन मेरी समझ यह है कि एफ # में कम्प्यूटेशनल वर्कफ़्लोज़, जैसे asyncवर्कफ़्लो, एक सन्यासी है। यह एक सूक्ष्म लेकिन बहुत शक्तिशाली निर्माण है। यह उतना ही शक्तिशाली है जितना कि C # में कक्षाएं yieldबनाने के लिए प्रयुक्त कीवर्ड IEnumerable। अनिवार्य रूप से यह कवर के तहत आपके लिए एक राज्य मशीन का निर्माण कर रहा है, लेकिन आपका तर्क रैखिक दिखता है।

आलसी मूल्यांकन और पुनरावृत्ति

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

एस-भाव

मुझे लगता है कि मुझे यकीन नहीं है कि इसे कहां रखा जाए, लेकिन संयुक्त राष्ट्र के संकलित कोड को एक वस्तु के रूप में मानने (और इसका निरीक्षण / संशोधन) करने की क्षमता, जैसे कि लिस्प एस-एक्सप्रेशंस, या लिनक्यू एक्सप्रेशंस, कुछ मायनों में, है कार्यात्मक प्रोग्रामिंग का सबसे शक्तिशाली उपकरण। अधिकांश नए .NET "धाराप्रवाह" इंटरफेस और DSLs, कुछ बहुत ही संक्षिप्त एपीआई बनाने के लिए लैम्ब्डा सिंटैक्स और LINQ एक्सप्रेशंस के संयोजन का उपयोग करते हैं। Linq2Sql / Linq2Nhibernate का उल्लेख नहीं करने के लिए जहां आपका C # कोड "जादुई" है SQL के बजाय C # कोड के रूप में निष्पादित किया गया है।

यह आपके प्रश्न के पहले भाग का लंबा उत्तर था ... अब ...

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

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

वहाँ कई कार्यात्मक प्रोग्रामिंग भाषाओं के साथ, आप अपनी आवश्यकताओं के अनुसार बेहतर सूट का चयन कैसे करेंगे?

यदि आप .NET से परिचित हैं, तो मैं अत्यधिक # F सुझाव देता हूं। दूसरी ओर, यदि आप JVM से अधिक परिचित हैं, तो हमेशा क्लोजर होता है । यदि आप व्यावहारिक से अधिक अकादमिक हैं, तो मैं कॉमन लिस्प या स्कीम के साथ जाऊंगा। यदि आप पहले से ही पायथन को जानते हैं, तो मेरा मानना ​​है कि वहां बहुत सारे कार्यात्मक निर्माण पहले से ही उपलब्ध हैं।


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

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

1
.NET के साथ @edalorzo - F # का एकीकरण बहुत अच्छा है, केवल एक मामूली अपवाद के साथ: कोई GUI डिजाइनर नहीं। आप अपने GUI को C # असेंबली में डिज़ाइन करके और F # से संदर्भित करके, या केवल F # के अंदर GUI उत्पन्न करके (किसी डिज़ाइनर के साथ नहीं) में प्राप्त करते हैं।
स्कॉट व्हिटलॉक

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

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

15

और काफी समय से ऐसा ही है। कार्यात्मक प्रोग्रामिंग बस अन्य मॉडल (यानी ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग) के रूप में लोकप्रिय नहीं हुई है।

यह सच है अगर आप पेशेवर प्रोग्रामर (या कम से कम ऐसे लोगों को खुद को देखकर) द्वारा विकसित कार्यक्रमों की गिनती करते हैं। यदि आप ऐसे लोगों को विकसित करने के लिए अपना नेट व्यापक प्रसार करते हैं, जो खुद को ऐसा नहीं मानते हैं, तो एफपी (या एक कार्यात्मक शैली में कम से कम प्रोग्रामिंग) ओओ (एक्सेल, गणितज्ञ, मतलाब, आर ... यहां तक ​​कि 'आधुनिक' जावास्क्रिप्ट के बहुत करीब है) )।

किसी कार्य को करने के लिए मुझे किन कार्यात्मक प्रोग्रामिंग भाषाओं पर बेहतर तरीके से विचार करना चाहिए? समानांतर प्रोग्रामिंग की इतनी हालिया लोकप्रिय मल्टीकोर समस्या के अलावा।

मेरी व्यक्तिगत राय है कि मल्टीकोर एफपी की हत्यारा विशेषता नहीं है (कम से कम जब तक हास्केल, स्काला, क्लॉज्योर, एफ # संकलक कैश स्थानीयता मुद्दे को हल करते हैं)। हत्यारा सुविधा है map, filter, foldऔर दोस्तों के जो एल्गोरिदम के एक बड़े समूह का एक और अधिक संक्षिप्त अभिव्यक्ति अनुमति देते हैं। यह सबसे लोकप्रिय OO समकक्षों की तुलना में अधिक संक्षिप्त सिंटैक्स वाले FP भाषाओं द्वारा संयोजित है।

इसके अतिरिक्त एफपी रिलेशनल मॉडल के करीब होने से RDBMS के साथ प्रतिबाधा बेमेल को कम करता है ... जो कि - कम से कम गैर-प्रोग्रामर के लिए - बहुत अच्छा है।

जब आप विशेष रूप से 'शुद्धता' की आवश्यकताओं को पूरा करने में मुश्किल होते हैं - ऐसे रूप में, जिसका परीक्षण करना कठिन हो (वैज्ञानिक कंप्यूटिंग / बड़े डेटा विश्लेषण में सामान्य जहां लक्ष्य पहले अज्ञात को प्राप्त करना है और इस तरह के संयुक्त राष्ट्र के विशिष्ट परिणाम के रूप में) एफपी की पेशकश कर सकते हैं फायदे।

अगर मैंने एक कार्यात्मक प्रोग्रामिंग भाषा पर स्विच करने का फैसला किया है जो आपको लगता है कि सबसे बड़ा नुकसान है जो मैं सामना करूंगा?

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

वहाँ कई कार्यात्मक प्रोग्रामिंग भाषाओं के साथ, आप अपनी आवश्यकताओं के अनुसार बेहतर सूट का चयन कैसे करेंगे?

  • पहले से ही लाइब्रेरियों / फ्रेमवर्क को किस प्लेटफ़ॉर्म पर (जैसे JVM या .Net) से बाहर निकालकर आपके कितने मुद्दों को हल किया जा सकता है? क्या भाषा निर्माण इन समस्याओं को सीधे व्यक्त करने में सक्षम हैं?

  • आपके आवेदन के स्थान और समय के प्रदर्शन पर आपको कितने निम्न स्तर के नियंत्रण की आवश्यकता है?

  • आपकी "शुद्धता" आवश्यकताएं कितनी सख्त हैं?

  • क्या आप एसडब्ल्यू विकास में कुछ अत्यधिक लाभदायक niches द्वारा की पेशकश की डेवलपर्स और / या लाभ लेने के लिए प्रतिस्पर्धा कर सकते हैं?


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

9

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

मान लें कि आप उद्योग में C ++ / C # / Java देव हैं ...

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

यदि आप एक वेब प्रोग्रामर हैं तो सबसे बड़ा नुकसान शायद आपके बालों का होगा।

वहाँ कई कार्यात्मक प्रोग्रामिंग भाषाओं के साथ, आप अपनी आवश्यकताओं के अनुसार बेहतर सूट का चयन कैसे करेंगे?

मैं मंच से शुरू करूँगा:

  • OCaml लिनक्स पर बहुत अच्छा है और विंडोज पर भयानक है।
  • एफ # विंडोज पर बहुत अच्छा है और लिनक्स पर भयानक है।
  • Scala और Clojure JVM पर शानदार हैं।

1
जब मैं पढ़ता हूं "क्रोधी साथियों के लिए तैयार रहें जो कुछ भी सीखना नहीं चाहते हैं।" मैं चिल्लाना चाहता था: "सच! तो बहुत सच है!" लेकिन यह वास्तव में दुखद है।
ज़ेल्फिर कल्टस्टाल

3

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

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


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

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

2

किसी कार्य को करने के लिए मुझे किन कार्यात्मक प्रोग्रामिंग भाषाओं पर बेहतर तरीके से विचार करना चाहिए? समानांतर प्रोग्रामिंग की इतनी हालिया लोकप्रिय मल्टीकोर समस्या के अलावा।

कोई जादुई सूत्र नहीं है जो आपको बताता है कि कार्यात्मक प्रोग्रामिंग का उपयोग कब करना है। यह ऐसा नहीं है कि ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग हमारी वर्तमान प्रोग्रामिंग स्थितियों के अनुकूल है। यह अमूर्त के एक और सेट के संदर्भ में कार्यक्रमों को संरचित करने का सिर्फ एक और तरीका है।

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

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

वहाँ कई कार्यात्मक प्रोग्रामिंग भाषाओं के साथ, आप अपनी आवश्यकताओं के अनुसार बेहतर सूट का चयन कैसे करेंगे?

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


@ Dadivk01 +1 मुझे यह तर्क पसंद है कि एफपी लैंग्स किसी भी अन्य की तरह एक प्रतिस्पर्धी उपकरण हैं और अन्य मॉडल के साथ हल किए गए समान समस्याओं को हल करने के लिए उपयोग किया जा सकता है। आपको क्या लगता है कि वे कम लोकप्रिय हैं, फिर? और, क्या आप अभी भी सहमत होंगे कि वे ज्यादातर ओओपी लैंग्स की तुलना में समानांतर कंप्यूटिंग मुद्दे को हल करने के लिए बेहतर अनुकूल हैं? क्या आप यह कहेंगे कि अपरिहार्य डेटा प्रकारों की अनिवार्यता की तुलना में मेमोरी फुटप्रिंट और प्रदर्शन पर कोई प्रभाव पड़ता है? मैं इसे हास्केल को मौका दे रहा था, आप "निराशा में हार" क्यों कहेंगे, आप मुझे भयभीत कर रहे हैं, यार :)
edalorzo

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

@edalorzo: जैसा कि "हताशा में हार मानने" के लिए मैं कहता हूं कि यदि अनिवार्य प्रोग्रामिंग आप सभी जानते हैं, तो हैस्केल का प्रकार प्रणाली और प्रभाव का वर्णन करने के लिए इसका राक्षसी दृष्टिकोण थोड़ा बहुत हो सकता है। मुझे लगता है कि ऐसी भाषा के साथ शुरुआत करना बेहतर है जो एर्लैंग और स्काला जैसे साइड-इफेक्ट्स के लिए अधिक व्यावहारिक दृष्टिकोण लेती है।
davidk01

0

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

संपादित करें: क्योंकि यह सभी के लिए स्पष्ट नहीं है।

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

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

समानता के लिए उपयोग किए जाने वाले एफपी के कुछ उदाहरण:

  • CouchDB - एर्लैंग पर निर्माण
  • फेसबुक चैट - Erlang पर निर्माण
  • ट्विटर - स्काला पर बड़े हिस्से का निर्माण

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

4
@vartec: निष्पक्षता के हित में यह तब भी अच्छा होगा यदि आप एक संदर्भ प्रदान कर सकते हैं जो आपके दावों का समर्थन करता है। यह अज्ञानतावश पाठकों को एक प्रति-प्रश्न से कहीं अधिक मदद करेगा ...
13

1
@vartec: वास्तव में नहीं, यह मेरे लिए कभी नहीं हुआ कि बहुत से लोगों ने कुछ दावा किया यह सच है। मैं अपने गणित प्रशिक्षण को दोष देता हूं, लेकिन हम सभी को अपने दावों के लिए कठिन तथ्यों और ठोस औचित्य जैसी चीजों पर विश्वास नहीं है और आपका संपादन अभी भी मेरी टिप्पणी को संबोधित नहीं करता है।
davidk01

1
@vartec आप अपने दावों के समर्थन में एक विश्वसनीय स्रोत का संदर्भ रख सकते हैं।
मात्रा_देव

1
+1 @ davidk01 "हर कोई समानांतर प्रोग्रामिंग का दावा करता है लेकिन इसे वापस करने के लिए बहुत कम डेटा है"। मुझे इसके विपरीत भारी मात्रा में सबूतों की जानकारी है। उदाहरण के लिए, Cilk पत्रों का वर्णन है कि कैसे इन-प्लेस म्यूटेशन आवश्यक है यदि आप अच्छी कैश जटिलता चाहते हैं जो एक मल्टीकोर पर स्केलेबल समानता की आवश्यकता है।
जॉन हेरोप 12
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.