अमूर्त सिद्धांत (कंप्यूटर प्रोग्रामिंग): Difference between revisions

From Vigyanwiki
 
No edit summary
Line 4: Line 4:


== सिद्धांत ==
== सिद्धांत ==
प्रोग्रामर को एक अनुशंसा के रूप में, बेंजामिन सी. पियर्स द्वारा [[ प्रकार और प्रोग्रामिंग भाषाएँ ]]ेज (2002) में इसके निर्माण में, अमूर्त सिद्धांत पढ़ता है (मूल में जोर):<ref>{{cite book|last=Pierce|first=Benjamin|title=प्रकार और प्रोग्रामिंग भाषाएँ|publisher=MIT Press|year=2002|isbn=0-262-16209-1|page=339}}</ref>
प्रोग्रामर को एक अनुशंसा के रूप में, बेंजामिन सी. पियर्स द्वारा [[ प्रकार और प्रोग्रामिंग भाषाएँ |प्रकार और प्रोग्रामिंग भाषाएँ]] ेज (2002) में इसके निर्माण में, अमूर्त सिद्धांत पढ़ता है (मूल में जोर):<ref>{{cite book|last=Pierce|first=Benjamin|title=प्रकार और प्रोग्रामिंग भाषाएँ|publisher=MIT Press|year=2002|isbn=0-262-16209-1|page=339}}</ref>
{{cquote|Each significant piece of functionality in a program should be implemented in just one place in the source code. Where similar functions are carried out by distinct pieces of code, it is generally beneficial to combine them into one by ''abstracting out'' the varying parts.}}
{{cquote|Each significant piece of functionality in a program should be implemented in just one place in the source code. Where similar functions are carried out by distinct pieces of code, it is generally beneficial to combine them into one by ''abstracting out'' the varying parts.}}


Line 16: Line 16:
* ब्रूस जे. मैकलेनन (1983) प्रोग्रामिंग भाषाओं के सिद्धांत: डिज़ाइन, मूल्यांकन और कार्यान्वयन: किसी चीज़ को एक से अधिक बार कहने की आवश्यकता से बचें; आवर्ती पैटर्न का कारक निकालें।<ref>Bruce J. MacLennan, ''Principles of programming languages: design, evaluation, and implementation'', Holt, Rinehart, and Winston, 1983, p. 53</ref>
* ब्रूस जे. मैकलेनन (1983) प्रोग्रामिंग भाषाओं के सिद्धांत: डिज़ाइन, मूल्यांकन और कार्यान्वयन: किसी चीज़ को एक से अधिक बार कहने की आवश्यकता से बचें; आवर्ती पैटर्न का कारक निकालें।<ref>Bruce J. MacLennan, ''Principles of programming languages: design, evaluation, and implementation'', Holt, Rinehart, and Winston, 1983, p. 53</ref>
* जॉन पीयर्स (1998) प्रोग्रामिंग और मेटा-प्रोग्रामिंग इन स्कीम: संरचना और कार्य स्वतंत्र होने चाहिए।<ref>Jon Pearce, ''Programming and meta-programming in scheme'', Birkhäuser, 1998, {{ISBN|0-387-98320-1}}, p. 40</ref>
* जॉन पीयर्स (1998) प्रोग्रामिंग और मेटा-प्रोग्रामिंग इन स्कीम: संरचना और कार्य स्वतंत्र होने चाहिए।<ref>Jon Pearce, ''Programming and meta-programming in scheme'', Birkhäuser, 1998, {{ISBN|0-387-98320-1}}, p. 40</ref>
यह सिद्धांत [[ ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग ]] में [[डिज़ाइन पैटर्न (कंप्यूटर विज्ञान)]] में एक केंद्रीय भूमिका निभाता है, हालांकि उस विषय पर अधिकांश लेखन सिद्धांत को कोई नाम नहीं देते हैं। गैंग ऑफ फोर द्वारा [[डिज़ाइन पैटर्न (पुस्तक)]]पुस्तक) में कहा गया है: यहां फोकस [[एनकैप्सुलेशन (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग)]] अवधारणा है जो भिन्न होती है, कई डिजाइन पैटर्न का विषय है। इस कथन को अन्य लेखकों द्वारा इस प्रकार दोहराया गया है कि जो भिन्न है उसे खोजें और उसे संपुटित करें।<ref>Alan Shalloway, James Trott, ''Design patterns explained: a new perspective on object-oriented design'', Addison-Wesley, 2002, {{ISBN|0-201-71594-5}}, p. 115</ref><!-- these guys can't even phrase something this simple coherently; no wonder they have herd of cargo-cult programmers following them -->
यह सिद्धांत [[ ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग |ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग]] में [[डिज़ाइन पैटर्न (कंप्यूटर विज्ञान)]] में एक केंद्रीय भूमिका निभाता है, हालांकि उस विषय पर अधिकांश लेखन सिद्धांत को कोई नाम नहीं देते हैं। गैंग ऑफ फोर द्वारा [[डिज़ाइन पैटर्न (पुस्तक)]]पुस्तक) में कहा गया है: यहां फोकस [[एनकैप्सुलेशन (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग)]] अवधारणा है जो भिन्न होती है, कई डिजाइन पैटर्न का विषय है। इस कथन को अन्य लेखकों द्वारा इस प्रकार दोहराया गया है कि जो भिन्न है उसे खोजें और उसे संपुटित करें।<ref>Alan Shalloway, James Trott, ''Design patterns explained: a new perspective on object-oriented design'', Addison-Wesley, 2002, {{ISBN|0-201-71594-5}}, p. 115</ref>
 
