क्या कार्यात्मक प्रोग्रामिंग के लिए एक सॉफ्टवेयर-इंजीनियरिंग पद्धति है? [बन्द है]

Question

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

नया प्रचार कार्यात्मक प्रोग्रामिंग है, जिसे कई पुस्तकों और ट्यूटोरियल में पढ़ाया जाता है। लेकिन कार्यात्मक सॉफ्टवेयर इंजीनियरिंग के बारे में क्या? लिस्प और क्लोजर के बारे में पढ़ते हुए, मैं दो दिलचस्प बयानों के बारे में आया:

1. कार्यात्मक कार्यक्रमों को अक्सर ऊपर नीचे ('लिस्प', पॉल ग्राहम) के बजाय नीचे विकसित किया जाता है

2. कार्यात्मक प्रोग्रामर उन मानचित्रों का उपयोग करते हैं जहां ओओ-प्रोग्रामर ऑब्जेक्ट्स / कक्षाएं ('जावा प्रोग्रामर्स के लिए क्लोजर', रिच हिकले द्वारा बात करते हैं) का उपयोग करते हैं।

तो एक कार्यात्मक अनुप्रयोग का एक व्यवस्थित (मॉडल आधारित) डिजाइन के लिए कार्यप्रणाली क्या है, यानी लिस्प या क्लोजर में? सामान्य कदम क्या हैं, मैं किन कलाकृतियों का उपयोग करता हूं, मैं उन्हें समस्या स्थान से समाधान स्थान तक कैसे मैप करूं?

Comments

मेरी यहाँ एक टिप्पणी है: कई कार्यक्रम टॉप-डाउन फैशन में लिखे गए हैं, एक कार्यात्मक भाषा में सॉफ्टवेयर के विकास की प्रक्रिया का एक व्यावहारिक वर्णन "फंक्शनल प्रोग्रामिंग इन कंसंट्रेट क्लीन" पुस्तक में दिया गया है (भाषा खुद बहुत अकादमिक है, हालांकि)।

— अर्योम शालखकोव

1. पारनस का तर्क है कि अधिकांश कार्यक्रमों को नीचे-ऊपर होना चाहिए और फिर ऊपर-नीचे देखने के लिए नकली होना चाहिए, इसलिए उन दृष्टिकोणों को मिश्रित किया जाना चाहिए, कोई सही उत्तर नहीं है।

— गेब्रियल Gabričerbák

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

— गेब्रियल Gabričerbák

मैंने कुछ समय पहले एक संबंधित प्रश्न पूछा था: "एक मॉडल डेटा क्लोजर में रिलेशनल डेटाबेस से कैसे करता है ?" stackoverflow.com/questions/3067261/…

— संदीप

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

— lfborjas

Answer 1

भगवान का शुक्र है कि सॉफ्टवेयर-इंजीनियरिंग के लोगों ने अभी तक कार्यात्मक प्रोग्रामिंग की खोज नहीं की है। यहाँ कुछ समानताएं हैं:

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

  ये उच्च-क्रम फ़ंक्शन अक्सर प्रोग्रामिंग के कुछ कानूनों के साथ आते हैं, उर्फ ​​"फ्री थ्योरम"।

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

  जो कार्यात्मक प्रोग्रामर प्रकार का उपयोग करते हैं वे आमतौर पर सोचते हैं कि "एक बार जब आप सही प्रकार प्राप्त करते हैं, तो कोड व्यावहारिक रूप से खुद लिखता है।"

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

तो एक कार्यात्मक अनुप्रयोग का एक व्यवस्थित (मॉडल आधारित) डिजाइन के लिए कार्यप्रणाली क्या है, यानी लिस्प या क्लोजर में?

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

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

सामान्य कदम क्या हैं, मैं किन कलाकृतियों का उपयोग करता हूं?

सामान्य चरण:

1. अपने प्रोग्राम में डेटा और उस पर कार्य को पहचानें, और इस डेटा का प्रतिनिधित्व करने वाले एक अमूर्त डेटा प्रकार को परिभाषित करें।

2. सामान्य क्रियाओं या संगणना के पैटर्न को पहचानें, और उन्हें उच्च-क्रम के कार्यों या मैक्रोज़ के रूप में व्यक्त करें। इस कदम को रिफैक्टिंग के हिस्से के रूप में लेने की उम्मीद है।

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

