क्या फंक्शनल प्रोग्रामिंग का उपयोग पूर्ण उद्यम अनुप्रयोग विकसित करने के लिए किया जा सकता है?

19

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

अगर कोई चीज परस्पर भिन्न नहीं है, तो एफपी में कर्मचारी या व्यक्ति जैसी सामान्य चीजों का प्रतिनिधित्व कैसे किया जाता है।

क्या एफपी का इस्तेमाल पूर्ण विकसित उद्यम बनाने के लिए किया जा सकता है?

functional-programming

— user2434
स्रोत

5

किसी कर्मचारी का प्रतिनिधित्व क्यों करना पड़ेगा? यह शायद राज्य है, लेकिन यह पूरी तरह से एक और सवाल है।

1

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

— dan_waterworth

2

कार्यात्मक प्रोग्रामिंग के दुष्प्रभाव हैं, अन्यथा आप कभी भी कुछ भी प्रिंट नहीं कर पाएंगे।

1

@ Thorbjørn Ravn Andersen: अपरिमेय (प्रक्रियात्मक, वस्तु-उन्मुख) प्रोग्रामिंग में आप बाहरी दुनिया (IO) के साथ संचार करने और अपने प्रोग्राम के भीतर डेटा परिवर्तनों की गणना के लिए दोनों साइड इफेक्ट्स का उपयोग करते हैं। एफपी में आप स्पष्ट रूप से दो दुनियाओं को अलग करते हैं: आप केवल आईओ के लिए साइड इफेक्ट्स का उपयोग करते हैं (आईओ के बिना एक कार्यक्रम सामान्य रूप से बेकार है), लेकिन आप आंतरिक डेटा परिवर्तनों की गणना करने के लिए शुद्ध कार्यों का उपयोग करते हैं। साइड-इफेक्ट्स को पूरी तरह से टाला नहीं जा सकता है, लेकिन चूंकि वे गैर स्थानीय हैं, इसलिए उनके लिए तर्क करना अधिक कठिन है, इसलिए जितना संभव हो उतना उनके उपयोग को प्रतिबंधित करना अच्छा है।

— जियोर्जियो

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

— ब्रेंडन

17

सवाल यह नहीं है कि क्या एंटरप्राइज में एफपी का इस्तेमाल किया जा सकता है? लेकिन क्या हमें Enteprise में FP का उपयोग करना चाहिए?

निःसंदेह तुमसे हो सकता है। आप किसी भी प्रकार की प्रोग्रामिंग भाषा के साथ किसी भी प्रकार का एप्लिकेशन विकसित कर सकते हैं, इसीलिए उन्हें "ट्यूरिंग कम्प्लीट" कहा जाता है।

अब, सवाल "एंटरप्राइज में इसका इस्तेमाल करना चाहिए?" यह आपके या आपके नियोक्ताओं के लिए है, एफपी वास्तव में कुछ प्रकार के अनुप्रयोगों में उपयोगी हो सकता है, और वास्तव में, यह काफी उपयोग किया जाता है: उद्योग में हास्केल

अब, आप पूछ रहे होंगे "तो इसका अधिक उपयोग क्यों नहीं किया जाता है?" मुख्य रूप से क्योंकि अन्य इम्पीरियल / ओओ भाषाएँ अधिक आम हैं, और कंपनियां अधिक "विदेशी" भाषा में बदलने से इनकार करती हैं क्योंकि वे जावा या सी ++ के लिए उपयोग की जाती हैं।

— dysoco
स्रोत

7

You can develop any kind of application with any kind of programming languageएक बहुत कमजोर तर्क है कि, सावधान रहना ट्यूरिंग tarpits ...

— Yannis

5

@YannisRizos मुझे लगता है कि वह समस्या के हर स्पर्श की खोज के विपरीत एक-से-एक बिंदु के जवाब के लिए सामान्यीकरण कर रहा था।

— जॉनी रॉटन

2

@YannisRizos चाह सकते !=हैं

1

कभी-कभी मुझे ऐसा लगता है कि कुछ खास तरह के एंटरप्राइज सॉल्यूशंस के लिए भी भाषा ट्यूरिंग पूरी नहीं होनी चाहिए ...

— shabunc

2

मैं तर्क दूंगा कि यह आपके नियोक्ताओं के लिए नहीं है, जब यह भाषाओं की बात आती है, तो यह इंजीनियरों पर निर्भर है कि हम अपने तकनीकी दृष्टिकोण से जो सबसे अच्छा देखते हैं उसे आगे बढ़ाएं।

— shmish111

11

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

IMO, FP भाषाओं की कुछ ताकतें हैं:

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