इस सदी में, एक बार और केवल एक बार के नारे के तहत [[चरम कार्यक्रम]] में सिद्धांत को फिर से खोजा गया है। इस सिद्धांत की परिभाषा अपनी पहली उपस्थिति में काफी संक्षिप्त थी: कोई डुप्लिकेट कोड नहीं।<ref>Kent Beck, ''Extreme programming explained: embrace change'', 2nd edition, Addison-Wesley, 2000, {{ISBN|0-201-61641-6}}, p. 61</ref> इसे बाद में सॉफ़्टवेयर विकास में अन्य मुद्दों पर लागू होने के रूप में विस्तृत किया गया है: स्वचालित करने लायक हर प्रक्रिया को स्वचालित करें। यदि आप स्वयं को कोई कार्य कई बार करते हुए पाते हैं, तो उसे स्क्रिप्ट करें।<ref>Chromatic, ''Extreme programming pocket guide'', O'Reilly, 2003, {{ISBN|0-596-00485-0}}</ref>
इस सदी में, एक बार और केवल एक बार के नारे के तहत [[चरम कार्यक्रम]] में सिद्धांत को फिर से खोजा गया है। इस सिद्धांत की परिभाषा अपनी पहली उपस्थिति में काफी संक्षिप्त थी: कोई डुप्लिकेट कोड नहीं।<ref>Kent Beck, ''Extreme programming explained: embrace change'', 2nd edition, Addison-Wesley, 2000, {{ISBN|0-201-61641-6}}, p. 61</ref> इसे बाद में सॉफ़्टवेयर विकास में अन्य मुद्दों पर लागू होने के रूप में विस्तृत किया गया है: स्वचालित करने लायक हर प्रक्रिया को स्वचालित करें। यदि आप स्वयं को कोई कार्य कई बार करते हुए पाते हैं, तो उसे स्क्रिप्ट करें।<ref>Chromatic, ''Extreme programming pocket guide'', O'Reilly, 2003, {{ISBN|0-596-00485-0}}</ref>




Line 23: Line 25:
अमूर्त सिद्धांत को अक्सर अमूर्तता को सुविधाजनक बनाने के उद्देश्य से कुछ तंत्र के संदर्भ में कहा जाता है। नियंत्रण अमूर्तन का मूल तंत्र एक फ़ंक्शन या [[सबरूटीन]] है। डेटा अमूर्तन में [[बहुरूपता प्रकार]] के विभिन्न रूप शामिल हैं। अधिक विस्तृत तंत्र जो डेटा को संयोजित कर सकते हैं और अमूर्तता को नियंत्रित कर सकते हैं, उनमें शामिल हैं: [[अमूर्त डेटा प्रकार]], जिसमें क्लास (कंप्यूटर विज्ञान), बहुरूपता_(कंप्यूटर_विज्ञान)#बहुरूपता आदि शामिल हैं। जटिल परिदृश्यों में कम दोहराव की अनुमति देने वाले समृद्ध अमूर्तता की तलाश प्रेरक शक्तियों में से एक है। प्रोग्रामिंग भाषा अनुसंधान और डिजाइन।
अमूर्त सिद्धांत को अक्सर अमूर्तता को सुविधाजनक बनाने के उद्देश्य से कुछ तंत्र के संदर्भ में कहा जाता है। नियंत्रण अमूर्तन का मूल तंत्र एक फ़ंक्शन या [[सबरूटीन]] है। डेटा अमूर्तन में [[बहुरूपता प्रकार]] के विभिन्न रूप शामिल हैं। अधिक विस्तृत तंत्र जो डेटा को संयोजित कर सकते हैं और अमूर्तता को नियंत्रित कर सकते हैं, उनमें शामिल हैं: [[अमूर्त डेटा प्रकार]], जिसमें क्लास (कंप्यूटर विज्ञान), बहुरूपता_(कंप्यूटर_विज्ञान)#बहुरूपता आदि शामिल हैं। जटिल परिदृश्यों में कम दोहराव की अनुमति देने वाले समृद्ध अमूर्तता की तलाश प्रेरक शक्तियों में से एक है। प्रोग्रामिंग भाषा अनुसंधान और डिजाइन।


