कार्यात्मक प्रोग्रामिंग पर विचार करने के लिए उच्च स्तरीय प्रबंधन को समझाने के लिए अच्छे तथ्यात्मक तर्क क्या होंगे? [बन्द है]

Question

क्यों कार्यात्मक प्रोग्रामिंग एक अच्छा विचार है (इसके लिए बहुत से लोग एक खुले प्रश्न के रूप में रह गए हैं, और सही तरीके से) के लिए "सैद्धांतिक" तर्कों के टन हैं ।

हालांकि, उनमें से अधिकांश या तो सिद्धांत ("लालित्य", आदि ...) से बने तर्क हैं, या, डेवलपर्स के उद्देश्य से।

समस्या यह है, उनमें से ज्यादातर पूरी तरह से बेकार हैं जब किसी व्यक्ति का लक्ष्य किसी बड़ी कंपनी के वरिष्ठ प्रबंधन को प्रस्तुत करना है , जिनमें से कुछ डेवलपर्स भी नहीं हैं, और जिनमें से ज्यादातर व्यापारिक तर्कों के बारे में ध्यान रखते हैं : लागत, मानव पूंजी प्रबंधन , उत्पाद वितरण, ग्राहक सेवा और राजस्व; सैद्धांतिक बिंदुओं पर मात्रात्मक तथ्यों के साथ-साथ तथ्यों के साथ काफी बैकअप नहीं लिया जा सकता है।

क्या उन व्यावसायिक चिंताओं को दूर करने के लिए कोई सम्मोहक तर्क प्रस्तुत करना है जहाँ तक कि कार्यात्मक प्रोग्रामिंग को अवधारणा (किसी विशिष्ट भाषा) के रूप में अपनाने पर विचार नहीं किया गया है, बनाम प्रक्रियात्मक / ओओपी के विशिष्ट मिश्रण, उदाहरण के लिए जावा / सी ++ / (पर्ल | ​​पायथन) ।

अधिमानतः, मैं उन तर्कों की तलाश कर रहा हूं जो मात्रात्मक हैं और / या अनुसंधान या मामले के अध्ययन पर आधारित हैं। उदाहरण के लिए "इस संदर्भ के अनुसार, लिस्प / एफ # में मल्टीथ्रेडेड सिस्टम की बग दर जावा का 10% है" या "शीर्ष 3 हितों के रूप में कार्यात्मक प्रोग्रामिंग नामक वांछित प्रौद्योगिकी की वरीयताओं को व्यक्त करने वाले शीर्ष स्नातकों के 80%"।

मुझे पता है कि ग्राहम ने एक स्टार्प के लिए कार्यात्मक प्रोग्रामिंग के उपयोग के मामले प्रस्तुत किए हैं और उनके कुछ तर्क के लिए खुला होगा, यह मानते हुए कि वे एक बड़ी स्थापित कंपनी के लिए मान्य हो सकते हैं।

