कार्यात्मक प्रोग्रामिंग उद्योग में अधिक लोकप्रिय क्यों नहीं है? क्या अब इस पर पकड़ है? [बन्द है]


61

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

हालांकि, जब नौकरी की तलाश की जाती है, तो ऐसी नौकरी को देखना बहुत कम होता है जहां एक कार्यात्मक प्रोग्रामिंग भाषा का ज्ञान आवश्यक है।

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


3
कुछ हद तक, मैं आपके प्रश्न के आधार से असहमत हूं। जावा और जावास्क्रिप्ट जैसी भाषाओं में "कार्यात्मक भाषाओं" से प्रेरित भाषा सुविधाएँ जोड़ी जा रही हैं। वास्तव में, जावास्क्रिप्ट हमेशा (कुछ मायनों में) एक कार्यात्मक भाषा रही है, हालांकि बहुत से लोगों ने हाल ही में इसका एहसास नहीं किया।
MatrixFrog

1
@ मेट्रिक्सफ्रॉग: कोई यह पूछ सकता है कि "फुल-फ़ेड एफपी भाषा को अपनाने के बजाय गैर-कार्यात्मक भाषाओं में कुछ कार्यात्मक अवधारणाओं को जोड़कर केवल आधा रास्ता क्यों जाना है? आखिरकार सभी प्रतिमान कई वर्षों से आसपास हैं और बहुत परिपक्व हैं।"
जियोर्जियो

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

जवाबों:


38