अनुभवहीन प्रोग्रामर अपने प्रोग्राम में बहुत अधिक अमूर्तता लाने के लिए प्रलोभित हो सकते हैं - अमूर्तता जिसका उपयोग एक से अधिक बार नहीं किया जाएगा। {{Citation needed|date=March 2013}} एक पूरक सिद्धांत जो इस मुद्दे पर जोर देता है वह है आपको इसकी आवश्यकता नहीं होगी और, अधिक सामान्यतः, KISS सिद्धांत।
अनुभवहीन प्रोग्रामर अपने प्रोग्राम में बहुत अधिक अमूर्तता लाने के लिए प्रलोभित हो सकते हैं - अमूर्तता जिसका उपयोग एक से अधिक बार नहीं किया जाएगा। एक पूरक सिद्धांत जो इस मुद्दे पर जोर देता है वह है आपको इसकी आवश्यकता नहीं होगी और, अधिक सामान्यतः, KISS सिद्धांत।


चूंकि कोड आमतौर पर संशोधन के अधीन होता है, अमूर्त सिद्धांत का पालन करने से कोड को दोबारा बनाने की आवश्यकता हो सकती है।{{Citation needed|date=August 2022}} कोड के एक टुकड़े को फिर से लिखने के प्रयास को आम तौर पर एक अमूर्त के अनुमानित भविष्य के लाभों के मुकाबले परिशोधित करने की आवश्यकता होती है। इसे नियंत्रित करने वाला एक सामान्य नियम [[मार्टिन फाउलर (सॉफ्टवेयर इंजीनियर)]] द्वारा तैयार किया गया था, और तीन के नियम (प्रोग्रामिंग) के रूप में लोकप्रिय हुआ। इसमें कहा गया है कि यदि कोड का एक टुकड़ा दो बार से अधिक कॉपी किया गया है, यानी इसकी तीन या अधिक प्रतियां हो जाएंगी, तो इसे अलग करना होगा।
चूंकि कोड आमतौर पर संशोधन के अधीन होता है, अमूर्त सिद्धांत का पालन करने से कोड को दोबारा बनाने की आवश्यकता हो सकती है। कोड के एक टुकड़े को फिर से लिखने के प्रयास को आम तौर पर एक अमूर्त के अनुमानित भविष्य के लाभों के मुकाबले परिशोधित करने की आवश्यकता होती है। इसे नियंत्रित करने वाला एक सामान्य नियम [[मार्टिन फाउलर (सॉफ्टवेयर इंजीनियर)]] द्वारा तैयार किया गया था, और तीन के नियम (प्रोग्रामिंग) के रूप में लोकप्रिय हुआ। इसमें कहा गया है कि यदि कोड का एक टुकड़ा दो बार से अधिक कॉपी किया गया है, यानी इसकी तीन या अधिक प्रतियां हो जाएंगी, तो इसे अलग करना होगा।


== सामान्यीकरण ==
== सामान्यीकरण ==
  डोंट रिपीट योरसेल्फ, या DRY सिद्धांत, [[बहुस्तरीय वास्तुकला]] के संदर्भ में विकसित एक सामान्यीकरण है, जहां संबंधित कोड को कुछ हद तक सभी स्तरों पर, आमतौर पर अलग-अलग भाषाओं में दोहराया जाता है। व्यावहारिक रूप से, यहां पुनरावृत्ति से बचने के लिए [[स्वचालित प्रोग्रामिंग]] और [[डेटा परिवर्तन]]ों जैसे स्वचालित टूल पर भरोसा करने की सिफारिश की गई है।{{Citation Needed|date=November 2018}}
  डोंट रिपीट योरसेल्फ, या DRY सिद्धांत, [[बहुस्तरीय वास्तुकला]] के संदर्भ में विकसित एक सामान्यीकरण है, जहां संबंधित कोड को कुछ हद तक सभी स्तरों पर, आमतौर पर अलग-अलग भाषाओं में दोहराया जाता है। व्यावहारिक रूप से, यहां पुनरावृत्ति से बचने के लिए [[स्वचालित प्रोग्रामिंग]] और [[डेटा परिवर्तन]]ों जैसे स्वचालित टूल पर भरोसा करने की सिफारिश की गई है।


== हार्डवेयर प्रोग्रामिंग इंटरफेस ==
== हार्डवेयर प्रोग्रामिंग इंटरफेस ==

Revision as of 08:37, 4 July 2023

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

