सांख्यिकीय रूप से टाइप की गई कार्यात्मक प्रोग्रामिंग भाषा का उपयोग न करने के दस कारण

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

लेखक के बारे में

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

जो मुझे समझ नहीं आ रहा है, उस पर ध्यान देना

क्या आप कार्यात्मक भाषाओं के आसपास यह सब प्रचार से थक गए हैं? मुझे भी! मैं आपको कुछ कारण बताऊंगा कि आप और मेरे जैसे उचित लोगों को इससे दूर क्यों रहना चाहिए।

मैं थोड़ा समझाता हूं: जब मैं कहता हूं कि "सांख्यिकीय रूप से टाइप की गई कार्यात्मक प्रोग्रामिंग भाषा", मेरा मतलब है कि ऐसी भाषाएं जो डिफ़ॉल्ट प्रकार के अनुमान का समर्थन करती हैं और इसी तरह। व्यवहार में, इसका मतलब हास्केल और भाषाओं के एमएल परिवार (ओमेक्एल और एफ # सहित) है।

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

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

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

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

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

public static class SumOfSquaresHelper { public static int Square(int i) { return i * i; } public static int SumOfSquares(int n) { int sum = 0; for (int i = 1; i <= n; i++) { sum += Square(i); } return sum; } } 

और अब इसके साथ तुलना करें:

 let square x = x * x let sumOfSquares n = [1..n] |> List.map square |> List.sum 

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

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

और एक बात। इन सभी भाषाओं का क्या होता है जो घुंघराले ब्रेसिज़ से छुटकारा पाती हैं? उन्हें वास्तविक प्रोग्रामिंग भाषा कैसे कहा जा सकता है?
मैं आपको दिखाऊंगा कि मेरा क्या मतलब है। यहां सामान्य कर्ली ब्रेसिज़ के साथ एक नमूना कोड है।

 public class Squarer { public int Square(int input) { var result = input * input; return result; } public void PrintSquare(int input) { var result = this.Square(input); Console.WriteLine("Input={0}. Result={1}", input, result); } } 

और यहाँ एक समान कोड है, केवल घुंघराले ब्रेसिज़ के बिना।

 type Squarer() = let Square input = let result = input * input result let PrintSquare input = let result = Square input printf "Input=%i. Result=%i" input result 

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

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

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

 let GroupBy source keySelector = ... 

और यहाँ स्पष्ट प्रकार की परिभाषाओं के साथ समान सी # कोड के लिए फ़ंक्शन हस्ताक्षर है।

 public IEnumerable<IGrouping<TKey, TSource>> GroupBy<TSource, TKey>( IEnumerable<TSource> source, Func<TSource, TKey> keySelector ) ... 

शायद मैं अल्पमत में हूं, लेकिन मुझे दूसरा संस्करण बहुत पसंद है। मेरे लिए यह जानना महत्वपूर्ण है कि फ़ंक्शन IEnumerable<IGrouping<TKey, TSource>> प्रकार वापस कर देगा।

बेशक, कंपाइलर आपके लिए एक प्रकार की जाँच करेगा और यदि यह एक प्रकार का बेमेल का पता लगाता है तो आपको चेतावनी देगा। लेकिन संकलक को यह काम क्यों करने दें यदि आपका दिमाग ऐसा कर सकता है?
ठीक है, मेरा मानना ​​है कि यदि आप जेनेरिक, लैम्ब्डा, फ़ंक्शंस का उपयोग करते हैं जो फ़ंक्शंस लौटाते हैं, और ये सभी नए सामान हैं, तो हाँ, आपकी प्रकार की परिभाषाएं वास्तव में अत्यधिक जटिल और भ्रामक बन सकती हैं। और उन्हें सही ढंग से दर्ज करना बहुत मुश्किल हो जाता है।
लेकिन मेरे पास इसके लिए एक आसान समाधान है - जेनेरिक का उपयोग न करें और कहीं भी कार्य न करें, आपके हस्ताक्षर बहुत आसान हो जाएंगे।

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

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

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

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

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

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

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

मैं बहुत ईमानदारी से प्रत्येक विधि में अशक्त जांच करता हूं। यह मुझे बहुत संतुष्टि देता है, मुझे पता है कि परिणामस्वरूप, मेरा कोड पूरी तरह से बुलेटप्रूफ है।

 void someMethod(SomeClass x) { if (x == null) { throw new NullArgumentException(); } x.doSomething(); } 

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

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

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

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

यहाँ वर्गों के योग की गणना करने के लिए कोड है। इन सभी अजीब चरित्रों के कारण इस रिकॉर्डिंग विधि को समझना बहुत मुश्किल है।

 ss=: +/ @: *: 

ओह, क्षमा करें! मुझसे गलती हुई, यह J पर एक कोड था।
लेकिन फिर मैंने सुना कि कार्यात्मक भाषाएं <*> और >>= जैसे अजीब चरित्रों का उपयोग करती हैं, या "मोनडर्स" और "फ़ंक्शनलर्स" जैसी अस्पष्ट अवधारणाओं का उपयोग करती हैं।
मुझे नहीं पता कि कार्यात्मक प्रोग्रामर मेरे द्वारा पहले से ही जानी जाने वाली चीजों का पालन क्यों नहीं कर पाए, जैसे कि ++,; = = और अनुवांशिकता और बहुरूपता जैसे प्रकाश अवधारणाओं के रूप में स्पष्ट।

परिणाम। मुझे यह समझ में नहीं आ रहा है

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