मैं कहूंगा कि कार्यात्मक प्रोग्रामिंग अधिक प्रचलित नहीं होने का एक कारण ज्ञान का अभाव है। मेरा अनुभव यह है कि निगम उन तकनीकों को लागू करने के मामले में बहुत जोखिम में हैं जो मुख्य धारा नहीं हैं और वे आजमाए हुए और सच्चे ढांचे (java, c ++, c #) में निवेश करेंगे। यह केवल तब होता है जब कोई व्यावसायिक आवश्यकता होती है (जैसे एरिक्सन में) कि नए प्रतिमानों पर विचार किया जाता है। लेकिन एरिक्सन के मामले में भी मैंने सुना है कि प्रबंधन ने मांग की है कि सी ++ का उपयोग किया जाए और जो आर्मस्ट्रांग को सी ++ में कॉल को मिटाने के लिए मजबूर किया गया था !! यह दिखाना चाहिए कि नई तकनीकों को लागू करने के लिए अनिच्छुक निगम कैसे हैं!


9
किसी भी तरह से कार्यात्मक प्रोग्रामिंग 'नया' कैसे है?
इवान प्लाइस

7
मुझे लगता है कि उनका मतलब 'नए' के ​​बजाय 'अप्रयुक्त' था।
विन्को वर्सालोविच

9
तो यह अप्रयुक्त है ... क्योंकि यह अप्रयुक्त है? हम्म।
एलेक्स बारानोस्की

21
@ एलेक्स - बिल्कुल। बेकार है, है ना?
कीथ्स

5
@ Stargazer712: वे कारण क्या हैं? मैं ऐसे बहुत से डेवलपर्स को जानता हूं जो कार्यात्मक प्रोग्रामिंग नहीं जानते हैं, इसलिए अज्ञानता मेरे लिए समझ में आती है। क्या कार्यात्मक प्रोग्रामिंग में अतीत में एक बड़ी विफलता है जिसने उद्योग को उस से दूर कर दिया है जिससे मैं अनजान हूं?
सीन मैकमिलन

67

मैं एक प्रोफेसर था और प्रोग्रामर की तरह, प्रोफेसर हमेशा नेक्स्ट बिग थिंग की तलाश में रहते हैं। जब उन्हें लगता है कि वे एक मिल गया है, तो वे इसे एक बैंडवागन बनाते हैं, और हर कोई ढेर पर। चूंकि वे उन छात्रों को उपदेश दे रहे हैं जो सोचते हैं कि प्रोफेसर वास्तव में स्मार्ट होने चाहिए, अन्यथा वे प्रोफेसर क्यों होंगे, उन्हें कोई विरोध नहीं है।

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

यह देखते हुए कि, कार्यात्मक प्रोग्रामिंग आपके तरकश में होने के लिए सिर्फ एक तीर है, केवल एक ही नहीं है, जैसे कि ओओपी केवल एक ही नहीं है।

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


1
यह एक बहुत अच्छी टिप्पणी है। +1 आपके तरकश में तीर के लिए और ट्रेडऑफ़ के साथ समाधान की श्रेणी में।
user21007

2
QC के लिए +1। कि एमएससी परीक्षण, कोड समीक्षा, कोड जटिलता और इसी तरह के विषयों को समर्पित करने के साथ बहुत अधिक उपयोगी होता। स्वचालित रूप से यह सत्यापित करने में सक्षम होने के नाते कि एक प्रोग्राम वह करता है जो कि अंतिम पैच के बाद होना चाहिए "यह अब काम करना चाहिए" हाथ से लहराती गिबरिश की संख्या के लायक है।
l0b0

5
@ l0b0: धन्यवाद, हालांकि वास्तव में मैं क्या और कैसे पढ़ाया जाता है की गुणवत्ता नियंत्रण के बारे में सोच रहा था। जैसा कि यह है, सीएस प्रोफेसर केवल वही सिखाते हैं जो उन्हें व्यक्तिगत रूप से सबसे दिलचस्प लगता है। इसकी तुलना इंजीनियरिंग से करें, जहां उद्योग, या चिकित्सा के साथ परस्पर संबंध हैं, जहां वास्तविक दुनिया की प्रासंगिकता बहुत अधिक है। IME, CS प्रोफेसर वास्तविक दुनिया का आंकलन करते हैं कि वास्तविक दुनिया में क्या मायने रखता है, लेकिन अध्यापन कार्य करने के लिए उत्सुक नहीं होते हैं - बल्कि वे यह जानने के लिए उत्सुक रहते हैं कि प्रोफेसर सबसे अधिक उत्साहित थे या नहीं।
माइक डनलवे

@ माइक: बस किसी भी आधुनिक भाषा के बारे में? क्या आप C ++ और Java शामिल हैं?
केविन क्लाइन

+1। खुद मैने इससे बेहतर नहीं कहा होता।
रिवालक

25

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


48
मैं असहमत हूं। कार्यात्मक प्रोग्रामिंग भाषाएं एक राज्य के उपयोग को कम करने की कोशिश करती हैं, और इसके द्वारा कम जटिल हो जाती हैं। एक कार्यात्मक भाषा में प्रोग्राम किए गए प्रोग्राम परीक्षण और रीफैक्टर करने के लिए भी आसान है।
जोनास

7
@ जोनास: बहुत सारे प्रोग्रामर को लगभग सभी राज्यों को मिलाकर एक प्रोग्राम लिखना बेहद मुश्किल लगता है। उस दृष्टिकोण से, यह वास्तव में एक अधिक जटिल है। (कृपया ध्यान दें कि मैं किसी भी तरह से कार्यात्मक प्रोग्रामिंग की उपयोगिता पर बहस नहीं कर रहा हूँ!)
ShdNx

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

16
कठिनाई और जटिलता के बीच अंतर है। OOP निश्चित रूप से संरचित प्रोग्रामिंग की तुलना में अधिक कठिन है क्योंकि यह अधिक अवधारणाओं को जोड़ता है। बड़ी मात्रा में कोड के लिए, वे कोड को एक संरचना प्रदान करके जटिलता को कम करते हैं। एफपी एक ही बात है: यदि आप केवल दो लाइनें लिख रहे हैं, तो यह ओवरकिल की तरह लगता है, लेकिन अगर आपका कोड काफी बड़ा है, तो कोडिंग कोड के रूप में स्टेटलेस सबयूनिट स्केलेबिलिटी में सुधार करता है और कोड की जटिलता को कम करता है।
मुहम्मद अल्करौरी

6
कार्यात्मक प्रोग्रामिंग का एक मुख्य जोर कंपोजिबिलिटी है। यदि यह जटिलता के प्रबंधन के लिए एक उपकरण नहीं है, तो मुझे नहीं पता कि क्या है।
dan_waterworth

23

कार्यात्मक प्रोग्रामिंग निश्चित रूप से पकड़ना शुरू कर रही है - धीरे-धीरे लेकिन निश्चित रूप से।

उदाहरण के लिए, मैं जो स्टार्टअप बना रहा हूं, वह निम्न कारणों से प्राथमिक विकास भाषा के रूप में एक कार्यात्मक भाषा (क्लोजर) का उपयोग कर रहा है:

  • उत्पादकता - एफपी सीखना कठिन है, लेकिन एक बार जब आप इसे लटका लेते हैं तो शक्ति और अभिव्यक्तता के मामले में हरा देना बहुत कठिन है। मैं संभवतः सी # या जावा में जो कुछ भी होगा उसकी तुलना में किसी भी कार्यक्षमता को लागू करने के लिए लाइनों की संख्या के बारे में 1/10 वीं लिख रहा हूं।

  • विश्वसनीयता और शुद्ध कार्य राज्य की वस्तुओं की तुलना में तर्क और परीक्षण के लिए बहुत आसान हैं। इसलिए आप बेहतर परीक्षण लिख सकते हैं और अपने कोड की शुद्धता को अधिक आसानी से मान्य कर सकते हैं।

  • कंजेंसी - कार्यात्मक भाषा अपरिवर्तनीयता पर जोर देती है, जिसमें कई कोर पर प्रभावी रूप से चलाने के लिए समवर्ती अनुप्रयोगों के लिए भारी लाभ हैं। और यह पसंद है या नहीं, कई कोर पर चलना भविष्य है। Http://www.infoq.com/pretations/Value-Identity-State-Rich-Hickey को देखें कि यह इतना महत्वपूर्ण क्यों है

  • संगतता / प्रतिरूपकता - कार्यात्मक भाषा जटिल OO प्रणालियों की तुलना में एक साथ प्लगिंग घटकों को अधिक आसानी से उधार देती प्रतीत होती है। मैंने अभी भी इसके लिए सभी कारणों का पता नहीं लगाया है, लेकिन इसका एक हिस्सा इस तथ्य से उपजा है कि आपके पास सभी "आकस्मिक जटिलता" नहीं है जो OO मॉडल अपने साथ घसीटते हैं। स्टुअर्ट हल्लोवे द्वारा रेडिकल सिम्पलिसिटी पर बात इन विचारों को बहुत अधिक गहराई से तलाशती है।

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


+1, मुझे आपके निर्णय लेने की प्रक्रिया को सुनने में बहुत दिलचस्पी होगी कि आपने क्लोझर को क्यों चुना। (मैं क्लोजर के लिए या विरोधी नहीं हूं, मुझे बस दिलचस्पी है)।
dan_waterworth

4
"एफपी सीखना कठिन है": किसी भी प्रतिमान को सीखना कठिन है। मुझे याद है कि यथोचित रूप से उत्पादक होने के लिए पर्याप्त अनुभव होने से पहले मैंने अनिवार्य कोड (पास्कल) के साथ कितने घंटे बिताए थे। मुझे लगता है कि एफपी कम जाना जाता है क्योंकि कई प्रोग्रामर पहले एक अनिवार्य भाषा सीखते हैं और एक बार जब वे सीखते हैं कि उन्हें कैसे कुछ और देखने का समय नहीं है। मैं पूर्णकालिक C ++ प्रोग्रामर हूं और मैं काम के बाद शाम को स्काला सीख रहा हूं। अगर मेरे पास देखने के लिए एक परिवार था तो मैं बस इसके बारे में भूल सकता था।
जियोर्जियो

1
मुझे लगता है कि पहले 3 महान मामले हैं, हालांकि मैं 4 वें से असहमत हूं। OOP बेहद मॉड्यूलर और कंपोजिटल है; मेरे लिए यह इसकी सबसे बड़ी ताकत है। यह एनकैप्सुलेशन और अमूर्तता के माध्यम से जटिलता को छिपाने में भी बहुत अच्छा है।
डेस्परर्ट

1
@Giorgio। ठीक ठीक। "सीखना FP कठिन है, OOP सीखना आसान है" उतना ही बेतुका है जितना कि "स्पेनिश सीखना कठिन है लेकिन चीनी आसान है"। यह निर्भर करता है कि आपकी पहली भाषा कौन सी थी। और मैंने चीनी को OOP के लिए मनमाने ढंग से एनालॉग के रूप में नहीं चुना - क्योंकि OO मुहावरे hieroglyphs की तरह हैं: एक एक करके सीखना आसान है लेकिन उन सभी को याद रखना मुश्किल है और रचना करना असंभव है। एफपी एक वर्णमाला के साथ एक भाषा की तरह बहुत अधिक है: अलग-अलग पत्र अलगाव में बेकार हैं लेकिन नियमों के छोटे सेट के साथ कुछ भी रचना करने की अनुमति देते हैं
कोला

1
(जारी) इसलिए यह लोकप्रिय नहीं है - फिर भी - बहुत ही कारणों से। पहले वर्णमाला का आविष्कार और परिपक्व होने से बहुत पहले हीरोग्लिफ़ मौजूद था। यह एक और पीढ़ी ले सकता है जिसके पास
अल्फ़ाबेटिक

12

हत्यारे ऐप का अभाव

अरे, यहाँ यह एक ताजा लग रहा है। (खुदाई खोदो)

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

यहाँ मेरा बहुत सटीक दृष्टिकोण नहीं है कि आज जो कुछ भाषाएँ हमारे पास मौजूद हैं, उन्हें अपनाने का क्या तरीका है:

  • सी: हर जगह काम करता है (यह 70 और 80 के दशक के अंत में था)
  • C ++: GUI चौखटे (शुरुआती 90 के दशक)
  • जावा: सेब और सर्वलेट (90 के दशक के अंत में)
  • उद्देश्य- C: iOS ऐप्स (इससे पहले, OS X ऐप्स)
  • रूबी: रेल्स
  • C #: ASP.NET, WinForms
  • PHP: Wordpress, आदि।
  • जावास्क्रिप्ट: AJAX, विशेष रूप से चौखटे के माध्यम से
  • lua: खेल पटकथा, विशेष रूप से वाह

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

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

इसलिए, किसी भी कार्यात्मक भाषा को वास्तव में बंद करने की आवश्यकता होती है। वास्तविकता में, अभी तक कोई बहुत बड़ी कार्यात्मक भाषा नहीं है, लेकिन छोटे नखरों में बहुत कुछ हैं:

  • Emacs Lisp: डेवलपर्स द्वारा Emacs में 80 के दशक के बाद से लगातार उपयोग। ( शायद ही कभी कहीं और इस्तेमाल किया गया हो।)
  • एर्लांग: कहीं भी आप समवर्ती एजेंटों के बहुत सारे चाहते हैं।
  • योजना: शिक्षा
  • एपीएल / जे / के: वित्त (तर्क के लिए, इन कार्यों को कॉल करें)
  • आम लिस्प: "एआई" - यह वही है जो लोग कहते हैं कि इसका उपयोग किया जाता है, जो एक आशीर्वाद और अभिशाप है।

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

इस से, मैं कह सकता हूँ लगता है कि जो कार्यात्मक भाषाओं मैं कर रहे हैं वृद्धि पर:

  • क्लोजर: वेब प्रोग्रामिंग, एस्प। हरोकू के माध्यम से
  • स्काला: लिफ्ट (या शायद प्ले, इन दिनों) - जावा के बिना जेवीएम

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


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

1
@ डेस्पर्टर - मैं विशेष रूप से समतावादी बनने की कोशिश नहीं कर रहा था, जिसके बारे में मैंने जिन भाषाओं का उल्लेख किया है :) और सहमत हूं, कहानी कुछ वर्षों के अलावा पायथन की तरह लगती है।
जेसी मिलिकन जुएल

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