_{psI'm पूरी तरह से जानते हैं कि आप पर्ल, कार्यात्मक पायथन, और संभवतः (संभवतः) जावा 8 या C ++ 14. में कार्यात्मक प्रोग्रामिंग के करीब कुछ भी कर सकते हैं, लेकिन इसका मतलब यह नहीं है कि पर्ल, C ++ या जावा का उपयोग करने वाला संगठन कार्यात्मक का समर्थन करेगा। उन भाषाओं में भी OOP / प्रक्रियात्मक दृष्टिकोण}

_{इस भाषा के प्रयोजनों के लिए, "बड़े" को समर्पित विकास इंजीनियरिंग / उपकरण समूह के लिए पर्याप्त रूप से परिभाषित किया गया है, जो सभी डेवलपर्स को उपयोग / करने की अनुमति देता है; और कम अंत में कम से कम सैकड़ों डेवलपर्स} ।

Comments

आप इस एक की तलाश में हैं, मुझे लगता है? paulgraham.com/avg.html वास्तव में, मुझे लगता है कि लेख थोड़ा पुराना है, बीच में कई कार्यात्मक अवधारणाओं ने मुख्यधारा की भाषाओं में प्रवेश किया है।

— Doc Brown

उच्च-स्तरीय प्रबंधन को लानत क्यों देनी चाहिए कि प्रोग्रामिंग भाषाओं और विधियों का क्या उपयोग किया जाता है? वे इस तरह के फैसले में क्यों शामिल होंगे? निश्चित रूप से यह तकनीकी प्रबंधकों के लिए एक मामला है?

— उच्च प्रदर्शन मार्क

@HighPerformanceMark: "उच्च-स्तरीय प्रबंधन" के लिए "तकनीकी प्रबंधकों" को प्रतिस्थापित करें और प्रश्न का फिर से मूल्यांकन करें।

— रॉबर्ट हार्वे

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

— जेएफओ

आपके द्वारा वर्तमान में उपयोग की जाने वाली भाषाओं के लिए प्रबंधन ने कौन से व्यावसायिक तर्क दिए?

— जेएफओ

Answer 1

एक बहुत ही सरल तर्क है, जो कम से कम प्रबंधन को खुश कर सकता है।

यह सर्वविदित है कि आधुनिक कंप्यूटर "तेज" नहीं बन रहे हैं जैसे वे हुआ करते थे, क्योंकि आवृत्ति स्केलिंग, अब के लिए, सीमा को मारा। वे कोर को जोड़कर अपनी संभावित उत्पादकता बढ़ाते हैं।

इसका तात्पर्य यह है कि इस वास्तुकला से सबसे अधिक लाभान्वित होने के लिए, कार्यक्रमों को समांतर बनाना होगा। लेकिन समानांतर प्रोग्रामिंग अनुक्रमिक प्रोग्रामिंग की तुलना में कठिन है, बहुत सी नई चुनौतियों के कारण यह ( व्यापक अवलोकन के लिए विकी लेख से परामर्श करें)।

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

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

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

Comments

यदि आप इन शोधों के लिए वास्तविक शोध / साक्ष्य प्राप्त कर सकते हैं तो उन्हें वापस करने के लिए - विशेष रूप से "कार्यात्मक भाषाएं इन कुछ चुनौतियों से छुटकारा पाने में मदद करती हैं" - अब तक यह सबसे अच्छा उपलब्ध उत्तर होने की ओर अग्रसर है।

— DVK

यह बहुत ही सवाल पहले से ही कई बार चर्चा की गई है, जैसे quora.com/Why-does-functional-programming-favor-concurrency या stackoverflow.com/questions/474497/...

— Ashalynd

सिवाय इसके कि कई ओओपी भाषाएँ कार्यात्मक प्रोग्रामिंग का समर्थन करती हैं, इसलिए आप बच्चे को स्नान के पानी से बाहर फेंकने के साथ कार्यात्मक पहलुओं का उपयोग कर सकते हैं।

— एंडी

सही है, सवाल "कार्यात्मक प्रोग्रामिंग" के बारे में था "कार्यात्मक भाषाओं" के बारे में नहीं। शब्दशः बदल जाएगा।

— आशुलिपि

Answer 2

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

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

तो जिस्ट है: टीम के अन्य सदस्यों, या आपकी टीम के नेताओं को समझाएं, लेकिन, उच्च-स्तरीय प्रबंधन नहीं!

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

Comments

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

— डीवीके

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

— user253751

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

— जेएफओ

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

— Cort Ammon

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

— जूल्स

Answer 3

यह समझने के लिए कि कार्यात्मक प्रोग्रामिंग को दुनिया भर में क्यों नहीं लिया गया है, आपको प्रोग्रामिंग भाषा के निर्णयों के पीछे कॉर्पोरेट सोच को समझना होगा। एक पल के लिए जावा पर लेने के लिए:

1. वहाँ प्रोग्रामर की सेनाएँ उपलब्ध हैं जो साधारण जावा कोड के रिएम्स लिख सकते हैं। यह लिस्प या हास्केल (या यहां तक ​​कि स्काला) प्रोग्रामर का सच नहीं है।
2. हर कोई जावा का उपयोग कर रहा है, इसलिए यह अच्छा होना चाहिए। कोरोलरी: प्रबंधकों को जावा की अपनी पसंद का औचित्य साबित करने की ज़रूरत नहीं है। कुछ अस्पष्ट भाषा जो कमांड संरचना में किसी ने कभी नहीं सुनी है।

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

अपने लक्ष्य को एक सॉफ्टवेयर डेवलपर के रूप में विकसित करना, आपका सबसे अच्छा दांव है

1. अपने मौजूदा कार्यक्रमों में कार्यात्मक अवधारणाओं को शामिल करें जहां वे उपयोगी और उपयुक्त हैं,
2. नई कार्यात्मक भाषा सुविधाओं का उपयोग करें क्योंकि वे भाषा में जोड़े जाते हैं, और
3. ऑब्जेक्ट-ओरिएंटेड डिज़ाइन पैटर्न सीखें, जिनमें से कुछ OO भाषाओं में भाषा की कमियों को दूर करने के लिए मौजूद हैं जो कार्यात्मक भाषाओं में मौजूद नहीं हैं।

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

Comments

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

— डीवीके

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

— DVK

Nouns के राज्य के लिए +1। मैं इसे "द वॉर बिटवीन नाउन्स एंड वर्ब्स" कह रहा हूं।

— रोब

@Dvk: किसी भी चीज के प्रबंधन को समझाने का तरीका समय शुरू होने के बाद से ही है: उन्हें दिखाएं कि यह कैसे उन्हें पैसे बचाएगा।

— रॉबर्ट हार्वे

Answer 4

मेरे (कुछ हद तक निंदनीय) अनुभव में, एक दुकान के लिए काम करना, जहाँ हमने कार्यात्मक प्रोग्रामिंग का उपयोग किया था, और कई अन्य लोगों से साक्षात्कार किया था:

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

Answer 5

ऊपरी प्रबंधन के लिए विचार करने वाली चीजें जब / यदि ऊपरी प्रबंधन प्रोग्रामिंग भाषाओं का चयन करने में शामिल है (जो विषम है, तो उन्हें इसे विश्वसनीय, जानकार लोगों (प्रौद्योगिकी और व्यवसाय प्रेमी दोनों) पर छोड़ देना चाहिए:

• उत्पादकता
  • वर्तमान और भविष्य के कर्मचारी दोनों
  • सभी भूमिकाएं (आर्किटेक्ट, डेवलपर्स, परीक्षक, ओपी, ...)
• समर्थित मंच
  • ऑपरेटिंग सिस्टम, (हार्डवेयर)
• भाषा / मंच का प्रकाशक
  • लाइसेंस
• भाषा / मंच की परिपक्वता
  • प्रकाशक और / या समुदाय द्वारा / का समर्थन
  • पुस्तकालय
• वर्तमान कोड आधार माइग्रेट करना
  • या के साथ एकीकरण

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

Comments

व्यवसाय भी लोगों को काम पर रखने के बारे में चिंतित हैं, इसलिए यदि एक कार्यात्मक देव को बदलने के लिए कठिन है तो मैं कहूंगा कि उनके लिए इस तरह के फैसलों में शामिल होने का एक अच्छा कारण है।

— एंडी

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

— Erno

क्या वास्तव में एक कार्यात्मक डेवलपर को बदलना मुश्किल है? इंटरनेट और अन्य साइटों पर पोस्ट करने वाले सूचित डेवलपर्स की संख्या से, मुझे संदेह है कि प्रबंधकों की तुलना में बहुत अधिक कार्यात्मक डेवलपर्स हैं।

— जियोर्जियो

@ जियोर्जियो - मैंने कभी नहीं कहा कि उन्हें प्रतिस्थापित करना कठिन है लेकिन मेरा अनुभव है कि उपलब्धता स्थान से स्थान तक भिन्न हो सकती है। कुछ कॉलेज स्नातकों ने कभी भी मूल बातें नहीं सीखीं जबकि कुछ विश्वविद्यालय उनके विशेषज्ञ हैं। एक व्यवसाय के लिए दीर्घकालिक और नए किराए की अपेक्षित आवश्यकता को देखना बहुत महत्वपूर्ण है।

— एर्नो

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

— जियोर्जियो

Answer 6

मुझे नहीं लगता कि तर्क या तथ्य मदद करेंगे। और निश्चित रूप से उन समस्याओं को बताए बिना नहीं जिन्हें आप हल करना चाहते हैं।

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

यदि आप इस तरह के निर्णय को चुनौती देना चाहते हैं जैसे "हम सभी कंप्यूटरों के अंत तक भाषा की तरह सी से चिपके रहेंगे" तो आपको कुछ तर्क देने से ज्यादा कुछ करना होगा।

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

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

ध्वनि वास्तु निर्णय के साथ आने के लिए महत्वपूर्ण है:

• स्टेक होल्डर्स (प्रबंधन, उपयोगकर्ता, प्रशासक, बिक्री, ग्राहक ...) से इनपुट प्राप्त करें
• उस इनपुट पर बेस निर्णय
• स्पष्ट रूप से संवाद करें: क्या (प्रस्तावित) निर्णय हैं; वे किस जोखिम को कम करने का लक्ष्य रखते हैं; परस्पर विरोधी हितों में और कुछ देरी के साथ: उन्होंने कितना अच्छा काम किया।

यदि आप 10K + कर्मचारियों के साथ एक बड़ी कंपनी के लिए काम करते हैं, तो निम्नलिखित कुछ सबक सीखने के लिए तैयार रहें।

• नीचे की पंक्ति के लिए कोडिंग की गति वास्तव में प्रासंगिक नहीं है।
• दशकों के पैमाने पर स्थिरता जैसी चीजें हैं।
• जिन समस्याओं के बारे में आपको लगता है कि आप कार्यात्मक भाषाओं का उपयोग करके हल कर सकते हैं वे वास्तव में नीचे की रेखा के लिए प्रासंगिक नहीं हैं
• 1000 डेवलपर्स को प्रशिक्षण देने जैसी समस्याएं, डेवलपर्स द्वारा लिखित कोड बेस को बदलने और बनाए रखने की प्राकृतिक प्रतिरोध का उपयोग की गई तकनीक में 5 वर्ष से कम अनुभव के साथ होती हैं।

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

यदि यह प्रक्रिया आपके द्वारा किए गए कुछ क्षेत्रों में एक कार्यात्मक दृष्टिकोण का उपयोग करने के लिए सिफारिश का उत्पादन करती है।

यदि यह प्रक्रिया मौजूदा मुख्य प्रोग्रामिंग भाषा जो आप के रूप में अच्छी तरह से किया जाता है उससे परे जाने वाले कार्यात्मक दृष्टिकोणों को अनदेखा करने की सिफारिश पैदा करती है।

बुरी खबर यह है: कंपनी के आकार और शैली के आधार पर यह आसानी से कुछ वर्षों या दशकों तक ले सकता है।

अच्छी खबर यह है: आप रास्ते में बहुत कुछ सीखेंगे।

चूंकि पहला कदम बात करना शुरू करना है और विशेष रूप से वरिष्ठ प्रबंधन को सुनना है, मैं सिर्फ सुनने के लिए पढ़ना शुरू करने की सलाह दूंगा ।

Answer 7

एक अच्छा दृष्टिकोण यह दिखाना होगा कि यह उद्योग में अच्छे परिणाम दिखाए गए हैं और अपनाए गए हैं।

आप कुछ डेटा प्राप्त कर सकते हैं:

• http://www.quora.com/What-companies-use-a-functional-language-as-an-official-language

• http://pchristensen.com/blog/lisp-companies/

आदर्श रूप से, कुछ सूचीबद्ध कंपनियों में प्रबंधकों से बात करने की कोशिश करें, खासकर यदि आपके उद्योग में, और उनसे नंबर और प्रशंसापत्र प्राप्त करें।

Google के पास Haskell, OCaml, आदि के समान कई अन्य लिंक हैं।

Comments

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

— रॉबर्ट हार्वे

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

— DVK

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

— रॉबर्ट हार्वे

@RobertHarvey (1) मैं इसे वापस लेता हूं। अब उपयोगी उत्तरों में से दो सबसे कम मतदान वाले हैं :) (नया जो अभी पोस्ट किया गया है उसे तथ्यों के साथ बेहतर बनाया जा सकता है लेकिन यह एक अच्छी शुरुआत है)।

— DVK

@ रोबर्टहवे - हाँ। सवाल यह नहीं था कि "क्या एफपी एक अच्छी चीज है" या "क्या लोगों को समझाना संभव है कि एफपी अच्छी चीज है"। यह सवाल बहुत सटीक था कि "कौन सी दलीलों का इस्तेमाल किया जा सकता है, जब यह समझाने की कोशिश की जाती है कि यह एक अच्छी बात है।" यह नहीं था "मैं अपने काम में एफपी को कैसे चुपके से पेश कर सकता हूं / सकारात्मक तरीके से कोडिंग कर सकता हूं" या तो, जो आपने उत्तर दिया है - अगर वह एक विकल्प था तो मैं पहली जगह में नहीं पूछूंगा, मैं कोडिंग करूंगा: )