Comments

IMO विजिटर फोल्ड नहीं है - फोल्ड विजिटर का सबसेट है। एकाधिक प्रेषण तह द्वारा कब्जा कर लिया (सीधे) नहीं है।

— माइकल एकस्ट्रैंड

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

— स्कैलव

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

— एलेक्स मिलर

+1 के लिए "भगवान का शुक्र है कि सॉफ्टवेयर-इंजीनियरिंग लोगों ने अभी तक कार्यात्मक प्रोग्रामिंग की खोज नहीं की है।" ;)

— अका

OO स्वयं प्रकारों के साथ प्रोग्राम करने का एक तरीका है, इसलिए दृष्टिकोण इतने अलग नहीं हैं। OO डिजाइन के साथ समस्या आमतौर पर लोगों को यह जानने में नहीं आती है कि वे क्या कर रहे हैं।

— मार्सिन

Answer 2

क्लोजर के लिए, मैं अच्छे पुराने संबंधपरक मॉडलिंग में वापस जाने की सलाह देता हूं। टारपीट में से एक प्रेरणादायक पाठ है।

Comments

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

— थोरस्टन

यह। यह। यह! मैं इस पत्र को पढ़ रहा हूं, और यह वास्तव में दिलचस्प है कि यह कैसे नियंत्रित करने के लिए वास्तविक तंत्रों के निर्माण में लगने वाले सभी ठिकानों को कवर करता है, जबकि एक उच्च नियंत्रित फैशन में न्यूनतम उत्परिवर्ती राज्य बनाए रखता है। मैं एफआरएलपी शैली में पोंग और टेट्रिस का निर्माण कर रहा हूं (विचित्र प्रारंभिकवाद का बहाना है, लेकिन पहले से ही एक और लोकप्रिय एफआरपी है: कार्यात्मक प्रतिक्रियाशील प्रोग्रामिंग)।

— जॉन क्रॉमार्टी

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

— Thorsten

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

— 27'11

wayback.archive.org/web/jsp/…

— knb

Answer 3

व्यक्तिगत रूप से मुझे पता चलता है कि ओओ विकास से सभी सामान्य अच्छी कार्यप्रणाली कार्यात्मक प्रोग्रामिंग में भी लागू होती हैं - बस कुछ मामूली tweaks के साथ कार्यात्मक विश्वदृष्टि का ध्यान रखना। एक पद्धति के दृष्टिकोण से, आपको वास्तव में मौलिक रूप से कुछ भी करने की आवश्यकता नहीं है।

मेरा अनुभव हाल के वर्षों में जावा से क्लोजर में स्थानांतरित होने से आया है।

कुछ उदाहरण:

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

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

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

• प्रोटॉटिंग / पुनरावृत्ति - एफपी के साथ ही काम करता है। यदि आप उपकरण / डीएसएल बनाने और आरईपीएल पर उनका उपयोग करने में बहुत अच्छे हैं, तो आप उपयोगकर्ताओं के साथ लाइव प्रोटोटाइप बनाने में सक्षम हो सकते हैं।

Comments

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

— थोरस्टेन

लेकिन अगर आप पैटर्न को सर्वोत्तम प्रथाओं के रूप में अनुवादित करते हैं, तो एफपी दुनिया में भी पैटर्न हो सकते हैं, जो कि अनइंस्टॉल के साथ साझा किए जाने के लायक है।

— थोरस्टेन

PAIP बुक में कुछ इंट्रस्टिंग थ्योरी डिज़ाइन हैं। norvig.com/paip.html

— mathk 12

कार्यात्मक प्रोग्रामिंग पैटर्न (पुनरावृत्ति आदि की योजनाएं) भी हैं

— गेब्रियल bčerbák

Answer 4

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

तो वहाँ किताबें और उस पर किताबें नहीं हैं, लेकिन एक अच्छी तरह से स्थापित दृष्टिकोण है, जैसा कि कहा जाता है, असंभव मूल्यों को अप्राप्य बनाते हैं।

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

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

अब आपके पास एक डोमेन है जिस पर आपके कार्य हैं जो अच्छी तरह से व्यवहार किए गए कानूनों के अनुसार रचना करते हैं। एक साधारण एम्बेडेड DSL!