8

उसी कारण से कि लिस्प वास्तव में कभी नहीं पकड़ा (चलो फ्लीवर्स शुरू!)। फ़ंक्शनल प्रोग्रामिंग अनिवार्य और ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग की तुलना में एक बहुत ही विदेशी प्रतिमान है। यदि, CS छात्रों के विशाल बहुमत की तरह, आपने C से शुरुआत की और C ++ / Java में आगे बढ़े, तो आप इस तरह से सोचना नहीं चाहते हैं, जो पूरी तरह से सामान्य रूप से आपके सोचने के तरीके से पूरी तरह से रूढ़िवादी है।


2
विदेशी प्रतिमान? यह अनिवार्य प्रोग्रामिंग की तुलना में गणित के करीब है। यहाँ स्वीडन में मुझे लगता है कि विश्वविद्यालय में अधिकांश सीएस छात्र पहले थॉट फ़ंक्शनल प्रोग्रामिंग हैं। उदाहरण के लिए हमने C, एर्लांग और जावा से पहले स्टैंडर्ड एमएल के साथ शुरुआत की।
जोनास

4
काफी उचित। मुझे पता है कि यूके और भारत में इंजीनियरिंग के बहुत से छात्रों को पहले C, उसके बाद C ++ और / या Java पढ़ाया जाता है। अक्सर उन्हें एक कार्यात्मक भाषा बिल्कुल नहीं सिखाई जाती है।
चिन्मय कांची

