क्या कोई विधिपूर्वक टाइप की गई कार्यात्मक प्रोग्रामिंग भाषा का उपयोग करने का कोई कारण है?

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

कारण 1. मैं नवीनतम रुझानों का पालन नहीं करना चाहता

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

हालाँकि, क्या यह प्रवृत्ति इतनी महत्वपूर्ण है? और क्या कोई आश्वस्त हो सकता है कि "एक नई फैशनेबल भाषा जल्द ही दुनिया को जीत लेगी"? शायद यह किसी के लिए एक रहस्योद्घाटन होगा, लेकिन भाषा की वाक्य रचना या शैली शायद ही कभी वितरण या लोकप्रियता का आधार थी। शायद 60-80 के दशक में, जब प्रोग्रामिंग की विभिन्न शैलियाँ केवल दिखाई देती थीं, लेकिन अब नहीं। आइए फिलहाल सबसे आम (लोकप्रिय) भाषाओं की सूची की जाँच करें:

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

ऑब्जेक्टिव-सी - लोकप्रियता ऐप्पल प्लेटफॉर्म के लिए बाध्यकारी पर आधारित है।

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

C # - एक और C ++ क्लोन, सभी "चीनी" बाद में दिखाई दिया, और व्यापकता विंडोज के लिए बाध्यकारी पर आधारित है। मोनो? क्या आप सुनिश्चित हैं कि C # में लिखे गए किसी भी कार्यक्रम को शुरू करने का कार्य कभी हासिल किया जाएगा? और यह विचार कर रहा है कि .Net अपनी गति से विकसित हो रहा है, और मोनो सब कुछ साथ रखने की कोशिश कर रहा है। इसके अलावा, कई पुस्तकालय विंडोज से बहुत अधिक बंधे होते हैं।

PHP / रूबी - दो भाषाएँ जो वेब विकास से जुड़ी हैं। बहुत से लोग यह पसंद नहीं करेंगे कि वे एक जोड़ी में हैं, लेकिन यह जीवन का कठोर सच है। और, प्रोग्रामर की एक निश्चित संख्या के बीच PHP की नापसंदगी को भाषा के "बुरे" वाक्य-विन्यास द्वारा सटीक रूप से समझाया गया है। किसी भी कार्यात्मक भाषा की तुलना में उसे अधिक लोकप्रिय होने से क्या नहीं रोकता है। हालांकि, विरोधाभासी रूप से, लेकिन PHP वेब अनुप्रयोगों के "सरल" वाक्यविन्यास और तेजी से विकास के कारण लोकप्रिय हो गया है।

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

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

विजुअल बेसिक - एक विंडोज / ऑफिस प्लेटफ़ॉर्म पर बांधना।

शैल - यूनिक्स से बांधना।

असेंबलर - किसी भी उपकरण के लिए सबसे कुशल कोड लिखने की क्षमता। फिर, कई रेटिंग्स में, किसी भी कार्यात्मक भाषा की तुलना में अधिक लोकप्रिय।

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

कारण 2. मुझे कोड की लाइनों के लिए भुगतान मिलता है

यदि आपको कोड की लाइनों के लिए भुगतान किया जाता है, तो आपको निश्चित रूप से नौकरी बदलनी चाहिए, यदि केवल इसलिए कि यदि प्रबंधन प्रदर्शन का सही मूल्यांकन नहीं करता है (जैसा कि इस मामले में है), तो आपको भविष्य में समस्या हो सकती है।

गंभीरता से बोल, "कोड की लाइनें" क्या हैं? उदाहरण के लिए, मेरे पास कोड की 100 लाइनों के साथ एक आवेदन है, मुझे एक पुस्तकालय मिला जिसने उन्हें कम कर दिया 5. और कोई कार्यात्मक प्रोग्रामिंग नहीं। और शायद मुझे 5 और लाइब्रेरी भी मिलीं जो समान हैं और कोड को 3, 7, 10, 15 और 8 लाइनों के कोड को कम करती हैं। क्या मुझे सबसे छोटा समर्थन चुनना चाहिए या जिसके पास सबसे अच्छा समर्थन, अधिक विकल्प, बेहतर प्रदर्शन प्रदान करता है, आदि?

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

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

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

कारण 3. मुझे ब्रेसिज़ पसंद है

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

कारण 4. मुझे स्पष्ट प्रकार देखना पसंद है

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

कारण 5. मुझे बग्स को ठीक करना पसंद है

कारण 6. मैं एक डिबगर में रहता हूं

ये शायद सबसे गंभीर तर्क हैं। यदि यह सच था, तो मुझे लगता है कि लाखों डेवलपर्स तुरंत कार्यात्मक भाषाओं पर स्विच करना चाहेंगे। लेकिन मुझे संदेह है कि यह ऐसा है। कार्यात्मक भाषाओं के अनुयायी क्यों सोचते हैं कि उनके यहाँ और यहाँ कम कीड़े हैं । तर्क नीचे आते हैं

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

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

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

कारण 7. मैं हर छोटी चीज के बारे में नहीं सोचना चाहता

फिर से एक भावनात्मक तर्क। यह सब डेवलपर पर अधिक निर्भर करता है, न कि भाषा पर।

कारण 8. मैं अशक्त के लिए जाँच करना पसंद करता हूँ

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

कारण 9. मैं हर जगह डिजाइन पैटर्न का उपयोग करता हूं

क्या यह वास्तव में एक रहस्य है कि कई डिज़ाइन पैटर्न ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग की सुविधाओं का परिणाम हैं? और क्लोजर, मोनड्स, या करीने से भी कार्यात्मक प्रोग्रामिंग के पैटर्न नहीं हैं? और यह संभव है कि कई कार्यात्मक प्रोग्रामिंग पैटर्न अभी भी हमसे आगे हैं - कौन जानता है?

कारण 10. बहुत गणित

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

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

निष्कर्ष

बेशक, कार्यात्मक शैली का उज्ज्वल भविष्य है। बल्कि, आश्चर्य की बात है कि यह 20 साल पहले नहीं आया था। और इससे भी अधिक आश्चर्य की बात यह है कि पहली कार्यात्मक भाषा के आगमन के 60 साल बाद।

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

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

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

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

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