👎 🏟️ 👵 प्रोग्रामिंग पर विचार 🛀🏽 🤵🏼 👩🏽‍⚖️

अरस्तू से विट्गेन्स्टाइन तक

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

प्रस्तावना

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

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

परिचय

"अगर एक वैज्ञानिक यह नहीं जानता कि आठ साल के बच्चे को कैसे समझा जाए कि वह क्या कर रहा है, तो वह एक चरित्रहीन है"
कर्ट वोनगुट, द क्रैड फॉर द कैट, 1963

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

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

प्र। कुछ प्रोग्रामर ड्रेगन में विश्वास करते हैं, लेकिन कई मानते हैं कि जटिलता एक व्यक्तिपरक अवधारणा है। "मुश्किल" शब्द की परिभाषाओं में से एक मुश्किल, भ्रामक है। उदाहरण के लिए, एक कठिन कार्य, एक जटिल (या, अधिक सटीक, एक भ्रामक?) कार्यक्रम। एक व्यक्ति के लिए मुश्किल और भ्रमित करना दूसरे के लिए आसान और स्पष्ट हो सकता है। ज्यामितीय टॉलेमी मॉडल में चक्र और महाकाव्य के साथ ग्रहों की गति, जैसा कि उनके द्वारा संशोधित है, जटिल दिखता है। केपलर दीर्घवृत्त के अनुसार हेलियोसेंट्रिक मॉडल में आंदोलन सरल है। यदि आप छवियों को थोड़ा प्रारूप में संपादित करते हैं, तो यह मुश्किल होगा, लेकिन अगर एक ग्राफिक्स संपादक में, तो बस। मैंडेलब्रोट सेट की छवि को बिना देखे हुए पर्यवेक्षक की जटिलता से मंत्रमुग्ध किया जा सकता है, लेकिन एक पर्याप्त भाषा में मैंडेलब्रॉट सेट को बहुत सरल रूप से वर्णित किया गया है: "जटिल विमान पर बिंदुओं का सेट जिसके लिए संख्यात्मक अनुक्रम z ₀ = 0, z _n = z _n-1 ² + c ( _n = _{n) है।} 1, 2, 3, ...) अनंत तक नहीं जाता है। "

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

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

शोध करे

"हर कार्य तुच्छ हो जाता है यदि एक पर्याप्त भाषा में तैयार किया गया है " I.M. Gelfand

कार्यक्रमों के बारे में

कार्यक्रम = कार्य + मॉडल + एल्गोरिथ्म + डेटा संरचना

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

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

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

इसलिए, एक प्रोग्राम एक भाषा में लिखा गया एक समाधान है जो कुछ कैलकुलेटर के लिए समझ में आता है जो हमारे सामने है।

ऑब्जेक्ट ओरिएंटेड दृष्टिकोण के बारे में

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

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

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

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

हां, अब हम पहले से ही " कैरी " नहीं, बल्कि " कैरी फायरवुड " या " कैरी स्टोन " कहना सीख चुके हैं। अपने विकास में, प्रोग्रामिंग भाषाओं ने इस तथ्य पर ध्यान केंद्रित किया कि उन्होंने वस्तुओं ( जलाऊ लकड़ी और पत्थर ) के बीच अंतर करना सीखा, लेकिन उन पर कार्यों को भेद करना नहीं सीखा। और प्रोग्रामिंग भाषा के संदर्भ में, men.carry (जलाऊ लकड़ी) और men.carry (पत्थर) अलग-अलग भाषा इकाइयां होंगी, जब तक कि जलाऊ लकड़ी और पत्थर की वस्तुओं का एक सामान्य पूर्वज नहीं होता है! यह सिर्फ इतना है कि इन वस्तुओं द्वारा " एक व्यक्ति क्या पहन सकता है " इंटरफ़ेस के कार्यान्वयन से हमें मदद नहीं मिलेगी, क्योंकि यह दो कार्यान्वयन होगा, और इसलिए, स्रोत कोड की दो इकाइयाँ होंगी।

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

वंशानुक्रम के बारे में

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

पोस्ट के बारे में

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

गुणों के बारे में

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

एकत्रीकरण के बारे में

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

एसोसिएशन के बारे में

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

पहचान के बारे में

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

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

लुडविग विट्गेन्स्टाइन की ऑन्कोलॉजी के बारे में

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

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

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

डोमेन विशिष्ट भाषा (DSL) के बारे में

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

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

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

डीएनए जैसे डीएसएल का वर्णन करना चाहिए:

तैयार घटकों से एक मॉडल को इकट्ठा करने के लिए परिदृश्य;
प्रारंभिक अवस्था की शुरुआत;
समय में मॉडल के विकास के नियम।

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

निष्कर्ष

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

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

प्रोग्रामिंग पर विचार