13
@ जोनास वहाँ के कई लोगों के लिए, गणित एक विदेशी प्रतिमान है और जो कुछ भी प्रोग्रामिंग को गणित से दूर ले जाता है, उसे समझना आसान हो जाता है।
स्क्रिप्टोकलिप्स 20

5
मैंने ऐसे लोगों के बारे में सुना है, जिन्होंने कभी पेड़ों के बारे में नहीं सुना है, अकेले ही प्रोग्रामिंग करते हैं, स्नातक की उपाधि प्राप्त की है।
dan_waterworth

1
@ टक्स-डी, वास्तव में, नहीं, मैं यूके में छात्रों के बारे में बात कर रहा हूं।
दान_ वाटरवर्थ

6

चलो व्यवसायों और प्रोग्रामिंग पर विचार करें।

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

इसके अलावा, व्यवसायों में, सबसे सस्ता काम आमतौर पर वही होता है जो उन्होंने कल किया था। परिवर्तन, हालांकि, वांछनीय, महंगा है। यदि कोई कंपनी, C # /। NET समाधान से, F # से भी बदलने के लिए कहती है, तो उन्हें समस्याएँ होंगी। उनके प्रोग्रामर (जो संभवतः सबसे तेज प्रोग्रामर नहीं हैं) को एक नई भाषा सीखनी होगी, और दोनों में कुशल होना होगा, और दोनों को अक्सर उपयोग करना होगा। लंबे समय तक दोनों में दिनचर्या लिखी जाती। यदि वे हास्केल जैसी किसी चीज़ की ओर बढ़ना चाहते थे, या यदि वे पहली जगह में C ++ / MFC का उपयोग कर रहे थे, तो वे बहुत अधिक बदल रहे होंगे, और यह बहुत अधिक महंगा होगा।