— डीवीके

Answer 8

आप इस पर गलत दिशा से आ रहे हैं।

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

बल्कि, आपको इस बारे में सोचना चाहिए कि वर्तमान व्यवसाय की आवश्यकता क्या है और यह कैसे सबसे अच्छी सेवा है। यदि ऐसा होता है कि यह एक कार्यात्मक प्रतिमान का उपयोग करके सबसे अच्छा परोसा जाता है तो - याय! - आप खेलने के लिए मिलता है। लेकिन यदि आप एक निष्पक्ष विश्लेषण करते हैं, तो परिचालन व्यवसाय की जरूरतों, सहकर्मियों के आवश्यक प्रशिक्षण, भविष्य के प्रोग्रामर की पृष्ठभूमि, रखरखाव, और इसी तरह और आगे, अक्सर यह नहीं होगा।

Comments

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

— VF1

Answer 9

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

यह कहा जा रहा है, यहां तकनीकी पृष्ठभूमि (पहले मामले) और एक (दूसरे मामले) के बिना लोगों को समझाने के लिए कुछ संकेत दिए गए हैं।

पहला मामला

अगर आप प्रोग्रामिंग जानने वाले लोगों से बात कर रहे हैं , तो कार्यात्मक प्रोग्रामिंग प्रतिमानों के बिना लिखे गए कोड की तुलना करना और कार्यात्मक शैली में लिखे गए समान कोड के बारे में आश्वस्त हो सकते हैं:

