रिच हिक्की की अनऑफिशियल ब्रेन गाइड

फ्लाइंग मशीन स्टूडियो ब्लॉग
6 दिसंबर 2012
लेख का अनुवाद अनधिकृत गाइड टू रिच हिक्की ब्रेन



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

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

निम्नलिखित सभी पाठ रिच हिकी की चर्चा पर आधारित हैं "क्या हम अभी तक वहाँ हैं?"

प्रविष्टि

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

• मूल्य (मूल्य)
• स्थिति (राज्य)
• पहचान (पहचान)
• समय (समय)
• व्यवहार (व्यवहार)

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

तत्वमीमांसा, प्रोग्रामिंग और आप: तुलना ओओपी और एफपी

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

जैसा कि विकिपीडिया हमें सिखाता है, तत्वमीमांसा मोटे तौर पर दो मुख्य सवालों के जवाब देने की कोशिश करता है:

• वहाँ क्या है?
• यह कैसा दिखता है?

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

ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग

OOP तत्वमीमांसा के अनुसार, एक नदी वास्तव में वास्तविक दुनिया में मौजूद है। मुझे पता है, मुझे पता है, मैंने आपको यह भी पूछते हुए सुना: "हाँ, और क्या?", लेकिन, मेरा विश्वास करो, इस कथन की सटीकता ने कई दार्शनिकों को सोने नहीं दिया।

चाल यह है कि नदी लगातार बदल रही है, और इसका पानी कभी भी बहना बंद नहीं करता है। पीएलओ के संदर्भ में, हम कहेंगे कि एक नदी में एक परिवर्तनशील राज्य है, और यह (राज्य) लगातार उतार-चढ़ाव कर रहा है।

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

यह दुनिया की हमारी सहज धारणा के अनुरूप है। मेरी कॉफी के कप में इलेक्ट्रॉन्स चलते हैं, लेकिन यह अभी भी कॉफी की तरह स्वाद लेता है, जैसा कि मुझे उम्मीद थी।

आखिरकार, ओओपी में, वस्तुएं सोचती हैं। वे एक-दूसरे पर कार्रवाई करते हैं। और फिर, यह दुनिया के बारे में हमारे विचारों से मेल खाती है जहां परिवर्तन दूसरों पर कुछ वस्तुओं के कार्यों का परिणाम हैं। मैन ऑब्जेक्ट डोर ऑब्जेक्ट को धकेलता है और हाउस ऑब्जेक्ट पर ले जाता है।

कार्यात्मक प्रोग्रामिंग

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

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

क्या वास्तव में मौजूद है कण और प्रक्रियाएं। एक नदी एक स्थिर वस्तु नहीं है, बल्कि यह एक निश्चित प्रक्रिया द्वारा निर्मित बाध्य कणों का एक क्रम है।

ये कण एक दूसरे पर कार्य नहीं करते हैं, और इन्हें बदला नहीं जा सकता है। वे कुछ नहीं कर सकते। परिवर्तन दूसरे पर एक वस्तु की कार्रवाई का परिणाम नहीं है, परिवर्तन एक अपरिवर्तनीय कण पर लागू प्रक्रिया का परिणाम है। यह कहने के लिए कि कुछ बदल गया है, यह कहने जैसा है: "ओह, यह कणों की इस धारा में एक नया कण है।" यह वही है जो कह रहा है कि HEIT Git रिपॉजिटरी में एक नई प्रतिबद्धता की ओर इशारा करता है।

ठीक है, तत्वमीमांसा के साथ पर्याप्त! अब हम मान के साथ शुरू होने वाले अधिक उपयोगी विषयों का वर्णन करेंगे।

मूल्य (मूल्य)

यह स्पष्ट है कि संख्या 3, 6 और 42 मान हैं। संख्या स्थिर, अपरिवर्तनीय हैं।

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

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

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

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

पहचान (पहचान)

एक भाषण में, श्री हिक्की कहते हैं:

“सबसे बड़ी समस्या यह है कि हम दो चीजों को भ्रमित करते हैं। "हमने इस विचार को व्यक्त किया कि समय में परिवर्तन करने वाली कोई वस्तु हमारी वस्तु है।"

एफपी में, हम एक साधारण नाम के साथ काम करते हैं, जिसे हमने बाध्य कणों का एक क्रम दिया था। "नदी" नदी के "प्रवाह" की प्रक्रिया द्वारा निर्मित अनुक्रम R1, R2, R3, आदि से मेल खाती है। गिट में HEAD के लिए एक सीधा सादृश्य है - यह सिर्फ एक नाम है जो वास्तविक मूल्यों की ओर इशारा करता है। OOP में ऐसा कोई अंतर नहीं है।

या, जैसा कि वे खुद कहते हैं:

“पत्राचार एक काल्पनिक वस्तु का संबंध है जो समय के साथ संबंधित मूल्यों (राज्यों) की एक श्रृंखला के साथ है। ये ऐसे लेबल हैं जिनका उपयोग हम समय अवधि के नाम के लिए करते हैं। ”

स्थिति (राज्य)

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

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

समय (समय)

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

इसके विपरीत, एफपी की दुनिया में हम पढ़ रहे हैं, समय की अवधारणा अच्छी तरह से परिभाषित है। समय राज्यों के नामकरण (पहचानने) की प्रक्रिया का एक उपोत्पाद है।

व्यवहार (व्यवहार)

अंत में, व्यवहार। मुझे यहाँ लिखने के लिए बहुत कुछ नहीं है - मैं शायद अभी भी भाषण देख रहा हूँ, लेकिन मैं अभी भी श्री हिक्की के एक उद्धरण आपको सोचने के लिए आमंत्रित कर रहा हूँ:

“कोई व्यवहार नहीं है। जब बिजली ने तुम्हें मारा, तो "व्यवहार" कौन है?

हो सकता है कि इसने स्टीव येज को " नाउन्स किंगडम में निष्पादन" लिखने के लिए प्रेरित किया।

अंत

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

अनुवादक के नोट्स

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