इसके अलावा, C # प्रोग्रामर्स की आपूर्ति होने जा रही है, और आने वाले लंबे समय के लिए Microsoft समर्थन जारी रखना है। वर्तमान आईटी प्रथाओं को गिना जा सकता है। संस्थागत सहायता या प्रोग्रामरों की निरंतर उपलब्धता के आश्वासन के समान स्तर नहीं है।

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


2

आप पहले से ही कार्यात्मक शैली में कोड लिखते हैं, बस आप इसे नहीं जानते हैं।

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

मुझे लगता है कि कार्यात्मक भाषाएं बहुत सीमित हैं। इसलिए कार्यात्मक के साथ अनिवार्य भाषाओं की जगह, अनिवार्य भाषाओं को कार्यात्मक सुविधाएं मिलेंगी। आजकल लगभग हर प्रोग्रामिंग लैंग्वेज में क्लोजर और लैम्ब्डा हैं।


1

मेरा मानना ​​है कि आपके प्रश्न का केवल एक वास्तविक उत्तर है। आप बहुत सारे संबंधित कारणों से पता कर सकते हैं कि यह उत्तर क्यों है, लेकिन वे अलग-अलग प्रश्न हैं।

यह रहा:

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

क्या यह पकड़ रहा है? यह सब इस बात पर निर्भर करता है कि कार्यात्मक भाषाओं का उपयोग करने में विश्वास रखने वाले लोग आर्किटेक्ट बन रहे हैं और उन परियोजनाओं के लिए इसका उपयोग करना चाहते हैं, जिन पर वे काम करते हैं।


