प्रोग्रामिंग पैराडाइम की तुलना: Difference between revisions

From Vigyanwiki
No edit summary
No edit summary
Line 1: Line 1:
{{Short description|Comparison of programming language features}}{{Programming paradigms}}
{{Short description|Comparison of programming language features}}{{Programming paradigms}}
यह आलेख विकीपीडिया के मौजूदा लेखों में इन समानताओं और अंतरों से संबंधित अलग-अलग चर्चाओं के लिंक के साथ ग्राफिकल और सारणीबद्ध प्रारूप दोनों में सारांश के रूप में विभिन्न [[प्रोग्रामिंग प्रतिमान]]ों के बीच विभिन्न समानताओं और अंतरों को निर्धारित करने का प्रयास करता है।
यह आलेख विकीपीडिया के वर्तमान लेखों में इन समानताओं और अंतरों से संबंधित अलग-अलग चर्चाओं के लिंक के साथ ग्राफिकल और सारणीबद्ध प्रारूप दोनों में सारांश के रूप में विभिन्न [[प्रोग्रामिंग प्रतिमान]] के बीच विभिन्न समानताओं और अंतरों को निर्धारित करने का प्रयास करता है।


== मुख्य प्रतिमान दृष्टिकोण ==
== मुख्य प्रतिमान दृष्टिकोण ==
प्रोग्रामिंग के दो मुख्य दृष्टिकोण हैं:<ref>{{cite web |title=Programming paradigms: What are the principles of programming? |url=https://www.ionos.com/digitalguide/websites/web-development/programming-paradigms/ |website=IONOS |publisher=IONOS |access-date=30 May 2022}}</ref>
प्रोग्रामिंग के दो मुख्य दृष्टिकोण हैं |<ref>{{cite web |title=Programming paradigms: What are the principles of programming? |url=https://www.ionos.com/digitalguide/websites/web-development/programming-paradigms/ |website=IONOS |publisher=IONOS |access-date=30 May 2022}}</ref>
* [[अनिवार्य प्रोग्रामिंग]] - क्रियान्वित करने के तरीके पर ध्यान केंद्रित करता है, नियंत्रण प्रवाह को कथन (प्रोग्रामिंग) के रूप में परिभाषित करता है जो प्रोग्राम की स्थिति (कंप्यूटर विज्ञान) को बदल देता है।
* [[अनिवार्य प्रोग्रामिंग]]  क्रियान्वित करने के विधि पर ध्यान केंद्रित करता है | नियंत्रण प्रवाह को कथन (प्रोग्रामिंग) के रूप में परिभाषित करता है | जो प्रोग्राम की स्थिति (कंप्यूटर विज्ञान) को बदल देता है।
* [[घोषणात्मक प्रोग्रामिंग]] - क्या निष्पादित करना है इस पर ध्यान केंद्रित करता है, प्रोग्राम लॉजिक को परिभाषित करता है, लेकिन विस्तृत नियंत्रण प्रवाह नहीं।
* [[घोषणात्मक प्रोग्रामिंग]] क्या निष्पादित करना है इस पर ध्यान केंद्रित करता है | प्रोग्राम लॉजिक को परिभाषित करता है, किन्तु विस्तृत नियंत्रण प्रवाह नहीं होती है।


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


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


ओओपी विधियों को लागू करने वाले सबरूटीन्स को अंततः  अनिवार्य, कार्यात्मक, या प्रक्रियात्मक शैली में कोडित किया जा सकता है, जो इनवोकिंग प्रोग्राम की ओर से [[राज्य (कंप्यूटर विज्ञान)]] को सीधे बदल सकता है या नहीं। प्रतिमानों के बीच अनिवार्य रूप से कुछ ओवरलैप है, लेकिन मुख्य विशेषताएं या पहचाने जाने योग्य अंतर इस तालिका में संक्षेप हैं:
ओओपी विधियों को प्रयुक्त करने वाले सबरूटीन्स को अंततः  अनिवार्य, कार्यात्मक, या प्रक्रियात्मक शैली में कोडित किया जा सकता है | जो इनवोकिंग प्रोग्राम की ओर से [[राज्य (कंप्यूटर विज्ञान)|स्तर (कंप्यूटर विज्ञान)]] को सीधे बदल सकता है या नहीं। प्रतिमानों के बीच अनिवार्य रूप से कुछ ओवरलैप है | किन्तु मुख्य विशेषताएं या पहचाने जाने योग्य अंतर इस तालिका में संक्षेप हैं |


{| class="wikitable sortable"
{| class="wikitable sortable"
Line 56: Line 56:
| [[C++|सी++]],<ref>{{Cite web |url=https://meetingcpp.com/tl_files/mcpp/slides/12/FunctionalProgrammingInC++11.pdf |title=Archived copy |access-date=2015-12-18 |archive-url=https://web.archive.org/web/20170202210855/http://meetingcpp.com/tl_files/mcpp/slides/12/FunctionalProgrammingInC++11.pdf |archive-date=2017-02-02 |url-status=dead }}</ref> [[C sharp (programming language)|सी#]],<ref>{{cite web |url=https://en.wikipedia.org/wiki/C_Sharp_(programming_language)#Functional_programming |title=Functional programming C# |last= |first= |date=August 2020 |access-date=2015-08-14 |publisher=}}</ref>{{Circular reference|date=October 2020}} [[Clojure|क्लोजर]], [[CoffeeScript|कॉफीस्क्रिप्ट]],<ref>{{cite web |url=http://cedricruiz.me/blog/functional-coffeescript-for-the-impatient/ |title=Functional CoffeeScript for the impatient |last=Ruiz |first=Cedric |date=May 2014 |access-date=2015-08-09 |work=Blog de Cedric Ruiz |publisher=Cedric Ruiz}}</ref> एलिक्सिर, [[Erlang (programming language)|एर्लैंग]], [[F Sharp (programming language)|F#]], [[Haskell (programming language)|हास्केल]], [[Java (programming language)|जावा]] (वर्जन के बाद से 8), [[Kotlin (programming language)|कोटलिन]], [[Lisp (programming language)|लिस्प]], [[Python (programming language)|पायथन]], [[R (programming language)|R]],<ref>{{Cite web|url=http://adv-r.had.co.nz/Functional-programming.html|title = Functional programming · Advanced R}}</ref> [[Ruby (programming language)|रूबी]], [[Scala (programming language)|स्काला]], [[SequenceL|सीक्वेंस एल]], [[Standard ML|स्टैंडर्ड एमएल]], [[JavaScript|जावास्क्रिप्ट]], [[Elm (programming language)|एल्म]]
| [[C++|सी++]],<ref>{{Cite web |url=https://meetingcpp.com/tl_files/mcpp/slides/12/FunctionalProgrammingInC++11.pdf |title=Archived copy |access-date=2015-12-18 |archive-url=https://web.archive.org/web/20170202210855/http://meetingcpp.com/tl_files/mcpp/slides/12/FunctionalProgrammingInC++11.pdf |archive-date=2017-02-02 |url-status=dead }}</ref> [[C sharp (programming language)|सी#]],<ref>{{cite web |url=https://en.wikipedia.org/wiki/C_Sharp_(programming_language)#Functional_programming |title=Functional programming C# |last= |first= |date=August 2020 |access-date=2015-08-14 |publisher=}}</ref>{{Circular reference|date=October 2020}} [[Clojure|क्लोजर]], [[CoffeeScript|कॉफीस्क्रिप्ट]],<ref>{{cite web |url=http://cedricruiz.me/blog/functional-coffeescript-for-the-impatient/ |title=Functional CoffeeScript for the impatient |last=Ruiz |first=Cedric |date=May 2014 |access-date=2015-08-09 |work=Blog de Cedric Ruiz |publisher=Cedric Ruiz}}</ref> एलिक्सिर, [[Erlang (programming language)|एर्लैंग]], [[F Sharp (programming language)|F#]], [[Haskell (programming language)|हास्केल]], [[Java (programming language)|जावा]] (वर्जन के बाद से 8), [[Kotlin (programming language)|कोटलिन]], [[Lisp (programming language)|लिस्प]], [[Python (programming language)|पायथन]], [[R (programming language)|R]],<ref>{{Cite web|url=http://adv-r.had.co.nz/Functional-programming.html|title = Functional programming · Advanced R}}</ref> [[Ruby (programming language)|रूबी]], [[Scala (programming language)|स्काला]], [[SequenceL|सीक्वेंस एल]], [[Standard ML|स्टैंडर्ड एमएल]], [[JavaScript|जावास्क्रिप्ट]], [[Elm (programming language)|एल्म]]
|-
|-
! समय-संचालित सहित घटना-संचालित
! समय-संचालित सहित इवेंट-संचालित
| नियंत्रण प्रवाह मुख्य रूप से घटनाओं द्वारा निर्धारित किया जाता है, जैसे कि माउस क्लिक या टाइमर सहित व्यवधान
| नियंत्रण प्रवाह मुख्य रूप से घटनाओं द्वारा निर्धारित किया जाता है, जैसे कि माउस क्लिक या टाइमर सहित व्यवधान
| मेन लूप, इवेंट हैंडलर, एसिंक्रोनस प्रोसेस
| मेन लूप, इवेंट हैंडलर, एसिंक्रोनस प्रोसेस
Line 64: Line 64:
|-
|-
! [[Object-oriented programming|ऑब्जेक्ट-ओरिएंटेड]]
! [[Object-oriented programming|ऑब्जेक्ट-ओरिएंटेड]]
| डेटाफ़ील्ड को केवल पूर्वनिर्धारित विधियों के माध्यम से हेरफेर की गई वस्तुओं के रूप में मानता है
| डेटाफ़ील्ड को केवल पूर्वनिर्धारित विधियों के माध्यम से हेरफेर की गई ऑब्जेक्ट्स के रूप में मानता है
| वस्तुएं, विधियाँ, संदेश पास करना, सूचना छिपाना, डेटा अमूर्तता, एनकैप्सुलेशन, बहुरूपता, वंशानुक्रम, क्रमांकन-मार्शलिंग
| वस्तुएं, विधियाँ, संदेश पास करना, सूचना छिपाना, डेटा अमूर्तता, एनकैप्सुलेशन, बहुरूपता, वंशानुक्रम, क्रमांकन-मार्शलिंग
| प्रक्रियात्मक
| प्रक्रियात्मक
Line 80: Line 80:
| प्रोग्राम को परिमित अवस्था मशीन या किसी अन्य औपचारिक ऑटोमेटा के मॉडल के रूप में मानता है
| प्रोग्राम को परिमित अवस्था मशीन या किसी अन्य औपचारिक ऑटोमेटा के मॉडल के रूप में मानता है
| स्तर गणना, नियंत्रण चर, स्तर परिवर्तन, समरूपता, स्तर संक्रमण तालिका
| स्तर गणना, नियंत्रण चर, स्तर परिवर्तन, समरूपता, स्तर संक्रमण तालिका
| अनिवार्य, घटना-संचालित
| अनिवार्य, इवेंट-संचालित
|  
|  
| [[Abstract State Machine Language|एब्स्ट्रैक्ट स्टेट मशीन लैंग्वेज]]
| [[Abstract State Machine Language|एब्स्ट्रैक्ट स्टेट मशीन लैंग्वेज]]
Line 87: Line 87:


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


== भाषा समर्थन ==
== भाषा समर्थन ==
{{Main|Syntactic sugar}}
{{Main|सिंथेटिक शुगर}}
[[सिंटैक्टिक चीनी]] भाषा की विशेषताओं को पेश करके प्रोग्राम की कार्यक्षमता को मधुर बनाना है जो किसी दिए गए उपयोग की सुविधा प्रदान करती है, भले ही उनके बिना अंतिम परिणाम प्राप्त किया जा सके। सिंटैक्टिक चीनी का  उदाहरण वस्तु-उन्मुख प्रोग्रामिंग भाषाओं में उपयोग की जाने वाली कक्षा (कंप्यूटर प्रोग्रामिंग) हो सकता है। अनिवार्य भाषा [[सी (प्रोग्रामिंग भाषा)]] [[समारोह सूचक]], टाइप कास्टिंग और संरचनाओं की सुविधाओं के माध्यम से [[ ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग ]] का समर्थन कर सकती है। हालाँकि, सी++ जैसी भाषाओं का उद्देश्य इस कोडिंग शैली के लिए सिंटैक्स विशिष्ट को पेश करके ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग को अधिक सुविधाजनक बनाना है। इसके अलावा, विशेष सिंटैक्स वस्तु-उन्मुख दृष्टिकोण पर जोर देने के लिए काम करता है। इसी तरह, सी (और अन्य प्रक्रियात्मक और संरचित प्रोग्रामिंग भाषाओं) में फ़ंक्शंस और लूपिंग सिंटैक्स को सिंटैक्टिक शुगर माना जा सकता है। [[ सभा की भाषा ]] प्रोग्राम स्टेट के आधार पर रजिस्टर वैल्यू और ब्रांचिंग एक्जीक्यूशन को संशोधित करने के लिए अपनी सुविधाओं के माध्यम से प्रक्रियात्मक या संरचित प्रोग्रामिंग का समर्थन कर सकती है। हालाँकि, सी जैसी भाषाओं ने प्रक्रियात्मक और संरचित प्रोग्रामिंग को अधिक सुविधाजनक बनाने के लिए इन कोडिंग शैलियों के लिए विशिष्ट सिंटैक्स पेश किया। सी # (सी शार्प) भाषा की विशेषताएं, जैसे गुण और इंटरफेस, इसी तरह कोई नया कार्य सक्षम नहीं करते हैं, लेकिन अच्छी प्रोग्रामिंग प्रथाओं को अधिक प्रमुख और प्राकृतिक बनाने के लिए डिज़ाइन किए गए हैं।
[[सिंटैक्टिक चीनी|सिंटैक्टिक शुगर]] भाषा की विशेषताओं को प्रस्तुत करके प्रोग्राम की कार्यक्षमता को सरल बनाना है | जो किसी दिए गए उपयोग की सुविधा प्रदान करती है | तथापि उनके बिना अंतिम परिणाम प्राप्त किया जा सके। सिंटैक्टिक शुगर का  उदाहरण ऑब्जेक्ट-उन्मुख प्रोग्रामिंग भाषाओं में उपयोग की जाने वाली कक्षा (कंप्यूटर प्रोग्रामिंग) हो सकता है। अनिवार्य भाषा [[सी (प्रोग्रामिंग भाषा)]] [[समारोह सूचक]], टाइप कास्टिंग और संरचनाओं की सुविधाओं के माध्यम से [[ ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग ]] का समर्थन कर सकती है। चूँकि, सी++ जैसी भाषाओं का उद्देश्य इस कोडिंग शैली के लिए सिंटैक्स विशिष्ट को प्रस्तुत करके ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग को अधिक सुविधाजनक बनाना है। इसके अतिरिक्त, विशेष सिंटैक्स ऑब्जेक्ट-उन्मुख दृष्टिकोण पर जोर देने के लिए काम करता है। इसी तरह, सी (और अन्य प्रक्रियात्मक और संरचित प्रोग्रामिंग भाषाओं) में फ़ंक्शंस और लूपिंग सिंटैक्स को सिंटैक्टिक शुगर माना जा सकता है। [[ सभा की भाषा ]] प्रोग्राम स्टेट के आधार पर रजिस्टर वैल्यू और ब्रांचिंग एक्जीक्यूशन को संशोधित करने के लिए अपनी सुविधाओं के माध्यम से प्रक्रियात्मक या संरचित प्रोग्रामिंग का समर्थन कर सकती है। चूँकि, सी जैसी भाषाओं ने प्रक्रियात्मक और संरचित प्रोग्रामिंग को अधिक सुविधाजनक बनाने के लिए इन कोडिंग शैलियों के लिए विशिष्ट सिंटैक्स प्रस्तुत किया। सी # (सी शार्प) भाषा की विशेषताएं, जैसे गुण और इंटरफेस, इसी तरह कोई नया कार्य सक्षम नहीं करते हैं | किन्तु अच्छी प्रोग्रामिंग प्रथाओं को अधिक प्रमुख और प्राकृतिक बनाने के लिए डिज़ाइन किए गए हैं।


कुछ प्रोग्रामर महसूस करते हैं कि ये सुविधाएँ महत्वहीन या तुच्छ हैं। उदाहरण के लिए, [[एलन पर्लिस]] ने एक बार [[ घुंघराले ब्रैकेट प्रोग्रामिंग भाषा ]] | ब्रैकेट-सीमांकित भाषाओं के संदर्भ में चुटकी ली, कि सिंटैक्टिक चीनी अर्धविराम के कैंसर का कारण बनती है ([[प्रोग्रामिंग पर एपिग्राम]] देखें)।
कुछ प्रोग्रामर अनुभव करते हैं कि ये सुविधाएँ महत्वहीन या सामान्य हैं। उदाहरण के लिए, [[एलन पर्लिस]] ने एक बार [[ घुंघराले ब्रैकेट प्रोग्रामिंग भाषा ]] ब्रैकेट-सीमांकित भाषाओं के संदर्भ में किया था | क्योकि सिंटैक्टिक शुगर अर्धविराम के कैंसर का कारण बनती है ([[प्रोग्रामिंग पर एपिग्राम]] देखें)।


इसका एक विस्तार है सिंटैक्टिक शुगर#सिंटैक्टिक सैकरिन, या मुफ्त सिंटैक्स जो प्रोग्रामिंग को आसान नहीं बनाता है।<ref>{{cite web|url=http://www.retrologic.com/jargon/S/syntactic-sugar.html|title= The Jargon File v4.4.7: "syntactic sugar"}}</ref>
इसका एक विस्तार है सिंटैक्टिक शुगर सिंटैक्टिक सैकरिन, या मुफ्त सिंटैक्स जो प्रोग्रामिंग को सरल नहीं बनाता है।<ref>{{cite web|url=http://www.retrologic.com/jargon/S/syntactic-sugar.html|title= The Jargon File v4.4.7: "syntactic sugar"}}</ref>




== प्रदर्शन तुलना ==
== प्रदर्शन तुलना ==
केवल कुल निर्देश पथ लंबाई में,  अनिवार्य शैली में कोडित  प्रोग्राम, बिना किसी सबरूटीन्स का उपयोग करते हुए, सबसे कम गिनती होगी। हालाँकि, ऐसे प्रोग्राम का [[बाइनरी फ़ाइल]] आकार सबरूटीन्स (कार्यात्मक और प्रक्रियात्मक प्रोग्रामिंग के रूप में) का उपयोग करके कोड किए गए समान प्रोग्राम से बड़ा हो सकता है और संदर्भ के अधिक स्थानीयता को संदर्भित करेगा। गैर-स्थानीय भौतिक निर्देश जो कैशे (कंप्यूटिंग) #ऑपरेशन बढ़ा सकते हैं और निर्देश आधुनिक [[सेंट्रल प्रोसेसिंग यूनिट]] में [[कम्प्यूटेशनल ओवरहेड]] लाते हैं।
केवल कुल निर्देश पथ लंबाई में,  अनिवार्य शैली में कोडित  प्रोग्राम, बिना किसी सबरूटीन्स का उपयोग करते हुए, सबसे कम गिनती होगी। चूँकि, ऐसे प्रोग्राम का [[बाइनरी फ़ाइल]] आकार सबरूटीन्स (कार्यात्मक और प्रक्रियात्मक प्रोग्रामिंग के रूप में) का उपयोग करके कोड किए गए समान प्रोग्राम से बड़ा हो सकता है और संदर्भ के अधिक स्थानीयता को संदर्भित करेगा। गैर-स्थानीय भौतिक निर्देश जो कैशे (कंप्यूटिंग) संचालन बढ़ा सकते हैं और निर्देश आधुनिक [[सेंट्रल प्रोसेसिंग यूनिट|सेंट्रल प्रोसेसिंग]] इकाई में [[कम्प्यूटेशनल ओवरहेड]] लाते हैं।


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


=== [[प्रबंधित कोड]] ===
=== [[प्रबंधित कोड]] ===
प्रबंधित कोड वातावरण में निष्पादित प्रोग्राम के लिए, जैसे .NET फ्रेमवर्क, कई मुद्दे प्रदर्शन को प्रभावित करते हैं जो प्रोग्रामिंग भाषा प्रतिमान और उपयोग की जाने वाली विभिन्न भाषा सुविधाओं से महत्वपूर्ण रूप से प्रभावित होते हैं।<ref>{{cite web |url=http://msdn.microsoft.com/en-us/library/ms973852 |title=Writing Faster Managed Code: Know What Things Cost |last=Gray |first=Jan |date=June 2003 |work=MSDN |publisher=Microsoft}}</ref>
प्रबंधित कोड वातावरण में निष्पादित प्रोग्राम के लिए, जैसे . नेट फ्रेमवर्क, कई तथ्य प्रदर्शन को प्रभावित करते हैं | जो प्रोग्रामिंग भाषा प्रतिमान और उपयोग की जाने वाली विभिन्न भाषा सुविधाओं से महत्वपूर्ण रूप से प्रभावित होते हैं।<ref>{{cite web |url=http://msdn.microsoft.com/en-us/library/ms973852 |title=Writing Faster Managed Code: Know What Things Cost |last=Gray |first=Jan |date=June 2003 |work=MSDN |publisher=Microsoft}}</ref>




=== [[स्यूडोकोड]] उदाहरण विभिन्न प्रतिमानों की तुलना ===
=== [[स्यूडोकोड]] उदाहरण विभिन्न प्रतिमानों की तुलना ===
सर्कल के क्षेत्र (πr²) की गणना करने के लिए उपयोग किए जाने वाले अनिवार्य, प्रक्रियात्मक और ऑब्जेक्ट ओरिएंटेड दृष्टिकोणों की  स्यूडोकोड तुलना, कोई सबरूटीन इनलाइन विस्तार नहीं, कोई [[ मैक्रो (कंप्यूटर विज्ञान) ]] [[ preprocessor ]] नहीं मानते, अंकगणित पंजीकृत करते हैं, और प्रत्येक निर्देश 'स्टेप' को केवल भारित करते हैं। 1 निर्देश - निर्देश पथ की लंबाई के कच्चे माप के रूप में - नीचे प्रस्तुत किया गया है। निर्देश चरण जो अवधारणात्मक रूप से राज्य परिवर्तन कर रहा है, प्रत्येक मामले में बोल्ड टाइपफेस में हाइलाइट किया गया है। सर्कल के क्षेत्र की गणना करने के लिए उपयोग किए जाने वाले अंकगणितीय संचालन तीनों प्रतिमानों में समान हैं, अंतर यह है कि प्रक्रियात्मक और वस्तु-उन्मुख प्रतिमान उन कार्यों को  सबरूटीन कॉल में लपेटते हैं जो गणना को सामान्य और पुन: प्रयोज्य बनाता है। मैक्रो प्रीप्रोसेसर का उपयोग करते हुए विशुद्ध रूप से अनिवार्य प्रोग्राम में समान प्रभाव प्राप्त किया जा सकता है, केवल प्रोग्राम के आकार में वृद्धि (केवल प्रत्येक मैक्रो इनवोकेशन साइट पर) के बिना संबंधित [[यथानुपात]] रनटाइम लागत (एन इनवोकेशन के लिए आनुपातिक - जो एक के भीतर स्थित हो सकती है) आंतरिक पाश उदाहरण के लिए)। इसके विपरीत,  कंपाइलर द्वारा सबरूटीन इनलाइनिंग प्रक्रियात्मक कार्यक्रमों को आकार में पूरी तरह अनिवार्य कोड के समान कुछ कम कर सकती है। हालाँकि, ऑब्जेक्ट-ओरिएंटेड प्रोग्राम के लिए, इनलाइनिंग के साथ भी, ऑब्जेक्ट-ओरिएंटेड तरीकों द्वारा प्रसंस्करण के लिए संदेशों को अभी भी (तर्कों की प्रतियों से) बनाया जाना चाहिए। कॉल का ओवरहेड, आभासी या अन्यथा, नियंत्रण प्रवाह परिवर्तन का प्रभुत्व नहीं है - लेकिन आसपास के [[कॉलिंग कन्वेंशन]] लागतों द्वारा, जैसे फ़ंक्शन प्रस्तावना कोड, स्टैक सेटअप और पैरामीटर (कंप्यूटर प्रोग्रामिंग)#पैरामीटर और तर्क पारित करना<ref>{{cite web|url=http://hbfs.wordpress.com/2008/12/30/the-true-cost-of-calls/ |title=कॉल की सही कीमत|date=2008-12-30|publisher=wordpress.com}}</ref> (यहाँ देखें<ref>{{Cite web|url=http://en.wikibooks.org/wiki/X86_Disassembly/Functions_and_Stack_Frames|title = X86 Disassembly/Functions and Stack Frames - Wikibooks, open books for an open world}}</ref> अधिक यथार्थवादी निर्देश पथ लंबाई, स्टैक और x[[86]] प्लेटफॉर्म पर कॉल से जुड़ी अन्य लागतों के लिए)। यहां भी देखें<ref>{{cite web|url=http://www-cs-faculty.stanford.edu/~eroberts/books/ArtAndScienceOfJava/slides/07-ObjectsAndMemory.ppt|title=Art and Science of Java; Chapter 7: Objects and Memory|last=Roberts|first=Eric S.|publisher=Stanford University|year=2008|access-date=2010-05-17|archive-url=https://web.archive.org/web/20110606103526/http://www-cs-faculty.stanford.edu/~eroberts/books/ArtAndScienceOfJava/slides/07-ObjectsAndMemory.ppt|archive-date=2011-06-06|url-status=dead}}</ref> एरिक एस रॉबर्ट्स द्वारा  स्लाइड प्रस्तुति के लिए ( चर के लिए स्मृति का आवंटन , अध्याय 7)<ref>{{cite book|url=http://www-cs-faculty.stanford.edu/~eroberts/books/ArtAndScienceOfJava/slides/07-ObjectsAndMemory.ppt|title=जावा की कला और विज्ञान|last=Roberts|first=Eric S.|publisher=Addison-Wesley|year=2008|isbn=978-0-321-48612-7|access-date=2010-05-17|archive-url=https://web.archive.org/web/20110606103526/http://www-cs-faculty.stanford.edu/~eroberts/books/ArtAndScienceOfJava/slides/07-ObjectsAndMemory.ppt|archive-date=2011-06-06|url-status=dead}}</ref> - [[ जावा (प्रोग्रामिंग भाषा) ]] ऑब्जेक्ट-ओरिएंटेड लैंग्वेज में तीन परिमेय संख्याओं को जोड़ते समय स्टैक और हीप मेमोरी के उपयोग का चित्रण।
सर्कल के क्षेत्र (πr²) की गणना करने के लिए उपयोग किए जाने वाले अनिवार्य, प्रक्रियात्मक और ऑब्जेक्ट ओरिएंटेड दृष्टिकोणों की  स्यूडोकोड तुलना, कोई सबरूटीन इनलाइन विस्तार नहीं, कोई [[ मैक्रो (कंप्यूटर विज्ञान) ]] [[ preprocessor |प्रीप्रोसेसर]] नहीं मानते, अंकगणित पंजीकृत करते हैं, और प्रत्येक निर्देश 'स्टेप' को केवल भारित करते हैं। 1 निर्देश पथ की लंबाई के कच्चे माप के रूप में नीचे प्रस्तुत किया गया है। निर्देश चरण जो अवधारणात्मक रूप से स्तर परिवर्तन कर रहा है | प्रत्येक स्थिति में बोल्ड टाइपफेस में हाइलाइट किया गया है। सर्कल के क्षेत्र की गणना करने के लिए उपयोग किए जाने वाले अंकगणितीय संचालन तीनों प्रतिमानों में समान हैं | अंतर यह है कि प्रक्रियात्मक और ऑब्जेक्ट-उन्मुख प्रतिमान उन कार्यों को  सबरूटीन कॉल में लपेटते हैं | जो गणना को सामान्य और पुन: प्रयोज्य बनाता है। मैक्रो प्रीप्रोसेसर का उपयोग करते हुए विशुद्ध रूप से अनिवार्य प्रोग्राम में समान प्रभाव प्राप्त किया जा सकता है | केवल प्रोग्राम के आकार में वृद्धि (केवल प्रत्येक मैक्रो इनवोकेशन साइट पर) के बिना संबंधित [[यथानुपात]] रनटाइम निवेश (एन इनवोकेशन के लिए आनुपातिक - जो एक के अंदर स्थित हो सकती है) आंतरिक पाश उदाहरण के लिए)। इसके विपरीत,  कंपाइलर द्वारा सबरूटीन इनलाइनिंग प्रक्रियात्मक कार्यक्रमों को आकार में पूरी तरह अनिवार्य कोड के समान कुछ कम कर सकती है। चूँकि, ऑब्जेक्ट-ओरिएंटेड प्रोग्राम के लिए, इनलाइनिंग के साथ भी, ऑब्जेक्ट-ओरिएंटेड तरीकों द्वारा प्रसंस्करण के लिए संदेशों को अभी भी (तर्कों की प्रतियों से) बनाया जाना चाहिए। कॉल का ओवरहेड, आभासी या अन्यथा, नियंत्रण प्रवाह परिवर्तन का प्रभुत्व नहीं है | किन्तु आसपास के [[कॉलिंग कन्वेंशन]] निवेशो द्वारा, जैसे फ़ंक्शन प्रस्तावना कोड, स्टैक सेटअप और मापदंड (कंप्यूटर प्रोग्रामिंग)#मापदंड और तर्क पारित करना<ref>{{cite web|url=http://hbfs.wordpress.com/2008/12/30/the-true-cost-of-calls/ |title=कॉल की सही कीमत|date=2008-12-30|publisher=wordpress.com}}</ref> (यहाँ देखें<ref>{{Cite web|url=http://en.wikibooks.org/wiki/X86_Disassembly/Functions_and_Stack_Frames|title = X86 Disassembly/Functions and Stack Frames - Wikibooks, open books for an open world}}</ref> अधिक यथार्थवादी निर्देश पथ लंबाई, स्टैक और x[[86]] प्लेटफॉर्म पर कॉल से जुड़ी अन्य निवेशो के लिए)। यहां भी देखें <ref>{{cite web|url=http://www-cs-faculty.stanford.edu/~eroberts/books/ArtAndScienceOfJava/slides/07-ObjectsAndMemory.ppt|title=Art and Science of Java; Chapter 7: Objects and Memory|last=Roberts|first=Eric S.|publisher=Stanford University|year=2008|access-date=2010-05-17|archive-url=https://web.archive.org/web/20110606103526/http://www-cs-faculty.stanford.edu/~eroberts/books/ArtAndScienceOfJava/slides/07-ObjectsAndMemory.ppt|archive-date=2011-06-06|url-status=dead}}</ref> एरिक एस रॉबर्ट्स द्वारा  स्लाइड प्रस्तुति के लिए ( चर के लिए स्मृति का आवंटन , अध्याय 7) <ref>{{cite book|url=http://www-cs-faculty.stanford.edu/~eroberts/books/ArtAndScienceOfJava/slides/07-ObjectsAndMemory.ppt|title=जावा की कला और विज्ञान|last=Roberts|first=Eric S.|publisher=Addison-Wesley|year=2008|isbn=978-0-321-48612-7|access-date=2010-05-17|archive-url=https://web.archive.org/web/20110606103526/http://www-cs-faculty.stanford.edu/~eroberts/books/ArtAndScienceOfJava/slides/07-ObjectsAndMemory.ppt|archive-date=2011-06-06|url-status=dead}}</ref> [[ जावा (प्रोग्रामिंग भाषा) ]] ऑब्जेक्ट-ओरिएंटेड लैंग्वेज में तीन परिमेय संख्याओं को जोड़ते समय स्टैक और हीप मेमोरी के उपयोग का चित्रण होता है  ।


{| class="wikitable"
{| class="wikitable"
Line 191: Line 191:
  stack storage
  stack storage
|}
|}
<references group="See" />प्रक्रियात्मक अमूर्तता और वस्तु-उन्मुख-शैली बहुरूपता के लाभों को ऊपर दिए गए एक छोटे उदाहरण द्वारा खराब रूप से चित्रित किया गया है। यह उदाहरण मुख्य रूप से कुछ आंतरिक प्रदर्शन अंतरों को चित्रित करने के लिए डिज़ाइन किया गया है, अमूर्त या कोड पुन: उपयोग नहीं।
<references group="See" />प्रक्रियात्मक अमूर्तता और ऑब्जेक्ट-उन्मुख-शैली बहुरूपता के लाभों को ऊपर दिए गए एक छोटे उदाहरण द्वारा व्यर्थ रूप से चित्रित किया गया है। यह उदाहरण मुख्य रूप से कुछ आंतरिक प्रदर्शन अंतरों को अमूर्त या कोड पुन: उपयोग नहीं चित्रित करने के लिए डिज़ाइन किया गया है, ।


==== सबरूटीन, मेथड कॉल ओवरहेड ====
==== सबरूटीन, मेथड कॉल ओवरहेड ====
प्रोग्राम में  (कहा जाता है) सबरूटीन की उपस्थिति प्रतिमान की परवाह किए बिना प्रोग्राम की कार्यक्षमता के लिए अतिरिक्त योगदान नहीं देती है, लेकिन प्रोग्राम की संरचना और व्यापकता में बहुत योगदान दे सकती है, जिससे इसे लिखना, संशोधित करना और विस्तार करना बहुत आसान हो जाता है।<ref name="steele1997">Guy Lewis Steele, Jr. "Debunking the 'Expensive Procedure Call' Myth, or, Procedure Call Implementations Considered Harmful, or, Lambda: The Ultimate GOTO". MIT AI Lab. AI Lab Memo AIM-443. October 1977. [http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-443.pdf] {{Webarchive|url=https://web.archive.org/web/20091229133005/http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-443.pdf |date=2009-12-29 }}[http://dspace.mit.edu/handle/1721.1/5753][http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.72.4404&rep=rep1&type=pdf]</ref> जिस हद तक अलग-अलग प्रतिमान सबरूटीन्स (और उनकी परिणामी मेमोरी आवश्यकताओं) का उपयोग करते हैं, वह संपूर्ण एल्गोरिथ्म के समग्र प्रदर्शन को प्रभावित करता है, हालांकि जैसा कि [[गाय स्टील]] ने 1977 के पेपर में बताया,  अच्छी तरह से डिज़ाइन की गई प्रोग्रामिंग भाषा के कार्यान्वयन में प्रक्रियात्मक अमूर्तता के लिए बहुत कम ओवरहेड्स हो सकते हैं। (लेकिन अधिकांश कार्यान्वयनों में अफसोस जताते हैं, कि व्यवहार में वे शायद ही कभी इसे प्राप्त करते हैं - बल्कि इस संबंध में विचारहीन या लापरवाह होते हुए)। उसी पेपर में, स्टील ऑटोमेटा-आधारित प्रोग्रामिंग ([[ पूंछ पुनरावर्तन ]] के साथ प्रक्रिया कॉल का उपयोग करके) के लिए  विचारित मामला भी बनाता है और निष्कर्ष निकालता है कि हमें प्रक्रिया कॉल के लिए  स्वस्थ सम्मान होना चाहिए (क्योंकि वे शक्तिशाली हैं) लेकिन सुझाव दिया कि उन्हें कम से कम उपयोग करें<ref name="steele1997"/>
प्रोग्राम में  (कहा जाता है) सबरूटीन की उपस्थिति प्रतिमान की परवाह किए बिना प्रोग्राम की कार्यक्षमता के लिए अतिरिक्त योगदान नहीं देती है | किन्तु प्रोग्राम की संरचना और व्यापकता में बहुत योगदान दे सकती है | जिससे इसे लिखना, संशोधित करना और विस्तार करना बहुत सरल हो जाता है।<ref name="steele1997">Guy Lewis Steele, Jr. "Debunking the 'Expensive Procedure Call' Myth, or, Procedure Call Implementations Considered Harmful, or, Lambda: The Ultimate GOTO". MIT AI Lab. AI Lab Memo AIM-443. October 1977. [http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-443.pdf] {{Webarchive|url=https://web.archive.org/web/20091229133005/http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-443.pdf |date=2009-12-29 }}[http://dspace.mit.edu/handle/1721.1/5753][http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.72.4404&rep=rep1&type=pdf]</ref> जिस सीमा तक अलग-अलग प्रतिमान सबरूटीन्स (और उनकी परिणामी मेमोरी आवश्यकताओं) का उपयोग करते हैं | वह संपूर्ण एल्गोरिथ्म के समग्र प्रदर्शन को प्रभावित करता है | चूँकि जैसा कि [[गाय स्टील]] ने 1977 के पेपर में बताया,  अच्छी तरह से डिज़ाइन की गई प्रोग्रामिंग भाषा के कार्यान्वयन में प्रक्रियात्मक अमूर्तता के लिए बहुत कम ओवरहेड्स हो सकते हैं। (किन्तु अधिकांश कार्यान्वयनों में अफसोस जताते हैं, कि व्यवहार में वे संभवतः ही कभी इसे प्राप्त करते हैं | किन्तु इस संबंध में विचारहीन या लापरवाह होते हुए)। उसी पेपर में, स्टील ऑटोमेटा-आधारित प्रोग्रामिंग ([[ पूंछ पुनरावर्तन ]] के साथ प्रक्रिया कॉल का उपयोग करके) के लिए  विचारित स्थिति भी बनाता है और निष्कर्ष निकालता है कि हमें प्रक्रिया कॉल के लिए  स्वस्थ सम्मान होना चाहिए (क्योंकि वे शक्तिशाली हैं) किन्तु सुझाव दिया कि उन्हें कम से कम उपयोग करें |<ref name="steele1997"/>
उपनेमका कॉल की आवृत्ति में:
* प्रक्रियात्मक प्रोग्रामिंग के लिए, कोड की ग्रैन्युलैरिटी # डेटा ग्रैन्युलैरिटी काफी हद तक असतत प्रक्रियाओं या [[मॉड्यूलर प्रोग्रामिंग]] की संख्या से निर्धारित होती है।
* कार्यात्मक प्रोग्रामिंग के लिए, [[ पुस्तकालय (कम्प्यूटिंग) ]] सबरूटीन्स के लिए लगातार कॉल आम हैं,{{Citation needed|date=March 2010}} लेकिन अक्सर ऑप्टिमाइज़िंग कंपाइलर द्वारा इनलाइन किया जा सकता है
* ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के लिए, कॉल किए गए मेथड कॉल्स की संख्या भी आंशिक रूप से डेटा संरचनाओं की ग्रैन्युलैरिटी द्वारा निर्धारित की जाती है और इस प्रकार निम्न स्तर की वस्तुओं के लिए कई रीड-ओनली एक्सेस शामिल हो सकते हैं जो इनकैप्सुलेटेड हैं, और इस प्रकार किसी अन्य में एक्सेस करने योग्य नहीं हैं, अधिक प्रत्यक्ष , रास्ता। चूंकि बढ़ी हुई ग्रैन्युलैरिटी अधिक [[कोड पुन: उपयोग]] के लिए  शर्त है, प्रवृत्ति ठीक-ठाक डेटा संरचनाओं की ओर है, और असतत वस्तुओं (और उनकी विधियों) की संख्या में वृद्धि और इसके परिणामस्वरूप, सबरूटीन कॉल। [[देव वस्तु]]ओं के निर्माण को सक्रिय रूप से हतोत्साहित किया जाता है। [[कंस्ट्रक्टर (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग)]] भी गिनती में जोड़ते हैं क्योंकि वे सबरूटीन कॉल भी हैं (जब तक कि वे इनलाइन न हों)। जब तक [[ scalability ]]  समस्या नहीं बन जाती, तब तक अत्यधिक ग्रैन्युलैरिटी के कारण होने वाली प्रदर्शन समस्याएं स्पष्ट नहीं हो सकती हैं।
* अन्य प्रतिमानों के लिए, जहाँ उपरोक्त प्रतिमानों का मिश्रण नियोजित किया जा सकता है, सबरूटीन का उपयोग कम अनुमानित है।


==== संदेश और वस्तु भंडारण के लिए गतिशील स्मृति का आवंटन ====
विशिष्ट रूप से, ऑब्जेक्ट-ओरिएंटेड प्रतिमान में ऑब्जेक्ट निर्माण और संदेश पासिंग दोनों के लिए हीप स्टोरेज से डायनेमिक मेमोरी आवंटन शामिल है। 1994 का बेंचमार्क - [[डिजिटल उपकरण निगम]] द्वारा विभिन्न प्रकार के सॉफ़्टवेयर पर संचालित बड़े सी और सी++ प्रोग्राम में मेमोरी एलोकेशन कॉस्ट,  इंस्ट्रक्शन-लेवल प्रोफाइलिंग टूल का उपयोग करके मापा गया कि डायनेमिक स्टोरेज आवंटन के लिए कितने निर्देश आवश्यक थे। परिणामों से पता चला कि निष्पादित निर्देशों की सबसे कम निरपेक्ष संख्या औसतन लगभग 50 थी, लेकिन अन्य 611 तक पहुंच गए।<ref>{{cite journal |journal=Software: Practice and Experience |title=Memory Allocation Costs in Large C and C++ Programs; Page 532 |first1= David |last1= Detlefs |first2= Al |last2 = Dosser |first3= Benjamin |last3= Zorn |volume=24|issue=6 |pages= 527–542 |date=June 1994 |citeseerx=10.1.1.30.3073|doi=10.1002/spe.4380240602 |s2cid=14214110 }}</ref> मुरली आर. कृष्णन द्वारा हीप: सुख और पीड़ा भी देखें<ref>{{cite web|url=http://msdn.microsoft.com/en-us/library/ms810466%28v=MSDN.10%29.aspx|publisher=microsoft.com|title=Heap: Pleasures and pains|last=Krishnan|first=Murali R.|date=February 1999}}</ref> यह बताता है कि ढेर कार्यान्वयन सभी प्लेटफार्मों के लिए सामान्य रहता है, और इसलिए भारी ओवरहेड होता है। आईबीएम के अरुण अयंगर द्वारा 1996 का आईबीएम पेपर स्केलेबिलिटी ऑफ डायनामिक स्टोरेज एलोकेशन एल्गोरिदम <ref>{{cite document |citeseerx=10.1.1.3.3759 |title=गतिशील भंडारण आवंटन एल्गोरिदम की मापनीयता|year=1996}}</ref> विभिन्न डायनेमिक स्टोरेज एल्गोरिदम और उनके संबंधित निर्देश काउंट को प्रदर्शित करता है। यहां तक ​​कि अनुशंसित एमएफएलएफ I एल्गोरिदम (एचएस स्टोन, आरसी 9674) 200 और 400 के बीच की सीमा में निर्देश गणना दिखाता है। उपरोक्त स्यूडोकोड उदाहरण में इस स्मृति आवंटन पथ की लंबाई या स्मृति उपसर्ग ओवरहेड शामिल नहीं है और बाद में संबंधित कचरा शामिल नहीं है। संग्रह ओवरहेड्स। दृढ़ता से सुझाव देते हुए कि हीप आवंटन  गैर-तुच्छ कार्य है, गेम डेवलपर जॉन डब्ल्यू रैटक्लिफ द्वारा  [[खुला स्रोत सॉफ्टवेयर]] माइक्रोएलोकेटर, जिसमें कोड की लगभग 1,000 पंक्तियाँ होती हैं।<ref>{{cite web |url=http://code.google.com/p/microallocator/ |title=माइक्रोआवंटक.एच|work=Google Code |access-date=2012-01-29}}</ref>


'''उपनेमका कॉल की आवृत्ति में:'''


==== गतिशील रूप से प्रेषित संदेश कॉल वी। प्रत्यक्ष प्रक्रिया कॉल ओवरहेड्स ====
* प्रक्रियात्मक प्रोग्रामिंग के लिए, कोड की ग्रैन्युलैरिटी  डेटा ग्रैन्युलैरिटी अधिक सीमा तक असतत प्रक्रियाओं या [[मॉड्यूलर प्रोग्रामिंग]] की संख्या से निर्धारित होती है।
स्टेटिक क्लास पदानुक्रम विश्लेषण का उपयोग करके ऑब्जेक्ट-ओरिएंटेड प्रोग्राम के उनके सार अनुकूलन में,<ref>{{cite book |chapter=Optimization of Object-Oriented Programs Using Static Class Hierarchy Analysis |first1= Jeffrey |last1= Dean |first2= David |last2= Grove |first3= Craig |last3= Chambers |title= ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग|volume= 952 |pages= 77–101 |publisher=University of Washington |doi=10.1007/3-540-49538-X_5 |isbn= 978-3-540-60160-9 |citeseerx=10.1.1.117.2420|series= Lecture Notes in Computer Science |year= 1995 }}</ref> [[वाशिंगटन विश्वविद्यालय]] में कंप्यूटर विज्ञान और इंजीनियरिंग विभाग के जेफरी डीन, डेविड ग्रोव और क्रेग चेम्बर्स का दावा है कि वंशानुक्रम और गतिशील रूप से बाध्य संदेशों के भारी उपयोग से कोड को अधिक विस्तार योग्य और पुन: प्रयोज्य बनाने की संभावना है, लेकिन यह गैर-ऑब्जेक्ट-ओरिएंटेड तरीके से लिखे गए समतुल्य लेकिन गैर-विस्तार योग्य प्रोग्राम के सापेक्ष महत्वपूर्ण प्रदर्शन ओवरहेड। कुछ डोमेन में, जैसे कि संरचित ग्राफ़िक्स पैकेज, भारी वस्तु-उन्मुख शैली का उपयोग करके प्रदान किए गए अतिरिक्त लचीलेपन की प्रदर्शन लागत स्वीकार्य है। हालाँकि, अन्य डोमेन में, जैसे कि बुनियादी डेटा संरचना लाइब्रेरी, संख्यात्मक कंप्यूटिंग पैकेज, रेंडरिंग लाइब्रेरी और ट्रेस-संचालित सिमुलेशन फ्रेमवर्क, संदेश पास करने की लागत बहुत अधिक हो सकती है, जिससे प्रोग्रामर को "हॉट" में ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग से बचने के लिए मजबूर होना पड़ता है। स्पॉट ”उनके आवेदन के।
* कार्यात्मक प्रोग्रामिंग के लिए, [[ पुस्तकालय (कम्प्यूटिंग) | लाइब्रेरी (कम्प्यूटिंग)]]  सबरूटीन्स के लिए निरंतर कॉल सामान्य हैं | किन्तु अधिकाशतः ऑप्टिमाइज़िंग कंपाइलर द्वारा इनलाइन किया जा सकता है |
* ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के लिए, कॉल किए गए मेथड कॉल्स की संख्या भी आंशिक रूप से डेटा संरचनाओं की ग्रैन्युलैरिटी द्वारा निर्धारित की जाती है और इस प्रकार निम्न स्तर की ऑब्जेक्ट्स के लिए कई रीड-ओनली एक्सेस सम्मिलित हो सकते हैं | जो इनकैप्सुलेटेड हैं, और इस प्रकार किसी अन्य में एक्सेस करने योग्य नहीं हैं | अधिक प्रत्यक्ष , रास्ता चूंकि बढ़ी हुई ग्रैन्युलैरिटी अधिक [[कोड पुन: उपयोग]] के लिए  शर्त है, प्रवृत्ति ठीक-ठाक डेटा संरचनाओं की ओर है, और असतत ऑब्जेक्ट्स (और उनकी विधियों) की संख्या में वृद्धि और इसके परिणामस्वरूप, सबरूटीन कॉल ऑब्जेक्ट्स के निर्माण को सक्रिय रूप से हतोत्साहित किया जाता है। [[कंस्ट्रक्टर (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग)]] भी गिनती में जोड़ते हैं क्योंकि वे सबरूटीन कॉल भी हैं (जब तक कि वे इनलाइन न हों)। जब तक [[ scalability |अनुमापकता]]  समस्या नहीं बन जाती, तब तक अत्यधिक ग्रैन्युलैरिटी के कारण होने वाली प्रदर्शन समस्याएं स्पष्ट नहीं हो सकती हैं।
* अन्य प्रतिमानों के लिए, जहाँ उपरोक्त प्रतिमानों का मिश्रण नियोजित किया जा सकता है | सबरूटीन का उपयोग कम अनुमानित है।


=== वस्तुओं को क्रमबद्ध करना ===
==== संदेश और ऑब्जेक्ट भंडारण के लिए गतिशील स्मृति का आवंटन ====
{{Main|Serialization}}
विशिष्ट रूप से, ऑब्जेक्ट-ओरिएंटेड प्रतिमान में ऑब्जेक्ट निर्माण और संदेश पासिंग दोनों के लिए हीप स्टोरेज से डायनेमिक मेमोरी आवंटन सम्मिलित है। 1994 का बेंचमार्क [[डिजिटल उपकरण निगम]] द्वारा विभिन्न प्रकार के सॉफ़्टवेयर पर संचालित बड़े सी और सी++ प्रोग्राम में मेमोरी एलोकेशन कॉस्ट,  इंस्ट्रक्शन-लेवल प्रोफाइलिंग टूल का उपयोग करके मापा गया कि डायनेमिक स्टोरेज आवंटन के लिए कितने निर्देश आवश्यक थे। परिणामों से पता चला कि निष्पादित निर्देशों की सबसे कम निरपेक्ष संख्या औसतन लगभग 50 थी | किन्तु अन्य 611 तक पहुंच गए ।<ref>{{cite journal |journal=Software: Practice and Experience |title=Memory Allocation Costs in Large C and C++ Programs; Page 532 |first1= David |last1= Detlefs |first2= Al |last2 = Dosser |first3= Benjamin |last3= Zorn |volume=24|issue=6 |pages= 527–542 |date=June 1994 |citeseerx=10.1.1.30.3073|doi=10.1002/spe.4380240602 |s2cid=14214110 }}</ref> मुरली आर. कृष्णन द्वारा हीप: सुख और पीड़ा भी देखें \<ref>{{cite web|url=http://msdn.microsoft.com/en-us/library/ms810466%28v=MSDN.10%29.aspx|publisher=microsoft.com|title=Heap: Pleasures and pains|last=Krishnan|first=Murali R.|date=February 1999}}</ref> यह बताता है कि ढेर कार्यान्वयन सभी प्लेटफार्मों के लिए सामान्य रहता है, और इसलिए भारी ओवरहेड होता है। आईबीएम के अरुण अयंगर द्वारा 1996 का आईबीएम पेपर स्केलेबिलिटी ऑफ डायनामिक स्टोरेज एलोकेशन एल्गोरिदम <ref>{{cite document |citeseerx=10.1.1.3.3759 |title=गतिशील भंडारण आवंटन एल्गोरिदम की मापनीयता|year=1996}}</ref> विभिन्न डायनेमिक स्टोरेज एल्गोरिदम और उनके संबंधित निर्देश काउंट को प्रदर्शित करता है। यहां तक ​​कि अनुशंसित एमएफएलएफ  एल्गोरिदम (एचएस स्टोन, आरसी 9674) 200 और 400 के बीच की सीमा में निर्देश गणना दिखाता है। उपरोक्त स्यूडोकोड उदाहरण में इस स्मृति आवंटन पथ की लंबाई या स्मृति उपसर्ग ओवरहेड सम्मिलित नहीं है और बाद में संबंधित कचरा सम्मिलित नहीं है। संग्रह ओवरहेड्स दृढ़ता से सुझाव देते हुए कि हीप आवंटन  गैर-सामान्य कार्य है | गेम डेवलपर जॉन डब्ल्यू रैटक्लिफ द्वारा  [[खुला स्रोत सॉफ्टवेयर]] माइक्रोएलोकेटर, जिसमें कोड की लगभग 1,000 पंक्तियाँ होती हैं ।<ref>{{cite web |url=http://code.google.com/p/microallocator/ |title=माइक्रोआवंटक.एच|work=Google Code |access-date=2012-01-29}}</ref>
[[क्रमबद्धता]] ऑब्जेक्ट (कंप्यूटर साइंस) को  सिस्टम से दूसरे सिस्टम में पास करते समय बड़े ओवरहेड्स लगाता है, खासकर जब ट्रांसफर मानव-पठनीय प्रारूपों जैसे एक्सटेंसिबल मार्कअप लैंग्वेज ([[एक्सएमएल]]) और जावास्क्रिप्ट ऑब्जेक्ट नोटेशन (जेएसओएन) में होता है। यह गैर-ऑब्जेक्ट उन्मुख डेटा के लिए कॉम्पैक्ट बाइनरी प्रारूपों के विपरीत है। ऑब्जेक्ट के डेटा मान और इसकी विशेषताओं के एन्कोडिंग और डिकोडिंग दोनों क्रमबद्ध प्रक्रिया में शामिल हैं, जिसमें विरासत, एनकैप्सुलेटिंग और डेटा छिपाने जैसे जटिल मुद्दों के बारे में जागरूकता भी शामिल है।
 
 
 
==== गतिशील रूप से प्रेषित संदेश कॉल वी प्रत्यक्ष प्रक्रिया कॉल ओवरहेड्स ====
स्टेटिक क्लास पदानुक्रम विश्लेषण का उपयोग करके ऑब्जेक्ट-ओरिएंटेड प्रोग्राम के उनके सार अनुकूलन में,<ref>{{cite book |chapter=Optimization of Object-Oriented Programs Using Static Class Hierarchy Analysis |first1= Jeffrey |last1= Dean |first2= David |last2= Grove |first3= Craig |last3= Chambers |title= ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग|volume= 952 |pages= 77–101 |publisher=University of Washington |doi=10.1007/3-540-49538-X_5 |isbn= 978-3-540-60160-9 |citeseerx=10.1.1.117.2420|series= Lecture Notes in Computer Science |year= 1995 }}</ref> [[वाशिंगटन विश्वविद्यालय]] में कंप्यूटर विज्ञान और इंजीनियरिंग विभाग के जेफरी डीन, डेविड ग्रोव और क्रेग चेम्बर्स का प्रमाणित है कि वंशानुक्रम और गतिशील रूप से बाध्य संदेशों के भारी उपयोग से कोड को अधिक विस्तार योग्य और पुन: प्रयोज्य बनाने की संभावना है | किन्तु यह  गैर-ऑब्जेक्ट-ओरिएंटेड विधि से लिखे गए समतुल्य किन्तु गैर-विस्तार योग्य प्रोग्राम के सापेक्ष महत्वपूर्ण प्रदर्शन ओवरहेड कुछ डोमेन में, जैसे कि संरचित ग्राफ़िक्स पैकेज, भारी ऑब्जेक्ट-उन्मुख शैली का उपयोग करके प्रदान किए गए अतिरिक्त लचीलेपन की प्रदर्शन निवेश स्वीकार्य है। चूँकि, अन्य डोमेन में, जैसे कि मूलभूत डेटा संरचना लाइब्रेरी, संख्यात्मक कंप्यूटिंग पैकेज, रेंडरिंग लाइब्रेरी और ट्रेस-संचालित सिमुलेशन फ्रेमवर्क, संदेश पास करने की निवेश बहुत अधिक हो सकती है | जिससे प्रोग्रामर को "हॉट" में ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग से बचने के लिए अशक्त होना पड़ता है।
 
=== ऑब्जेक्ट्स को क्रमबद्ध करना ===
{{Main|क्रमबद्धता}}
[[क्रमबद्धता]] ऑब्जेक्ट (कंप्यूटर साइंस) को  सिस्टम से दूसरे सिस्टम में पास करते समय बड़े ओवरहेड्स लगाता है | विशेष रूप से जब ट्रांसफर मानव-पठनीय प्रारूपों जैसे एक्सटेंसिबल मार्कअप लैंग्वेज ([[एक्सएमएल]]) और जावास्क्रिप्ट ऑब्जेक्ट नोटेशन (जेएसओएन) में होता है। यह गैर-ऑब्जेक्ट उन्मुख डेटा के लिए कॉम्पैक्ट बाइनरी प्रारूपों के विपरीत है। ऑब्जेक्ट के डेटा मान और इसकी विशेषताओं के एन्कोडिंग और डिकोडिंग दोनों क्रमबद्ध प्रक्रिया में सम्मिलित हैं | जिसमें विरासत, एनकैप्सुलेटिंग और डेटा छिपाने जैसे जटिल उद्देश्य के बारे में जागरूकता भी सम्मिलित है।


=== समानांतर कंप्यूटिंग ===
=== समानांतर कंप्यूटिंग ===
{{Main|Parallel computing}}
{{Main|समानांतर कंप्यूटिंग}}
मार्च 2011 में कार्नेगी-मेलन विश्वविद्यालय के प्रोफेसर [[रॉबर्ट हार्पर (कंप्यूटर वैज्ञानिक)]] ने लिखा: इस सेमेस्टर डैन लिकाटा और मैं प्रथम वर्ष के संभावित सीएस मेजर्स के लिए कार्यात्मक प्रोग्रामिंग पर  नया पाठ्यक्रम सह-शिक्षण दे रहे हैं। परिचयात्मक पाठ्यक्रम, क्योंकि यह अपनी प्रकृति से मॉड्यूलर और विरोधी समानांतर दोनों है, और इसलिए आधुनिक सीएस पाठ्यक्रम के लिए अनुपयुक्त है। उन छात्रों के लिए जो इस विषय का अध्ययन करना चाहते हैं, द्वितीय स्तर पर वस्तु-उन्मुख डिजाइन पद्धति पर  प्रस्तावित नया पाठ्यक्रम पेश किया जाएगा।<ref>[http://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/ Teaching FP to Freshmen], from Harper's blog about teaching introductory computer science.[http://existentialtype.wordpress.com/2011/03/15/getting-started/]</ref>
मार्च 2011 में कार्नेगी-मेलन विश्वविद्यालय के प्रोफेसर [[रॉबर्ट हार्पर (कंप्यूटर वैज्ञानिक)]] ने लिखा था | इस सेमेस्टर डैन लिकाटा और मैं प्रथम वर्ष के संभावित सीएस मेजर्स के लिए कार्यात्मक प्रोग्रामिंग पर  नया पाठ्यक्रम सह-शिक्षण दे रहे हैं। परिचयात्मक पाठ्यक्रम, क्योंकि यह अपनी प्रकृति से मॉड्यूलर और विरोधी समानांतर दोनों है, और इसलिए आधुनिक सीएस पाठ्यक्रम के लिए अनुपयुक्त है। उन छात्रों के लिए जो इस विषय का अध्ययन करना चाहते हैं | द्वितीय स्तर पर ऑब्जेक्ट-उन्मुख डिजाइन पद्धति पर  प्रस्तावित नया पाठ्यक्रम प्रस्तुत किया जाएगा।<ref>[http://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/ Teaching FP to Freshmen], from Harper's blog about teaching introductory computer science.[http://existentialtype.wordpress.com/2011/03/15/getting-started/]</ref>




Line 220: Line 224:
* [[प्रोग्रामिंग भाषाओं की तुलना]]
* [[प्रोग्रामिंग भाषाओं की तुलना]]
* [[प्रोग्रामिंग भाषाओं की तुलना (मूल निर्देश)]]
* [[प्रोग्रामिंग भाषाओं की तुलना (मूल निर्देश)]]
* ग्रैन्युलैरिटी # कम्प्यूटिंग
* ग्रैन्युलैरिटी कम्प्यूटिंग
* संदेश देना
* संदेश देना
* [[सबरूटीन]]
* [[सबरूटीन]]

Revision as of 12:54, 19 May 2023

Programming paradigms

यह आलेख विकीपीडिया के वर्तमान लेखों में इन समानताओं और अंतरों से संबंधित अलग-अलग चर्चाओं के लिंक के साथ ग्राफिकल और सारणीबद्ध प्रारूप दोनों में सारांश के रूप में विभिन्न प्रोग्रामिंग प्रतिमान के बीच विभिन्न समानताओं और अंतरों को निर्धारित करने का प्रयास करता है।

मुख्य प्रतिमान दृष्टिकोण

प्रोग्रामिंग के दो मुख्य दृष्टिकोण हैं |[1]

  • अनिवार्य प्रोग्रामिंग  क्रियान्वित करने के विधि पर ध्यान केंद्रित करता है | नियंत्रण प्रवाह को कथन (प्रोग्रामिंग) के रूप में परिभाषित करता है | जो प्रोग्राम की स्थिति (कंप्यूटर विज्ञान) को बदल देता है।
  • घोषणात्मक प्रोग्रामिंग क्या निष्पादित करना है इस पर ध्यान केंद्रित करता है | प्रोग्राम लॉजिक को परिभाषित करता है, किन्तु विस्तृत नियंत्रण प्रवाह नहीं होती है।

निम्नलिखित को व्यापक रूप से मुख्य प्रोग्रामिंग प्रतिमान माना जाता है | जैसा कि प्रोग्रामिंग भाषा की लोकप्रियता को मापते समय देखा जाता है |

निम्नलिखित सामान्य प्रकार के प्रोग्रामिंग हैं | जिन्हें विभिन्न प्रतिमानों का उपयोग करके कार्यान्वित किया जा सकता है |

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

उदाहरण विवरण प्रमुख लक्षण संबंधित उदाहरण आलोचना उदाहरण
अनिवार्य कथनों के रूप में प्रोग्राम जो सीधे गणना की गई स्थिति (डेटाफ़ील्ड) को बदलते हैं प्रत्यक्ष कार्य, सामान्य डेटा संरचनाएं, वैश्विक चर एडजर डब्ल्यू. डिज्कस्ट्रा, माइकल ए. जैक्सन सी, सी++, जावा, कोटलिन, पीएचपी, पायथन, रूबी
स्ट्रक्चर्ड अधिक तार्किक प्रोग्राम संरचना के साथ अनिवार्य प्रोग्रामिंग की शैली स्ट्रक्चरोग्राम, इंडेंटेशन, गोटो स्टेटमेंट का कोई या सीमित उपयोग नहीं अनिवार्य सी, सी++, जावा, कोटलिन, Pascal, पीएचपी, पायथन
प्रक्रियात्मक मॉड्यूलर प्रोग्रामिंग या प्रक्रिया कॉल की अवधारणा के आधार पर संरचित प्रोग्रामिंग से व्युत्पन्न स्थानीय चर, अनुक्रम, चयन, पुनरावृत्ति और मॉडर्लाइज़ेशन संरचित, अनिवार्य सी, सी++, लिस्प, पीएचपी, पायथन
कार्यात्मक गणना को स्तर और परिवर्तनशील डेटा से बचने वाले गणितीय कार्यों के मूल्यांकन के रूप में मानता है लैम्ब्डा कैलकुस, संरचना, सूत्र, रिकर्सन, रेफरेंसियल पारदर्शिता, कोई साइड इफेक्ट नहीं वर्णनात्मक सी++,[2] सी#,[3][circular reference] क्लोजर, कॉफीस्क्रिप्ट,[4] एलिक्सिर, एर्लैंग, F#, हास्केल, जावा (वर्जन के बाद से 8), कोटलिन, लिस्प, पायथन, R,[5] रूबी, स्काला, सीक्वेंस एल, स्टैंडर्ड एमएल, जावास्क्रिप्ट, एल्म
समय-संचालित सहित इवेंट-संचालित नियंत्रण प्रवाह मुख्य रूप से घटनाओं द्वारा निर्धारित किया जाता है, जैसे कि माउस क्लिक या टाइमर सहित व्यवधान मेन लूप, इवेंट हैंडलर, एसिंक्रोनस प्रोसेस प्रक्रियात्मक, डेटा प्रवाह जावास्क्रिप्ट, एक्शनस्क्रिप्ट, विजुअल बेसिक, एल्म
ऑब्जेक्ट-ओरिएंटेड डेटाफ़ील्ड को केवल पूर्वनिर्धारित विधियों के माध्यम से हेरफेर की गई ऑब्जेक्ट्स के रूप में मानता है वस्तुएं, विधियाँ, संदेश पास करना, सूचना छिपाना, डेटा अमूर्तता, एनकैप्सुलेशन, बहुरूपता, वंशानुक्रम, क्रमांकन-मार्शलिंग प्रक्रियात्मक इसकी आलोचना चयन और अन्यत्र देखें [6][7][8] सामान्य लिस्प, सी++, सी#, आइफिल, जावा, कोटलिन, पीएचपी, पायथन, रूबी, स्काला, जावास्क्रिप्ट[9][10]
वर्णनात्मक प्रोग्राम लॉजिक को परिभाषित करता है, किन्तु विस्तृत नियंत्रण प्रवाह को नहीं चौथी पीढ़ी की भाषाएं, स्प्रेडशीट, रिपोर्ट प्रोग्राम जेनरेटर एसक्यूएल, रेगुलर एक्सप्रेशंस, प्रोलॉग, ओडब्ल्यूएल, स्पार्कल, डेटा लॉग, एक्सएसएलटी
ऑटोमेटा-आधारित प्रोग्रामिंग प्रोग्राम को परिमित अवस्था मशीन या किसी अन्य औपचारिक ऑटोमेटा के मॉडल के रूप में मानता है स्तर गणना, नियंत्रण चर, स्तर परिवर्तन, समरूपता, स्तर संक्रमण तालिका अनिवार्य, इवेंट-संचालित एब्स्ट्रैक्ट स्टेट मशीन लैंग्वेज


शब्दावली में अंतर

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

भाषा समर्थन

Main article: सिंथेटिक शुगर

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

कुछ प्रोग्रामर अनुभव करते हैं कि ये सुविधाएँ महत्वहीन या सामान्य हैं। उदाहरण के लिए, एलन पर्लिस ने एक बार घुंघराले ब्रैकेट प्रोग्रामिंग भाषा ब्रैकेट-सीमांकित भाषाओं के संदर्भ में किया था | क्योकि सिंटैक्टिक शुगर अर्धविराम के कैंसर का कारण बनती है (प्रोग्रामिंग पर एपिग्राम देखें)।

इसका एक विस्तार है सिंटैक्टिक शुगर सिंटैक्टिक सैकरिन, या मुफ्त सिंटैक्स जो प्रोग्रामिंग को सरल नहीं बनाता है।[11]


प्रदर्शन तुलना

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

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

प्रबंधित कोड

प्रबंधित कोड वातावरण में निष्पादित प्रोग्राम के लिए, जैसे . नेट फ्रेमवर्क, कई तथ्य प्रदर्शन को प्रभावित करते हैं | जो प्रोग्रामिंग भाषा प्रतिमान और उपयोग की जाने वाली विभिन्न भाषा सुविधाओं से महत्वपूर्ण रूप से प्रभावित होते हैं।[12]


स्यूडोकोड उदाहरण विभिन्न प्रतिमानों की तुलना

सर्कल के क्षेत्र (πr²) की गणना करने के लिए उपयोग किए जाने वाले अनिवार्य, प्रक्रियात्मक और ऑब्जेक्ट ओरिएंटेड दृष्टिकोणों की स्यूडोकोड तुलना, कोई सबरूटीन इनलाइन विस्तार नहीं, कोई मैक्रो (कंप्यूटर विज्ञान) प्रीप्रोसेसर नहीं मानते, अंकगणित पंजीकृत करते हैं, और प्रत्येक निर्देश 'स्टेप' को केवल भारित करते हैं। 1 निर्देश पथ की लंबाई के कच्चे माप के रूप में नीचे प्रस्तुत किया गया है। निर्देश चरण जो अवधारणात्मक रूप से स्तर परिवर्तन कर रहा है | प्रत्येक स्थिति में बोल्ड टाइपफेस में हाइलाइट किया गया है। सर्कल के क्षेत्र की गणना करने के लिए उपयोग किए जाने वाले अंकगणितीय संचालन तीनों प्रतिमानों में समान हैं | अंतर यह है कि प्रक्रियात्मक और ऑब्जेक्ट-उन्मुख प्रतिमान उन कार्यों को सबरूटीन कॉल में लपेटते हैं | जो गणना को सामान्य और पुन: प्रयोज्य बनाता है। मैक्रो प्रीप्रोसेसर का उपयोग करते हुए विशुद्ध रूप से अनिवार्य प्रोग्राम में समान प्रभाव प्राप्त किया जा सकता है | केवल प्रोग्राम के आकार में वृद्धि (केवल प्रत्येक मैक्रो इनवोकेशन साइट पर) के बिना संबंधित यथानुपात रनटाइम निवेश (एन इनवोकेशन के लिए आनुपातिक - जो एक के अंदर स्थित हो सकती है) आंतरिक पाश उदाहरण के लिए)। इसके विपरीत, कंपाइलर द्वारा सबरूटीन इनलाइनिंग प्रक्रियात्मक कार्यक्रमों को आकार में पूरी तरह अनिवार्य कोड के समान कुछ कम कर सकती है। चूँकि, ऑब्जेक्ट-ओरिएंटेड प्रोग्राम के लिए, इनलाइनिंग के साथ भी, ऑब्जेक्ट-ओरिएंटेड तरीकों द्वारा प्रसंस्करण के लिए संदेशों को अभी भी (तर्कों की प्रतियों से) बनाया जाना चाहिए। कॉल का ओवरहेड, आभासी या अन्यथा, नियंत्रण प्रवाह परिवर्तन का प्रभुत्व नहीं है | किन्तु आसपास के कॉलिंग कन्वेंशन निवेशो द्वारा, जैसे फ़ंक्शन प्रस्तावना कोड, स्टैक सेटअप और मापदंड (कंप्यूटर प्रोग्रामिंग)#मापदंड और तर्क पारित करना[13] (यहाँ देखें[14] अधिक यथार्थवादी निर्देश पथ लंबाई, स्टैक और x86 प्लेटफॉर्म पर कॉल से जुड़ी अन्य निवेशो के लिए)। यहां भी देखें [15] एरिक एस रॉबर्ट्स द्वारा स्लाइड प्रस्तुति के लिए ( चर के लिए स्मृति का आवंटन , अध्याय 7) [16] जावा (प्रोग्रामिंग भाषा) ऑब्जेक्ट-ओरिएंटेड लैंग्वेज में तीन परिमेय संख्याओं को जोड़ते समय स्टैक और हीप मेमोरी के उपयोग का चित्रण होता है ।

अनिवार्य प्रक्रियात्मक ऑब्जेक्ट-ओरिएंटेड 
 load r;                      1
 r2 = r * r;                  2
 result = r2 * "3.142";       3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.... storage .............
result variable
constant "3.142"

area proc(r2,res):
   push stack                                 5
   load r2;                                   6
   r3 = r2 * r2;                              7
   res = r3 * "3.142";                        8
   pop stack                                  9
   return;                                   10
...............................................
main proc:
   load r;                                    1
   call area(r,result);
    +load p = address of parameter list;      2
    +load v = address of subroutine 'area';   3
    +goto v with return;                      4
.
.
.
.
.... storage .............
result variable
constant "3.142"
parameter list variable
function pointer (==>area)
stack storage

circle.area method(r2):
   push stack                                 7
   load r2;                                   8
   r3 = r2 * r2;                              9
   res = r3 * "3.142";                       10
   pop stack                                 11
   return(res);                           12,13
...............................................
main proc:
   load r;                                    1
   result = circle.area(r);
      +allocate heap storage;                 2[See 1]
      +copy r to message;                     3
      +load p = address of message;           4
      +load v = addr. of method 'circle.area' 5
      +goto v with return;                    6
.
.
.... storage .............
result variable (assumed pre-allocated)
immutable variable "3.142" (final)
(heap) message variable for circle method call
vtable(==>area)
stack storage
  1. ↑ See section: Allocation of dynamic memory for message and object storage

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

सबरूटीन, मेथड कॉल ओवरहेड

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


उपनेमका कॉल की आवृत्ति में:

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

संदेश और ऑब्जेक्ट भंडारण के लिए गतिशील स्मृति का आवंटन

विशिष्ट रूप से, ऑब्जेक्ट-ओरिएंटेड प्रतिमान में ऑब्जेक्ट निर्माण और संदेश पासिंग दोनों के लिए हीप स्टोरेज से डायनेमिक मेमोरी आवंटन सम्मिलित है। 1994 का बेंचमार्क डिजिटल उपकरण निगम द्वारा विभिन्न प्रकार के सॉफ़्टवेयर पर संचालित बड़े सी और सी++ प्रोग्राम में मेमोरी एलोकेशन कॉस्ट, इंस्ट्रक्शन-लेवल प्रोफाइलिंग टूल का उपयोग करके मापा गया कि डायनेमिक स्टोरेज आवंटन के लिए कितने निर्देश आवश्यक थे। परिणामों से पता चला कि निष्पादित निर्देशों की सबसे कम निरपेक्ष संख्या औसतन लगभग 50 थी | किन्तु अन्य 611 तक पहुंच गए ।[18] मुरली आर. कृष्णन द्वारा हीप: सुख और पीड़ा भी देखें \[19] यह बताता है कि ढेर कार्यान्वयन सभी प्लेटफार्मों के लिए सामान्य रहता है, और इसलिए भारी ओवरहेड होता है। आईबीएम के अरुण अयंगर द्वारा 1996 का आईबीएम पेपर स्केलेबिलिटी ऑफ डायनामिक स्टोरेज एलोकेशन एल्गोरिदम [20] विभिन्न डायनेमिक स्टोरेज एल्गोरिदम और उनके संबंधित निर्देश काउंट को प्रदर्शित करता है। यहां तक ​​कि अनुशंसित एमएफएलएफ एल्गोरिदम (एचएस स्टोन, आरसी 9674) 200 और 400 के बीच की सीमा में निर्देश गणना दिखाता है। उपरोक्त स्यूडोकोड उदाहरण में इस स्मृति आवंटन पथ की लंबाई या स्मृति उपसर्ग ओवरहेड सम्मिलित नहीं है और बाद में संबंधित कचरा सम्मिलित नहीं है। संग्रह ओवरहेड्स दृढ़ता से सुझाव देते हुए कि हीप आवंटन गैर-सामान्य कार्य है | गेम डेवलपर जॉन डब्ल्यू रैटक्लिफ द्वारा खुला स्रोत सॉफ्टवेयर माइक्रोएलोकेटर, जिसमें कोड की लगभग 1,000 पंक्तियाँ होती हैं ।[21]


गतिशील रूप से प्रेषित संदेश कॉल वी प्रत्यक्ष प्रक्रिया कॉल ओवरहेड्स

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

ऑब्जेक्ट्स को क्रमबद्ध करना

Main article: क्रमबद्धता

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

समानांतर कंप्यूटिंग

Main article: समानांतर कंप्यूटिंग

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


यह भी देखें

संदर्भ

  1. ↑ "Programming paradigms: What are the principles of programming?". IONOS. IONOS. Retrieved 30 May 2022.
  2. ↑ "Archived copy" (PDF). Archived from the original (PDF) on 2017-02-02. Retrieved 2015-12-18.{{cite web}}: CS1 maint: archived copy as title (link)
  3. ↑ "Functional programming C#". August 2020. Retrieved 2015-08-14.
  4. ↑ Ruiz, Cedric (May 2014). "Functional CoffeeScript for the impatient". Blog de Cedric Ruiz. Cedric Ruiz. Retrieved 2015-08-09.
  5. ↑ "Functional programming · Advanced R".
  6. ↑ Shelly, Asaf (2008-08-22). "Flaws of Object-oriented Modeling". Intel Software Network. Retrieved 2010-07-04.
  7. ↑ Yegge, Steve (2006-03-30). "Execution in the Kingdom of Nouns". steve-yegge.blogspot.com. Retrieved 2010-07-03.
  8. ↑ "Data-Oriented Design (Or Why You Might be Shooting Yourself in the Foot with OOP) – Games from within".
  9. ↑ Crockford, Douglas. "JavaScript: The World's Most Misunderstood Programming Language". crockford.com.
  10. ↑ Crockford, Douglas. "Private Members in JavaScript". crockford.com.
  11. ↑ "The Jargon File v4.4.7: "syntactic sugar"".
  12. ↑ Gray, Jan (June 2003). "Writing Faster Managed Code: Know What Things Cost". MSDN. Microsoft.
  13. ↑ "कॉल की सही कीमत". wordpress.com. 2008-12-30.
  14. ↑ "X86 Disassembly/Functions and Stack Frames - Wikibooks, open books for an open world".
  15. ↑ Roberts, Eric S. (2008). "Art and Science of Java; Chapter 7: Objects and Memory". Stanford University. Archived from the original on 2011-06-06. Retrieved 2010-05-17.
  16. ↑ Roberts, Eric S. (2008). जावा की कला और विज्ञान. Addison-Wesley. ISBN 978-0-321-48612-7. Archived from the original on 2011-06-06. Retrieved 2010-05-17.
  17. ↑ 17.0 17.1 Guy Lewis Steele, Jr. "Debunking the 'Expensive Procedure Call' Myth, or, Procedure Call Implementations Considered Harmful, or, Lambda: The Ultimate GOTO". MIT AI Lab. AI Lab Memo AIM-443. October 1977. [1] Archived 2009-12-29 at the Wayback Machine[2][3]
  18. ↑ Detlefs, David; Dosser, Al; Zorn, Benjamin (June 1994). "Memory Allocation Costs in Large C and C++ Programs; Page 532". Software: Practice and Experience. 24 (6): 527–542. CiteSeerX 10.1.1.30.3073. doi:10.1002/spe.4380240602. S2CID 14214110.
  19. ↑ Krishnan, Murali R. (February 1999). "Heap: Pleasures and pains". microsoft.com.
  20. ↑ "गतिशील भंडारण आवंटन एल्गोरिदम की मापनीयता". 1996. CiteSeerX 10.1.1.3.3759. {{cite journal}}: Cite journal requires |journal= (help)
  21. ↑ "माइक्रोआवंटक.एच". Google Code. Retrieved 2012-01-29.
  22. ↑ Dean, Jeffrey; Grove, David; Chambers, Craig (1995). "Optimization of Object-Oriented Programs Using Static Class Hierarchy Analysis". ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग. Lecture Notes in Computer Science. Vol. 952. University of Washington. pp. 77–101. CiteSeerX 10.1.1.117.2420. doi:10.1007/3-540-49538-X_5. ISBN 978-3-540-60160-9.
  23. ↑ Teaching FP to Freshmen, from Harper's blog about teaching introductory computer science.[4]


अग्रिम पठन


बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=प्रोग्रामिंग_पैराडाइम_की_तुलना&oldid=182204’