ओह, और दिए गए गुण, आप निश्चित रूप से उनमें से स्वचालित यादृच्छिक परीक्षण (अल क्विकचेक) लिख सकते हैं .. और यह सिर्फ शुरुआत है।

Comments

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

— जक

@Zak - ठीक है, आप सांख्यिकीय रूप से जाँच नहीं कर सकते कि वे अप्राप्य हैं, लेकिन आप वैसे भी अपने डेटा संरचनाओं का निर्माण कर सकते हैं।

— स्कैलव

Answer 5

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

इसके अलावा, कार्यात्मक कार्यक्रम प्रतिरूपकता और अन्य संरचना का प्रदर्शन करते हैं। आपके विस्तृत डिज़ाइन को उस संरचना में अवधारणाओं के संदर्भ में व्यक्त किया जाना है।

Answer 6

एक दृष्टिकोण यह है कि पसंद की कार्यात्मक प्रोग्रामिंग भाषा के भीतर एक आंतरिक डीएसएल बनाया जाए। "मॉडल" तब DSL में व्यक्त व्यावसायिक नियमों का एक समूह है।

Comments

मैं पहली बार समस्या डोमेन की ओर भाषा का निर्माण करने के दृष्टिकोण को समझता हूं जब तक कि अमूर्तता का स्तर नहीं पहुंच जाता है, कोड में कोई भी दोहराव पैटर्न नहीं होता है, उस सार के साथ समस्या को हल करने की तुलना में।

— थोरस्टेन

लेकिन यह कैसे दिखता है जब "मॉडल DSL में व्यक्त व्यावसायिक नियमों का एक सेट है"? जावा ईई एप्लिकेशन में मॉडल को POJO-Entities के रूप में लिखा गया है, जिसे कंट्रोलर-ईजेबी से कॉल किया जाता है, जो बदले में अपडेट-जेएसपी - उदाहरण के लिए। क्या एफपी में समान आर्किटेक्चरल पैटर्न (जैसे एमवीसी-पैटर्न) हैं? वह कैसा दिखता है?

— थोरस्टेन

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

— sclv 14

Answer 7

किसी अन्य पोस्ट पर मेरा उत्तर देखें:

सरोकारों की क्लोजर ऑप्रैच सेपरेशन कैसे होती है?

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

Comments

मुझे 90% पाइपलाइन और 10% मैक्रो दृष्टिकोण पसंद है। अपरिवर्तनीय डेटा पर परिवर्तनों के पाइप लाइन के रूप में एक कार्यात्मक कार्यक्रम के बारे में सोचना काफी स्वाभाविक लगता है। मुझे यकीन नहीं है कि अगर मुझे समझ में आता है कि "डेटा में सभी बुद्धिमत्ता डालें, कोड नहीं" तो इसका मतलब क्या है, क्योंकि 1 डेटा संरचना पर 100 कार्य करने के लिए दृष्टिकोण (10 डेटास्ट्रक्चर पर 10 कार्यों के बजाय) का अर्थ लगता है विलोम। ओपी में डेटा संरचनाएं एफपी की तुलना में अधिक बुद्धिमान नहीं हैं, क्योंकि उनके पास अपना स्वयं का व्यवहार है?

— थोरस्टेन

Answer 8

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

यहाँ, कुछ लिंक:

http://www.northeastern.edu/magazine/0301/programming.html

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.86.8371

Comments

पूर्वोत्तर पृष्ठ का लिंक मृत प्रतीत होता है।

— जेम्स किंग्सबेरी

जेम्स, आप सही हैं, और मुझे याद नहीं है कि दुर्भाग्य से इसे ठीक करने के लिए क्या था। मुझे केवल इतना पता है कि HtDP लेखक पायरेट भाषा बनाने के लिए गए (और शायद, Racket के बजाय इसका उपयोग करने के लिए HtDP के दूसरे संस्करण को संशोधित कर रहे हैं, पूर्व में PLT योजना)।

— अर्योम शालखकोव

Answer 9

मुझे हाल ही में यह पुस्तक मिली है: कार्यात्मक और प्रतिक्रियाशील डोमेन मॉडलिंग

मुझे लगता है कि आपके सवाल के अनुरूप है।

पुस्तक विवरण से:

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

Answer 10