नमूना C # कोड जो अनिवार्य शैली का उपयोग करता है:

var categorizedProducts = new Dictionary<string, List<Product>>();

// Get only enabled products, filtering the disabled ones, and group them by categories.
foreach (var product in this.Data.Products)
{
    if (product.IsEnabled)
    {
        if (!categorizedProducts.ContainsKey(product.Category))
        {
            // The category is missing. Create one.
            categorizedProducts.Add(product.Category, new List<Product>());
        }

        categorizedProducts[product.Category].Add(product);
    }
}

// Walk through the categories.
foreach (var productsInCategory in categorizedProducts)
{
    var minimumPrice = double.MaxValue;
    var maximumPrice = double.MinValue;

    // Walk through the products in a category to search for the maximum and minimum prices.
    foreach (var product in productsInCategory.Value)
    {
        if (product.Price < minimumPrice)
        {
            minimumPrice = product.Price;
        }

        if (product.Price > maximumPrice)
        {
            maximumPrice = product.Price;
        }
    }

    yield return new PricesPerCategory(category: productsInCategory.Key, minimum: minimumPrice, maximum: maximumPrice);
}

समान कोड को मन में कार्यात्मक प्रोग्रामिंग के साथ फिर से लिखा गया:

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

फिर उनसे पूछें:

1. एक प्रोग्रामर पहले नमूने में कितनी गलतियाँ कर सकता है? दूसरे के बारे में क्या?

2. गलतियों को देखना कितना मुश्किल है?

3. कोड को संशोधित करना कितना मुश्किल है?

सभी तीन कारक उत्पादकता को प्रभावित करते हैं, और इसलिए उत्पाद की लागत।

दूसरा मामला

यदि आप ऐसे लोगों के साथ काम कर रहे हैं जो प्रोग्रामिंग नहीं जानते हैं, तो कोई भी तकनीकी सामान नहीं है जो आप उन्हें बता सकते हैं। समझाने के तरीकों में से एक आपके काम और अपने सहकर्मियों के काम पर कार्यात्मक प्रतिमानों के वास्तविक प्रभाव को दिखाना है।

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

Comments

मैंने देखा कि आपने वहां क्या किया है, लेकिन आपका उदाहरण पूरी तरह से आश्वस्त नहीं है। आप मूल रूप से अपने कार्यात्मक उदाहरण को एक अनिवार्यता में अनियंत्रित कर देते हैं, जो कि ऐसा कुछ नहीं है जो किसी भी व्यावहारिक कॉर्पोरेट चिंता में होगा। आपका yield returnएक धोखा है, यह इस बात का उदाहरण है कि आप किसी भी तरह से लिनक परिदृश्य में उपयोग किए जाने वाले कोड को कैसे तैयार करेंगे, और आपके ifबयानों को टर्नरी ऑपरेटरों के साथ अधिक आसानी से लिखा जा सकता है। आपके पहले उदाहरण को अनिवार्य कार्यों में बदला जा सकता है, ताकि जटिलता छिपी हो।