अब तक, मैंने एफपी प्रतिमान पर स्विच को काफी रोमांचक पाया है और एक बार जब आप इस पर पर्याप्त समय बिताते हैं तो बहुत मुश्किल नहीं है। (लेकिन मैंने C या C ++ सीखने में कितना समय लगाया? बहुत कुछ! "

इसलिए मुझे लगता है कि एक तकनीकी दृष्टिकोण से यह एक कार्यात्मक प्रोग्रामिंग भाषा का उपयोग करके पूर्ण उद्यम अनुप्रयोग विकसित करने के लिए पूरी तरह से समझ में आता है।

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

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

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

— जियोर्जियो
स्रोत

10

मुझे नहीं लगता कि यह सबसे अच्छा विचार है। लेकिन यह विशिष्ट एप्लिकेशन की प्रकृति पर निर्भर करता है।

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

जब आप एक अच्छा डोमेन मॉडल बनाने में सफल हो जाते हैं, तो आप पाएंगे कि प्रेजेंटेशन कोड डोमेन लेयर के ऊपर एक पतला शेल होता है।

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

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

लेकिन सामान्य तौर पर, मुझे लगता है कि वस्तु उन्मुख प्रतिमान उद्यम अनुप्रयोगों के बहुमत के लिए अधिक उपयोगी डोमेन मॉडल बनाने की अनुमति देता है।

संपादित करें

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

— पीट
स्रोत

2

+1: बहुत अच्छा और उत्तेजक जवाब। एफपी पर मेरे सीमित ज्ञान के कारण मुझे यकीन नहीं है कि यह सही है, लेकिन मुझे लगता है कि निरंतर वस्तुओं को मोनाड या अद्वितीय प्रकार (स्वच्छ में) का उपयोग करके मॉडलिंग की जा सकती है: इस तरह से एक मान एक पहचान प्राप्त कर सकता है, अपने कार्यक्रम के आसपास पारित किया जा सकता है और विभिन्न कार्यों द्वारा बदल दिया। लेकिन मुझे इसे वापस करने के लिए वास्तव में FP विशेषज्ञ की राय की आवश्यकता होगी।

— जियोर्जियो

3

हाँ यह कर सकते हैं। Google थोड़ा सा है और आपको शुद्ध कार्यात्मक भाषाओं में कोडेड असली सॉफ्टवेयर मिलेगा।

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

ध्यान दें कि इस तकनीक को अनिवार्य भाषाओं का उपयोग करके भी लागू किया जा सकता है!

— एंड्रेस एफ।
स्रोत

3

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

— dietbuddha
स्रोत

3

हां, एफपी का उपयोग उद्यम अनुप्रयोगों में किया जा सकता है। क्लोजर उद्यम में सफलता के साथ एफपी भाषा का एक उदाहरण है: http://cognitect.com/clojure#successstories

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

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

[[name: "James Brown" address: "Barnwell, SC"]
 [name: "Elvis Presley" address: "Tupelo, MS"]]

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

तो FRP के लिए फ़ंक्शन द्वारा दी गई वस्तु नया राज्य है और इसे सीधे दृश्य में या उच्च स्तर पर जो भी हो, दिया जा सकता है। कुछ मामलों में FRP पूरे राज्य को फ़ंक्शन में ले जाता है और पूरे राज्य को वापस मिल जाता है।

इस प्रतिमान के साथ, कंटेनर या फ्रेमवर्क को डिस्प्ले, डेटाबेस, या जो भी नए राज्य से अपडेट करने की आवश्यकता है, के अपडेट को संभालने की आवश्यकता है। तो आप एक रूपरेखा की कल्पना कर सकते हैं जो स्क्रीन पर एप्लिकेशन को खींचता है। जब कोई उपयोगकर्ता क्लिक करता है तो कुछ फ़ंक्शन को लागू किया जाता है और नया राज्य वापस कर दिया जाता है। इसके बाद फ्रेमवर्क स्क्रीन को अपडेट करता है या तो सब कुछ रिड्यूस करता है या फिर डिस्प्ले के कुछ हिस्सों को रीडिवेलिंग करता है। Http://blog.getprismatic.com/om-sweet-om-high-functional-frontend-engineering-with-clojurescript-and-react/ देखें

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

यह क्यों फायदेमंद है जो आप पूछ सकते हैं? क्योंकि इन क्लोजर कंस्ट्रक्शंस द्वारा संदर्भित अपरिवर्तनीय ऑब्जेक्ट को एक फ़ंक्शन को पास किया जा सकता है जो कुछ करता है और जबकि वह फ़ंक्शन ऑब्जेक्ट के संदर्भ में चल रहा है, उसे बदलने की गारंटी नहीं है। यही है, परमाणु / एजेंट / रेफरी समारोह में पारित नहीं किया जाता है, लेकिन उनके द्वारा इंगित अपरिवर्तनीय वस्तु को पारित किया जाता है। परमाणुओं, एजेंटों, और refs में विशेष गुण होते हैं जो अद्यतन और संगामिति को उन तरीकों से संभालते हैं जो सुरक्षित हैं और भाषा का हिस्सा हैं। Http://clojure.org/state देखें

आशा है कि ये आपकी मदद करेगा। मेरा सुझाव है कि एफपी में कर्मचारियों और व्यक्तियों का प्रतिनिधित्व कैसे किया जा सकता है, इस बारे में बेहतर समझ पाने के लिए क्लोजर राज्य और एफआरपी के बारे में अधिक पढ़ें। हालाँकि, वास्तविक प्रतिनिधित्व ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग के समान होगा ... यह एक भिन्नता है जो वास्तव में अलग है।

— जेसन
स्रोत