कार्यात्मक प्रोग्रामिंग पठनीयता [बंद]


13

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

यहां मेरा सवाल है, मैं लगातार OOP लोगों से सुनता हूं कि कार्यात्मक शैली बहुत ही अपठनीय है। अगर यह मामला है तो मैं उत्सुक हूं और मैं खुद को बहका रहा हूं, या अगर वे एक कार्यात्मक भाषा सीखने में समय लेते हैं, तो पूरी शैली ओओपी से अधिक अप्राप्य नहीं होगी?

क्या किसी ने कोई सबूत देखा है या कोई उपाख्यान मिला है, जहां उन्होंने देखा कि यह एक रास्ता है या आवृत्ति के साथ एक और संभवतः कहने के लिए पर्याप्त है? यदि कार्यात्मक रूप से लिखना वास्तव में कम पठनीयता का है, तो मैं इसका उपयोग नहीं करना चाहता, लेकिन मैं वास्तव में नहीं जानता कि यह मामला है या नहीं।


1
मुझे याद है कि "सुपर नारियो ब्रदर्स" svn.coderepos.org/share/lang/haskell/nario के कोड को देखने पर मुझे फंक्शनल प्रोग्रामिंग के बारे में कुछ भी पता नहीं था और यह सोचकर याद आया 'वाह। यह वास्तव में पठनीय लगता है '
वुहानहाइट

1
एक पर नजर डालें programmers.stackexchange.com/questions/158715/...
Superm


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

जवाबों:


15

कोड पठनीयता बहुत व्यक्तिपरक है । इस वजह से, विभिन्न लोग एक ही कोड को पठनीय या अपठनीय मानेंगे।

एक असाइनमेंट, x = x + 1एक गणितज्ञ के लिए अजीब लगता है, क्योंकि एक असाइनमेंट भ्रामक रूप से तुलना के समान दिखता है।

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

बहुत ही एफपी कोड पर लागू होता है। जब तक आप पर्दे के पीछे के लॉजिकल पैटर्न को नहीं जानते हैं, तब तक कुछ बुनियादी बातों को समझना बहुत मुश्किल होगा, जैसे कि किसी फंक्शन को दूसरे फंक्शन के लिए कैसे पास किया जाए।

यह कहने के बाद, किसी को यह समझना चाहिए कि एफपी चांदी की गोली नहीं है। ऐसे कई एप्लिकेशन हैं जहां एफपी को लागू करना मुश्किल होगा और इसलिए, यह एक बदतर पठनीय कोड को जन्म देगा


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

12

संक्षिप्त जवाब:

लोगों को बनाने वाले तत्वों में से एक यह कहता है कि कार्यात्मक प्रोग्रामिंग कोड को पढ़ना मुश्किल है, यह अधिक कॉम्पैक्ट सिंटैक्स को वरीयता देता है।

लंबा जवाब:

कार्यात्मक प्रोग्रामिंग स्वयं पढ़ने योग्य या अपठनीय नहीं हो सकती है, क्योंकि यह एक प्रतिमान है, न कि कोड लिखने की शैली। उदाहरण के लिए C # में, कार्यात्मक प्रोग्रामिंग जैसा दिखता है:

return this.Data.Products
    .Where(c => c.IsEnabled)
    .GroupBy(c => c.Category)
    .Select(c => new PricesPerCategory(category: c.Key, minimum: c.Min(d => d.Price), maximum: c.Max(d => d.Price)));

और जावा, C # या समान भाषाओं में पर्याप्त अनुभव वाले किसी भी व्यक्ति द्वारा पठनीय माना जाएगा।

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

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

की तुलना करें:

public void IsWithinRanges<T>(T number, param Range<T>[] ranges) where T : INumeric
{
    foreach (var range in ranges)
    {
        if (number >= range.Left && number <= range.Right)
        {
            return true;
        }
    }

    return false;
}

सेवा:

public function void IsWithinRanges
    with parameters T number, param array of (Range of T) ranges
    using generic type T
    given that T implements INumeric
{
    for each (var range in ranges)
    {
        if (number is from range.Left to range.Right)
        {
            return true;
        }
    }

    return false;
}

उसी तरह से:

var a = ((b - c) in 1..n) ? d : 0;

एक काल्पनिक भाषा में व्यक्त किया जा सकता है:

define variable a being equal to d if (b minus c) is between 1 and n or 0 otherwise;

जब छोटे वाक्यविन्यास बेहतर होते हैं?

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

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

उदाहरण:

  • PHP में आपको functionप्रत्येक फ़ंक्शन या विधि से पहले टाइप करना होगा, ऐसा करने के लिए कोई विशेष कारण नहीं है।

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

  • वाक्य रचना 1..n, कई एफपी (और Matlab) में इस्तेमाल किया, द्वारा प्रतिस्थापित किया जा सकता है between 1, nया between 1 and nया between (1, n)betweenकीवर्ड यह बहुत आसान है लोग हैं, जो भाषा वाक्य रचना से परिचित नहीं हैं, लेकिन फिर भी, दो डॉट्स टाइप करने के लिए बहुत तेजी से कर रहे हैं के लिए समझने के लिए बनाता है।


