क्या एक कार्यात्मक भाषा सीखना एक बेहतर OOP प्रोग्रामर है? [बन्द है]

Question

एक जावा / सी # / सी + + प्रोग्रामर के रूप में मैं कार्यात्मक भाषाओं के बारे में बहुत सारी बातें सुनता हूं, लेकिन कभी भी सीखने की जरूरत नहीं पड़ी। मैंने यह भी सुना है कि कार्यात्मक भाषाओं में पेश की गई उच्च स्तर की सोच आपको एक बेहतर OOP / प्रक्रियात्मक भाषा प्रोग्रामर बनाती है।

क्या कोई इसकी पुष्टि कर सकता है? किन तरीकों से यह आपके प्रोग्रामिंग कौशल में सुधार करता है?

कम परिष्कृत भाषा में कौशल में सुधार के लक्ष्य के साथ सीखने के लिए भाषा का एक अच्छा विकल्प क्या है?

Comments

यदि आप C # में कोडिंग कर रहे हैं, तो आप पहले से ही जानते हैं। LINQ काफी फंक्शनल चीज है।

— तर्क

मुझे लगता है कि OOP वास्तविक जीवन की वस्तुओं के मॉडलिंग के लिए बेहतर है।

— ट्यूलेंस कोर्डोवा

@ user61852 अधिकांश ओओ डिजाइन पैटर्न "वास्तविक जीवन" वस्तुओं के बारे में कुछ भी नहीं बताते हैं, लेकिन वास्तव में अत्यधिक अमूर्त अवधारणाएं हैं।

— एंड्रेस एफ।

एक Java / C # (+ C ++) प्रोग्रामर से अधिक हो। वहाँ एक बहुत कम पैम्फलेट के साथ एक विशाल स्विस सेना चाकू के बीच अंतर है कि आप 40 में से ब्लेड एक्स का चयन क्यों करते हैं और एक ब्लेड जिसे आप किसी भी चीज़ के पास ले जा सकते हैं, कृपया इसके साथ क्योंकि यह बहुत तेज़ और घुमावदार दोनों है सही है कि आप इसे लागू कर सकते हैं यह बहुत सोच के बिना परिस्थितियों की एक विस्तृत विविधता के लिए बिजली काटने है। (पाठ्यक्रम के संभाल में एक बोतल खोलने वाले के साथ)

— एरिक रेपेने

Answer 1

मैं मूल रूप से FrustratedWithFormsDesign के उत्तर से सहमत हूं , लेकिन आपने यह भी पूछा कि नया प्रतिमान सीखने से आपके कौशल को विकसित करने में मदद मिलती है। मैं अपने स्वयं के अनुभव से कुछ उदाहरण दे सकता हूं।

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

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

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

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

मुझे उच्च-क्रम के कार्यों का उपयोग करने की अधिक संभावना है। जॉन ह्यूजेस का पेपर, व्हाई फंक्शनल प्रोग्रामिंग मैटर्स । यह कार्यात्मक प्रोग्रामिंग तकनीकों को नियोजित करने से प्राप्त होने वाली योग्यता पर जोर देता है, उच्च-क्रम वाले कार्यों में प्रमुख भूमिका निभाता है।

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

Comments

@ ऐडन: ct 0x में wrt lambdas, किसी भी दर पर नए C ++ कंपाइलर ने उन्हें पहले ही शामिल कर लिया है।

— Matthieu M.

"ऑब्जेक्ट" के रूप में "वह वस्तु जो परस्पर परिवर्तनशील अवस्था रखती है" बहुत आम है, लेकिन वैल्यू ऑब्जेक्ट पैटर्न कई वर्षों से आसपास है।

— फ्रैंक शीयर

@ मैथ्यू, धन्यवाद, मैंने उस प्रतिबिंबित करने के लिए पाठ को अपडेट किया है।

— कल्ली

@ फ्रेंक: पॉइंटर के लिए धन्यवाद। मैंने इसे उत्तर में शामिल नहीं किया, लेकिन मुख्य आपत्ति है कि मुझे वस्तुओं में मूल्य बनाने के लिए अंतर बी / डब्ल्यू ऑब्जेक्ट इंटरफेस (जो वस्तुओं के स्वामित्व में है) और संचालन (जिसमें वस्तुओं के बीच संबंध अधिक हैं, के साथ क्या करना है) स्वयं वस्तुओं की तुलना में प्राथमिक)। 1 + 2गणितीय रूप से समतुल्य है 2 + 1, लेकिन 1.+(2)की तुलना में अलग तरह से लागू किया जाता है 2.+(1)। इसमें मौजूद SW समस्याओं की एक संख्या है जो ऑब्जेक्ट इंटरफेस का उपयोग करने की तुलना में संचालन का उपयोग करके अधिक स्वाभाविक रूप से समझा जा सकता है।

— कलि

@ एडन क्या आपने विलियम कुक की "अंडरस्टैंडिंग डेटा एब्सट्रैक्शन, रिविजिटेड" पढ़ा है? यह वस्तुओं और ADTs के बीच के अंतरों को उजागर करता है, जो कि आप पर इशारा कर रहे हैं।

— फ्रैंक शीयर

Answer 2

मैं यह नहीं कहूंगा कि यह आपको एक बेहतर OOP प्रोग्रामर बनाने की गारंटी है, लेकिन यह आपको सोचने के एक नए तरीके से परिचित कराएगा, और यह आपको सामान्य रूप से समस्या-समाधान में बेहतर बना सकता है, न कि केवल OOP के संदर्भ में।

Comments

यह देखते हुए कि वस्तु वास्तव में उच्च क्रम के कार्य हैं, मैंने पाया कि एफपी सामान सीखने से मेरे ओओपी के साथ सीधे मदद मिली। जैसा कि आप कहते हैं, यह अधिक सामान्यतः लागू / सहायक है।

— फ्रैंक शीयर

Answer 3

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

Comments

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

मैंने कभी प्रोलॉग को एक कार्यात्मक भाषा नहीं कहा है। अगर मैं पर्याप्त रूप से भटकता हूं तो मैं अस्पष्ट रूप से देख सकता हूं कि एफपी के साथ प्रोलॉग (पुर्जे) कैसे मदद कर सकते हैं।

— फ्रैंक शीयर

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

— मेरा सही जनम

@ मेरा सही विकल्प: हाँ, मुझे लगता है कि आप सही हैं। मुझे लगता है कि मुझे कार्यात्मक भाषाओं के बारे में अधिक जानने की आवश्यकता है!

— माइकल के

@moz: हाँ, काश जावा में लैम्बदास होता। अनाम Threadवस्तुएं हैं ... अनाड़ी।

— माइकल के

Answer 4

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

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

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

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

Answer 5

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

Answer 6

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

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

कम परिष्कृत भाषा में कौशल में सुधार के लक्ष्य के साथ सीखने के लिए भाषा का एक अच्छा विकल्प क्या है?

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

किन तरीकों से यह आपके प्रोग्रामिंग कौशल में सुधार करता है?

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