क्या कार्यात्मक प्रोग्रामिंग कोड में जटिलता जोड़ती है? [बन्द है]

Question

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

इस साल मैं एक नई टीम के साथ स्काला प्रोजेक्ट पर हूं, जो वास्तव में कार्यात्मक प्रोग्रामिंग पसंद करता है। वे स्कैलाज़ का भारी उपयोग करते हैं , और कोड को हर जगह एप्लिकेशंस, संदर्भ सीमा, रीडर / लेखक / स्टेट मोनाड से भरा जाता है, यहां तक ​​कि मुख्य विधि I / O मोनड में "लिपटा" है। उनका तर्क यह है कि यह संकलक "हमारे लिए काम करता है" यह सुनिश्चित करने में करता है कि कोड सही है, और प्रत्येक फ़ंक्शन साइड इफेक्ट्स से मुक्त है।

फिर भी, मेरे दृष्टिकोण से यह सब वाक्यविन्यास वास्तव में व्यावसायिक तर्क के रास्ते में है। उदाहरण के लिए, "MyBusinessObject" का एक प्रकार ठीक है, साथ ही "सूची [MyBusinessObject]", "विकल्प [MyBusinessObject]" या यहां तक ​​कि "भविष्य [MyBusinessObject" जैसे प्रकार भी हैं। इन सबका स्पष्ट अर्थ और उद्देश्य है। दूसरी ओर, जैसे कोड:

def method[M[_]: Applicative] = {
  case (a, b) => (ca[M](a) |@| cb[M](b)) {
    case t @ (ra, rb) =>
      if (ra.result && rb.result) t.right
      else t.left
  }
}

क्या यह कार्यक्रम में जटिलता जोड़ता है, या क्या यह सिर्फ मेरे लिए है कि मैं प्रोग्रामिंग के इस तरीके से अभ्यस्त नहीं हूं?

Comments

आपका उद्देश्यपूर्ण उत्तर देने योग्य प्रश्न क्या है?

— हिरण हंटर

ऐसा लगता है कि यह एक या दो अक्षर चर नामों के साथ एक टन कोड की ओर जाता है। देखने में APL सा लगता है। वह पूरक नहीं है।

— user949300

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

— KChaloux

आप मुहावरों से अपरिचित हैं। @ user949300 लघु चर वास्तव में बहुत सारे कार्यात्मक कोड के लिए एक समस्या नहीं हैं (गणित शैली सम्मेलनों के बारे में सोचो!)। इसके अलावा और अधिक गहन चर्चा के लिए टोनी मॉरिस के ब्लॉग को पढ़ें कि बेहतर अर्थ क्या है, प्रकार या क्रिया चर नाम।

— एंड्रेस एफ।

@ user949300: लघु चर नामों को स्थानीय रूप से पसंद किया जाता है, यह कार्यात्मक और अनिवार्य दुनिया में समान है (आप for(i=0; i<7; ++i) { trivialOperation(i); }कुछ अजीब trivialOperationCountचर के साथ नहीं लिखेंगे ? OO में बस एक्सेसर मेथड कॉल्स लिखें। परिणाम आम तौर पर अधिक संक्षिप्त है; शायद थोड़ा कम आत्म-व्याख्यात्मक, लेकिन डेटा घोषणा को सामान्य रूप से देखने से यह जल्दी से स्पष्ट हो जाता है। स्टेटिक टाइपिंग बहुत मदद करता है, यह एपीएल में पसंद नहीं है।

— लेफ्टरनैबाउट

Answer 1

कार्यात्मक प्रोग्रामिंग के साथ इसका कोई लेना- देना नहीं है - आप किसी भी अन्य प्रोग्रामिंग भाषा के संदर्भ में इस तरह की स्थिति पा सकते हैं - डेवलपर्स जो "अपनी" भाषा के उन्नत निर्माणों से इतना प्यार करते हैं कि वे पठनीयता के बारे में किसी भी सामान्य ज्ञान और चीजों को सरल रखने पर ध्यान नहीं देते हैं। मैंने सी, सी ++, पर्ल, जावा, सी #, बेसिक और अन्य गैर-कार्यात्मक भाषाओं में ऐसी स्थिति का सामना किया है। यह कार्यात्मक प्रोग्रामिंग नहीं है जो कोड - प्रोग्रामर को जटिलता जोड़ता है।

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

Comments

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

— एंड्रेस एफ।

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

— एंड्रेस एफ।

बस SLT C ++ लाइब्रेरी को देखें, जो शौकिया के लिए बहुत अधिक पठनीय लिखा जा सकता है

— शाफ़्ट फ्रीक

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

— डॉक्टर ब्राउन

@DocBrown हाँ डिस्लेक्सिया में गलत समय पर लात मारी, लेकिन ईमानदारी से अगर मेरे पास आधा दिमाग था (और अब मेरे पास जितना समय है) मैं कई और अधिक पठनीय होने के लिए फ़ंक्शन निकायों के कई हिस्सों को फिर से लिख सकता हूं।

— शाफ़्ट फ्रीक

Answer 2

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

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

तो फिर, यह भी 'कला के लिए कला' का मामला हो सकता है, जैसे @ डॉक ब्राउन सुझाव देते हैं। यह भी बाहर शासन नहीं कर सकता।

Answer 3

मेरा तर्क है कि सामान्य कार्यात्मक प्रोग्रामिंग में परिवर्तनशील स्थिति को समाप्त करके जटिलता को कम करता है, जिससे उन मामलों की संख्या कम हो जाती है जिन्हें समझने की कोशिश की जानी चाहिए कि कोड का एक भाग कैसे काम करता है।

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

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

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

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

वहाँ पर लटका हुआ। और यह मदद कर सकता है।

Answer 4

क्या यह कार्यक्रम में जटिलता जोड़ता है, या यह सिर्फ इतना है कि आप प्रोग्रामिंग के इस तरीके के लिए उपयोग नहीं किए जाते हैं?

आपको क्यों लगता है कि ये संभावनाएँ एक ही चीज़ नहीं हैं?

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

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

Comments

यह बस सच नहीं है:"Well written code can be read by people who aren't familiar with the specific programming language."

— एंड्रेस एफ।

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

— बेन वोइग्ट

मेरा मानना ​​है कि निम्नलिखित मुहावरेदार एपीएल है x[⍋x←6?40]:। आपको क्या लगता है यह क्या करता है? मुझे यकीन है कि पता नहीं है ...

— ब्रेडशाम

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

— इज़काता

ब्रेंडन, आपकी अच्छी तरह से लिखी गई परिभाषा गैर-मानक है। अच्छी तरह से लिखा हमेशा भाषा और उसके समुदाय के सापेक्ष होता है। भाषा X में एक कार्यक्रम अच्छी तरह से लिखा है अगर यह छोटी गाड़ी नहीं है, तो यह कुशल और स्पष्ट है ... दिए गए दर्शकों के लिए! यह सामान्य रूप से लिखित भाषा पर लागू होता है: हमेशा अपने दर्शकों को जानें। वैज्ञानिक कागज के लिए क्या कहना (उपयुक्त) है शायद आपकी माँ के लिए एक ईमेल के लिए उपयुक्त नहीं है।

— एंड्रेस एफ।