8
मैं भावना से सहमत हूं, लेकिन विभिन्न कारणों से। यह इस बारे में नहीं है कि कोई विशेषज्ञ कितनी आसानी से कोड लिख सकता है , क्योंकि कोड आमतौर पर जितना लिखा जाता है उससे कहीं अधिक बार पढ़ा जाता है। छोटा कोड कीमती समय, स्क्रीन स्पेस, और मानसिक क्षमता को बर्बाद न करके पठनीयता में भी मदद कर सकता है, अगर कुछ पहले से ही एक छोटे संकेतक (उदाहरण के लिए, अर्धविरामों के बजाय नई सुर्खियों, वैसे भी दो संयोग) से स्पष्ट होगा। जब यह बहुत अधिक गूढ़ हो जाता है तो यह चोट भी पहुंचा सकता है (उदाहरण के लिए, मैं for x in xsअधिक पसंद for x xsकरता हूं, क्योंकि यह मुझे लूप वेरिएबल और कंटेनर को अलग करने में मदद करता है)।

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

@ जिमी हॉफ: प्रोग्रामर देखें ।stackexchange.com/a/158721/6605 जहां मैं सी # स्निपेट पर चर्चा करता हूं और शुरुआत प्रोग्रामर द्वारा कैसे माना जाता है।
आर्सेनी मौरज़ेंको

1
@Sergiy: जावा या C # में, एक विधि हस्ताक्षर methodमें कीवर्ड नहीं है । उदाहरण: public int ComputePrice(Product product)। ऐसे कीवर्ड को जोड़ना, जैसा कि PHP ने किया था, बस चीजों को पढ़ने में आसान बनाने के बजाय अव्यवस्था को जोड़ता है। यदि एक प्रोग्रामर यह समझने में असमर्थ है कि कोई फ़ंक्शन उसके हस्ताक्षर से एक फ़ंक्शन है, तो या तो इस प्रोग्रामर को कोई अनुभव नहीं है या कोड मैं कभी देखे गए सबसे खराब कोड की तुलना में बहुत अधिक अपठनीय है।
बजे आर्सेनी मौरज़ेंको

1
@ शेरगी: ऐसे मामले हैं जहां वाचालता मदद कर सकती है (अन्यथा, हम भाषाओं और कोड जैसे देखेंगे p i ComputePrice(product): _.unitPrice * ~.cart[_]), लेकिन कुछ भाषाएं इसे बहुत दूर धकेल देती हैं। functionPHP में निरर्थक कीवर्ड का उदाहरण एक अच्छा उदाहरण है।
आर्सेनी मूरज़ेंको

6

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

उदाहरण के लिए, एक कार्यात्मक प्रोग्रामर के लिए एक कोड लिखना स्वाभाविक है जो कि Maybeमोनड, या Eitherमोनाड के भीतर विभिन्न बिंदुओं पर विफल हो सकता है । या, सन्यासी की मदद से एक राज्यपरक गणना लिखने के लिए State। लेकिन जो कोई भिक्षुओं की अवधारणा को नहीं समझता है, उसके लिए यह सब कुछ काला जादू जैसा लगता है।

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

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


2

पठनीयता का प्रतिमानों, मॉडलों और इस तरह से कोई लेना-देना नहीं है। जितना अधिक कोड आपके समस्या डोमेन के शब्दार्थ को दर्शाता है, उतना ही वह इस तरह के समस्या डोमेन की शब्दावली और मुहावरों को संचालित कर रहा है, यह उतना ही पठनीय है।

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

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


1

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

टाइप इंट्रेंस एक मुश्किल विशेषता हो सकती है। आमतौर पर, यह विकास का एक बड़ा त्वरक है, हालांकि, यह कभी-कभी यह पता लगाना मुश्किल हो सकता है कि भ्रामक त्रुटियों के कारण संदर्भ की कमी के कारण कौन से प्रकार शामिल हैं। यह केवल कार्यात्मक प्रोग्रामिंग भाषाओं तक सीमित नहीं है - मैंने इसे C ++ टेम्पलेट्स में भी देखा है!

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

कार्यात्मक भाषाओं में वाणिज्यिक विकास अभी भी अपेक्षाकृत अपरिपक्व है। मैंने कई गलतियाँ देखी हैं जिन्हें किसी भी भाषा में बुरा रूप माना जाएगा। जैसे कि:

  1. बदलती शैली के रूप में आप भाषा सीखते हैं (और नहीं refactoring) असंगति के लिए अग्रणी।
  2. एक फाइल में बहुत ज्यादा।
  3. एक पंक्ति पर बहुत से कथन।

गलतियों के बारे में मैं भी जोड़ूंगा: 4. प्रतीकों का अति प्रयोग, उदा: ~ @ # $% ^ & * () -_ + + = \ /!;; 5. निहित विशेषताएं: वैकल्पिक घोषणाएं / कीवर्ड / बयान, निहितार्थ रूपांतरण, आदि;
सर्गी सोकोलेन्को
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.