ऑक्सफोर्ड यूनिवर्सिटी (यूके) में प्रो। रिचर्ड बर्ड और प्रोग्रामिंग ग्रुप के बीजगणित से जुड़ी "प्रोग्राम गणना" / "डिजाइन द्वारा गणना" शैली है, मुझे नहीं लगता कि इस पद्धति पर विचार करना बहुत दूर की कौड़ी है।

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

Answer 11

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

Comments

क्लोजर में बीडीडी करने के लिए आप कौन से टूल का उपयोग कर रहे हैं?

— मर्तज़ा 52

मुझे मिडजे पसंद है। यह अप टू डेट और बहुत एक्सप्रेसिव है। इसे देखें: github.com/marick/Midje

— Marc

Answer 12

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

एक अच्छा उदाहरण fmap है। यह फ़ंक्शन एक फ़ंक्शन को एक तर्क के रूप में लेता है और इसे दूसरे तर्क के सभी "तत्वों" पर लागू करता है। चूँकि यह फन्नेटर टाइप क्लास का हिस्सा है, फ़ंक्टर के किसी भी उदाहरण (जैसे सूची, ग्राफ़, आदि ...) को इस फ़ंक्शन के दूसरे तर्क के रूप में पारित किया जा सकता है। यह अपने दूसरे तर्क के प्रत्येक तत्व के लिए एक फ़ंक्शन को लागू करने के सामान्य व्यवहार को कैप्चर करता है।

Answer 13

कुंआ,

आमतौर पर कई कार्यात्मक प्रोग्रामिंग भाषाओं का उपयोग विश्वविद्यालयों में "छोटी खिलौना समस्याओं" के लिए लंबे समय तक किया जाता है।

वे अब और अधिक लोकप्रिय हो रहे हैं क्योंकि OOP को "राज्य" के कारण "पैरालल प्रोग्रामिंग" के साथ कठिनाइयाँ हैं। और कभी-कभी Google MapReduce जैसी समस्या के लिए कार्यात्मक शैली बेहतर है।

मुझे यकीन है कि, जब functionalioanl लोग दीवार से टकराते हैं [कोड की 1.000.000 पंक्तियों से बड़ी प्रणालियों को लागू करने की कोशिश करते हैं], उनमें से कुछ buzz शब्दों के साथ नए सॉफ्टवेयर-इंजीनियरिंग के तरीके के साथ आएंगे :-)। उन्हें पुराने प्रश्न का उत्तर देना चाहिए: सिस्टम को टुकड़ों में कैसे विभाजित किया जाए ताकि हम एक बार में प्रत्येक टुकड़े को "काट" सकें? [कार्य पुनरावृत्त, वृद्धिशील एन विकासवादी तरीका] कार्यात्मक शैली का उपयोग कर।

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

लेकिन क्या इतनी बड़ी प्रणालियों के लिए कार्यात्मक कार्यक्रमों का उपयोग किया जाएगा? क्या वे मुख्य धारा बन जाएंगे? यही सवाल है ।

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

Comments

अब कार्यात्मक भाषाओं के साथ पर्याप्त बड़े पैमाने पर सिस्टम का निर्माण किया गया है। यहां तक ​​कि अगर वहाँ नहीं था, तो यह एक तर्क नहीं है।

— स्वेन्ते

अच्छा, उनमें से कुछ का नाम बताइए? मैं अभी बहुत कम "Erlang" सिस्टम जानता हूं। [मध्यम आकार] लेकिन हास्केल? Clojure? लिस्प?

— हिप्पियस माइनर

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

— हिप्पियास माइनर

भाषाओं के बारे में मज़ेदार बात "ओओपी" नहीं है, यह है कि वे अक्सर आपको "डिजाइन मेथोडोगिलिलोगीज़" से आज़ादी देते हैं, खुद के लिए सोचने के लिए, और एक सेट पैटर्न का पालन करने के बजाय आँख बंद करके और सबसे उपयुक्त तरीके से अपने कार्यक्रम को काटने के लिए, साथ रहते हैं नौकरशाही बॉयलर क्षमा करें, यहां कोई 10-बिंदु 3-सप्ताह का पाठ्यक्रम नहीं है।

— स्वेन्ते

मैंने ऐसी चीजें देखी हैं जिन पर आपको विश्वास नहीं होगा।

— स्वेन्ते