— रॉबर्ट हार्वे

@RobertHarvey आप पहले उदाहरणों को अनिवार्य कार्यों के एक समूह में बदल सकते हैं, लेकिन वे कस्टम अनिवार्य कार्य होंगे जो उस क्वेरी के लिए विशिष्ट हैं; अपने आप को यह समझाने के लिए कि क्वेरी सही है, आपको अभी भी यह देखना है। यह रिफैक्टिंग अनिवार्य कोड के आकार को और भी ऊपर उड़ा देगा। यहां तक ​​कि अगर आप इसे केवल कॉम्पैक्ट रूप से लिख सकते हैं, तब भी आपको कोड को ध्यान से पढ़ना होगा क्योंकि सभी काम साइड इफेक्ट्स के माध्यम से हो रहे हैं; आप एक पंक्ति के अंत में एक टर्नरी ऑपरेटर के दूसरे भाग में किए जा रहे दुष्प्रभाव को याद नहीं करना चाहेंगे।

— डोभाल

@RobertHarvey मुझे यकीन भी नहीं है कि दो कोड स्निपेट समतुल्य हैं, क्योंकि केवल पुनरावृत्ति छोड़ देने के बजाय दूसरी सूची बनाने से अनिवार्य "फ़िल्टर" होता है। क्या असली समान उपयोग केवल एक लूप नहीं होगा और इस प्रकार और भी अधिक गहराई से नेस्टेड होगा?

— डोभाल

कोई सवाल नहीं है कि आप एक अन्यथा अनिवार्य / ओओ भाषा में कार्यात्मक अवधारणाओं को शामिल करने के लिए एक अच्छा मामला बनाते हैं, लेकिन जरूरी नहीं कि कॉर्पोरेट वातावरण में पूरी तरह कार्यात्मक भाषाओं का उपयोग करने के लिए एक अच्छा मामला है जो पहले से ही जरूरी है।

— रॉबर्ट हार्वे

आपके उदाहरण के साथ एक और (शायद कम वैध) समस्या: मैं पहला उदाहरण पूरी तरह से पठनीय ज्यादातर गैर-एफपी पर्ल में लिख सकता हूं - मैं अनुमान लगा रहा हूं - मात्रा का 30%। कम हो सकते हैं। इस पर निर्भर करता है कि आप स्वीकार करते हैं map/ grepगैर-एफपी के रूप में। IOW, आप तर्क प्रस्तुत कर रहे हैं कि जावा एक खराब भाषा है, न कि एफपी एक अच्छा तरीका है।

— DVK