जब प्रोग्रामर की सिफ़ारिशों के रूप में पढ़ा जाता है, तो अमूर्त सिद्धांत को स्वयं को न दोहराने (DRY) सिद्धांत के रूप में सामान्यीकृत किया जा सकता है, जो सामान्य रूप से जानकारी के दोहराव से बचने की सिफारिश करता है, और सॉफ्टवेयर विकास प्रक्रिया में शामिल मानव प्रयास के दोहराव से भी बचाता है। .

सिद्धांत

प्रोग्रामर को एक अनुशंसा के रूप में, बेंजामिन सी. पियर्स द्वारा प्रकार और प्रोग्रामिंग भाषाएँ ेज (2002) में इसके निर्माण में, अमूर्त सिद्धांत पढ़ता है (मूल में जोर):[1]

Each significant piece of functionality in a program should be implemented in just one place in the source code. Where similar functions are carried out by distinct pieces of code, it is generally beneficial to combine them into one by abstracting out the varying parts.

प्रोग्रामिंग भाषा की आवश्यकता के रूप में, डेविड ए. श्मिट द्वारा टाइप की गई प्रोग्रामिंग भाषाओं की संरचना (1994) में इसके निर्माण में, अमूर्त सिद्धांत पढ़ता है:।[2]

The phrases of any semantically meaningful syntactic class may be named.

इतिहास और विविधताएँ

अमूर्तन सिद्धांत का उल्लेख कई पुस्तकों में किया गया है। इनमें से कुछ, सूत्रीकरण के साथ, यदि यह संक्षिप्त है, नीचे सूचीबद्ध हैं।

  • अल्फ्रेड जॉन कोल, रोनाल्ड मॉरिसन (1982) एस-अल्गोल के साथ प्रोग्रामिंग का एक परिचय: [अमूर्त] जब भाषा डिजाइन पर लागू किया जाता है तो भाषा में सभी अर्थपूर्ण रूप से सार्थक वाक्यविन्यास श्रेणियों को परिभाषित करना और उन पर एक अमूर्तता की अनुमति देना है।[3]
  • ब्रूस जे. मैकलेनन (1983) प्रोग्रामिंग भाषाओं के सिद्धांत: डिज़ाइन, मूल्यांकन और कार्यान्वयन: किसी चीज़ को एक से अधिक बार कहने की आवश्यकता से बचें; आवर्ती पैटर्न का कारक निकालें।[4]
  • जॉन पीयर्स (1998) प्रोग्रामिंग और मेटा-प्रोग्रामिंग इन स्कीम: संरचना और कार्य स्वतंत्र होने चाहिए।[5]

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

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


निहितार्थ

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

अनुभवहीन प्रोग्रामर अपने प्रोग्राम में बहुत अधिक अमूर्तता लाने के लिए प्रलोभित हो सकते हैं - अमूर्तता जिसका उपयोग एक से अधिक बार नहीं किया जाएगा। एक पूरक सिद्धांत जो इस मुद्दे पर जोर देता है वह है आपको इसकी आवश्यकता नहीं होगी और, अधिक सामान्यतः, KISS सिद्धांत।

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

सामान्यीकरण

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

हार्डवेयर प्रोग्रामिंग इंटरफेस

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


संदर्भ

  1. ↑ Pierce, Benjamin (2002). प्रकार और प्रोग्रामिंग भाषाएँ. MIT Press. p. 339. ISBN 0-262-16209-1.
  2. ↑ David A. Schmidt, The structure of typed programming languages, MIT Press, 1994, ISBN 0-262-19349-3, p. 32
  3. ↑ Alfred John Cole, Ronald Morrison, An introduction to programming with S-algol, CUP Archive, 1982, ISBN 0-521-25001-3, p. 150
  4. ↑ Bruce J. MacLennan, Principles of programming languages: design, evaluation, and implementation, Holt, Rinehart, and Winston, 1983, p. 53
  5. ↑ Jon Pearce, Programming and meta-programming in scheme, Birkhäuser, 1998, ISBN 0-387-98320-1, p. 40
  6. ↑ Alan Shalloway, James Trott, Design patterns explained: a new perspective on object-oriented design, Addison-Wesley, 2002, ISBN 0-201-71594-5, p. 115
  7. ↑ Kent Beck, Extreme programming explained: embrace change, 2nd edition, Addison-Wesley, 2000, ISBN 0-201-61641-6, p. 61
  8. ↑ Chromatic, Extreme programming pocket guide, O'Reilly, 2003, ISBN 0-596-00485-0
  9. ↑ Koziol, The Shellcoders Handbook", Wiley, 2004, p. 10, ISBN 0-7645-4468-3
Retrieved from ‘https://www.vigyanwiki.in/index.php?title=अमूर्त_सिद्धांत_(कंप्यूटर_प्रोग्रामिंग)&oldid=208603’