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

From Vigyanwiki
No edit summary
 
Line 231: Line 231:
* [http://hbfs.wordpress.com/2008/12/30/the-true-cost-of-calls/ The True Cost of Calls]- from "Harder, Better, Faster, Stronger" blog by computer scientist [https://web.archive.org/web/20090421000542/http://www.stevenpigeon.org/Publications/ Steven Pigeon]
* [http://hbfs.wordpress.com/2008/12/30/the-true-cost-of-calls/ The True Cost of Calls]- from "Harder, Better, Faster, Stronger" blog by computer scientist [https://web.archive.org/web/20090421000542/http://www.stevenpigeon.org/Publications/ Steven Pigeon]


{{DEFAULTSORT:Comparison of programming paradigms}}[[Category: प्रोग्रामिंग प्रतिमान|*]] [[Category: स्यूडोकोड के उदाहरण वाले लेख]]
{{DEFAULTSORT:Comparison of programming paradigms}}


 
[[Category:All articles lacking reliable references|Comparison of programming paradigms]]
 
[[Category:Articles lacking reliable references from October 2020|Comparison of programming paradigms]]
[[Category: Machine Translated Page]]
[[Category:Articles with hatnote templates targeting a nonexistent page|Comparison of programming paradigms]]
[[Category:Created On 13/05/2023]]
[[Category:CS1 errors]]
[[Category:Vigyan Ready]]
[[Category:CS1 maint]]
[[Category:Created On 13/05/2023|Comparison of programming paradigms]]
[[Category:Lua-based templates|Comparison of programming paradigms]]
[[Category:Machine Translated Page|Comparison of programming paradigms]]
[[Category:Pages with script errors|Comparison of programming paradigms]]
[[Category:Templates Vigyan Ready|Comparison of programming paradigms]]
[[Category:Templates that add a tracking category|Comparison of programming paradigms]]
[[Category:Templates that generate short descriptions|Comparison of programming paradigms]]
[[Category:Templates using TemplateData|Comparison of programming paradigms]]
[[Category:Webarchive template wayback links]]
[[Category:प्रोग्रामिंग प्रतिमान|*]]
[[Category:स्यूडोकोड के उदाहरण वाले लेख|Comparison of programming paradigms]]

Latest revision as of 10:04, 12 June 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=184557’