0

वास्तविक समस्या राज्य है।

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

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

इसलिए, हालांकि कार्यात्मक भाषाओं का कोई वैश्विक राज्य नहीं है, लेकिन उनके राज्य की जानकारी पैरामीटर और परिणाम के रूप में पारित की जाती है।

तो फिर सवाल यह हो जाता है कि भाषा समझ के पीछे कुशलता से राज्य को संभाल सकती है? खासकर जब डेटा का आकार वास्तुकला के आकार से अधिक हो।

हार्डवेयर साइड से इसे देख रहे हैं

ओएस ने पिछले कुछ वर्षों में पते की जगह को विज़ुअलाइज़ करने में बहुत मदद की है, इसलिए अनुप्रयोगों को आधिकारिक रूप से इसके बारे में चिंता करने की आवश्यकता नहीं है। लेकिन ऐसे अनुप्रयोग जो स्मृति दबाव के तीव्र हो जाने पर हार्डवेयर के जाल में गिरने की चिंता नहीं करते हैं (हार्डवेयर को घुमाने से आपकी प्रक्रिया क्रॉल में धीमी हो जाएगी)।

जैसा कि प्रोग्रामर का कार्यात्मक भाषा में राज्य पर सीधा नियंत्रण नहीं है, उन्हें इसे संभालने के लिए संकलक पर निर्भर होना चाहिए और मैंने ऐसी कार्यात्मक भाषाएं नहीं देखी हैं जो इसे अच्छी तरह से संभालती हैं।

सिक्के के नीचे की तरफ राज्य-पूर्ण प्रोग्रामर का राज्य पर सीधा नियंत्रण होता है और इस तरह वह कम मेमोरी की स्थिति की भरपाई कर सकता है। हालांकि मैंने कई प्रोग्रामर नहीं देखे हैं जो वास्तव में ऐसा करने के लिए पर्याप्त स्मार्ट हैं।

उद्योग की ओर से देखना:

उद्योग में बहुत सारे अकुशल राज्य-पूर्ण प्रोग्रामर हैं।

लेकिन समय के साथ इन कार्यक्रमों में सुधार को मापना आसान है। आप डेवलपर्स की एक टीम को इस समस्या पर फेंकते हैं कि वे कोड को बेहतर बना सकते हैं कि प्रोग्राम राज्य को कैसे संभालता है।

कार्यात्मक कार्यक्रमों के लिए सुधारों को मापना अधिक कठिन होता है क्योंकि आपको उन उपकरणों को सुधारने की आवश्यकता होती है जो कार्यक्रमों को बेहतर बनाएंगे (हम सिर्फ यह देख रहे हैं कि आवेदन कैसे अंतर्निहित स्थिति को कुशलतापूर्वक संभालते हैं, कार्यक्रम के समग्र सुधार को नहीं)।

इसलिए उद्योग के लिए मुझे लगता है कि यह कोड में सुधार को मापने की क्षमता के लिए नीचे आता है।

एक काम पर रखने के दृष्टिकोण से

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


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

1
कार्यात्मक भाषाओं में राज्य से निपटना बहुत आसान है, लेकिन इसके लिए जोर देने की आवश्यकता है। जबकि अपरिमेय भाषाओं में आप ऐसी प्रक्रियाएँ लिखते हैं जो राज्य को संशोधित करती हैं, कार्यात्मक भाषाओं में आप ऐसे कार्य लिखते हैं जो राज्य को संशोधित करने वाली प्रक्रियाएँ लौटाते हैं।
dan_waterworth

"कार्यात्मक भाषाओं में वैश्विक स्थिति नहीं है" - आपको वैश्विक राज्य की आवश्यकता नहीं है। बहुत सारे राज्य प्रबंधन मठों के माध्यम से किए जा सकते हैं।
अरुणव सान्याल

-3

इस सवाल का थोड़ा गलत आधार है। निम्नलिखित कारणों के लिए:

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

2
1) "लगभग सभी बड़े प्रोग्रामिंग प्रोजेक्ट इसका उपयोग कर रहे हैं"। मेरा अनुभव है कि यह वास्तविकता से दूर है। बहुत कम कंपनियां कार्यात्मक प्रोग्रामिंग का उपयोग कर रही हैं जैसा कि मुझे पता है। अधिकांश केवल जावा और C # का उपयोग करते हैं (भले ही C # को पिछले कुछ वर्षों में अधिक कार्यात्मक निर्माण मिले हों), C ++ और C.
जोनास

2
2) मेरा अनुभव इसके विपरीत है। विश्वविद्यालयों के लोग केवल वही होते हैं जो कार्यात्मक प्रोग्रामिंग जानते हैं। यहां स्वीडन में, अधिकांश विश्वविद्यालय पहले वर्ष से कार्यात्मक प्रोग्रामिंग सिखाते हैं। और एमआईटी जैसे विश्वविद्यालयों ने हाल ही में अपने पहले प्रोग्रामिंग कोर्स (स्कीम) में कार्यात्मक प्रोग्रामिंग का उपयोग किया है।
जोनास

@ जोनास: नहीं, प्रोग्रामिंग भाषा का इससे कोई लेना-देना नहीं है। बेशक C और C ++ और जावा आदि का उपयोग बड़ी संख्या में प्रॉजेक्ट्स द्वारा किया जाता है। कार्यात्मक प्रोग्रामिंग c ++ कोड में भी काम कर रहा है। वर्तमान अभ्यास से प्रतीत होता है कि परियोजना का हिस्सा OO का उपयोग कर रहा है और इसका कुछ भाग कार्यात्मक प्रोग्रामिंग का उपयोग करता है। दोनों भाग एक ही भाषा का उपयोग करते हैं (आमतौर पर c / c ++)
tp1

हाँ, आप O को C में भी कर सकते हैं। लेकिन यह अनुशंसित नहीं है। C और C ++ में कार्यात्मक प्रोग्रामिंग के लिए कई निर्माण नहीं हैं, जैसे डिफ़ॉल्ट रूप से अपरिवर्तनीय नहीं, पैटर्न मिलान के लिए कोई अच्छा समर्थन नहीं, अपरिवर्तनीय डेटास्ट्रक्चर और इतने पर शामिल नहीं ...
जोनास

ठीक है, इसलिए इसे अनुभवी प्रोग्रामर की आवश्यकता है। चूंकि प्रोग्रामिंग भाषा को मुख्यधारा के लोगों से बदलना बहुत असंभव है, अगली सबसे अच्छी बात यह है कि सी ++ में कार्यात्मक प्रोग्रामिंग करना है। इसके अलावा c ++ में const जैसी चीजें हैं जो काफी मदद करती हैं।
13

-10

क्योंकि एफपी को डिबग करना कठिन है।


11
मैं असहमत हूं। संपार्श्विक प्रभावों के बिना डिबग प्रक्रिया आसान है। शायद आपको लगता है कि यह कठिन है क्योंकि कार्यात्मक प्रतिमान अलग है और डिबग सहित चीजों को करने के नए तरीके के साथ सहज होने के लिए अनुभव की आवश्यकता है।
मणियो

2
फ़ंक्शनल प्रोग्रामिंग लैंग्वेज वास्तव में टेस्ट करना आसान है, क्योंकि शुद्ध फ़ंक्शंस स्टेटलेस हैं।
जोनास

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

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

2
जब तक आपके कार्य शुद्ध हैं, डिबगिंग आसान है। अगर आप यूनिट-टेस्ट जोड़कर डिबग नहीं कर सकते हैं तो आपका टेस्ट लिखने का पर्याप्त काम नहीं हो रहा है।
dan_waterworth
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.