क्या गतिशील भाषाओं का वास्तविक लाभ है? [बन्द है]

Question

_{पहले मैं कहना चाहता हूं कि जावा एकमात्र ऐसी भाषा है जिसका मैंने कभी इस्तेमाल किया है, इसलिए कृपया इस विषय पर अपनी अज्ञानता का बहाना करें।}

डायनामिक रूप से टाइप की गई भाषाएं आपको किसी भी चर में कोई भी मूल्य रखने की अनुमति देती हैं। इसलिए उदाहरण के लिए आप निम्नलिखित फ़ंक्शन (psuedocode) लिख सकते हैं:

void makeItBark(dog){
    dog.bark();
}

और आप इसके अंदर से गुजर सकते हैं जो भी मूल्य। जब तक मूल्य में एक bark()विधि है, तब तक कोड चलेगा। अन्यथा, एक रनटाइम अपवाद या समान कुछ फेंक दिया जाता है। _{(कृपया मुझे सही करें अगर मैं इस बारे में गलत हूं)।}

लगातार, यह आपको लचीलापन देता है।

हालाँकि, मैंने डायनेमिक भाषाओं पर कुछ पठन किया, और लोग क्या कहते हैं कि डायनामिक भाषा में कोड बनाते समय या लिखते समय, आप प्रकारों के बारे में सोचते हैं और उन्हें ध्यान में रखते हैं, जितना आप वैधानिक रूप से टाइप की गई भाषा में करेंगे।

इसलिए उदाहरण के लिए जब makeItBark()फ़ंक्शन लिखते हैं, तो आप इसके लिए केवल 'उन चीजों को स्वीकार करने का इरादा रखते हैं जो छाल कर सकते हैं', और आपको अभी भी यह सुनिश्चित करने की आवश्यकता है कि आप केवल इस प्रकार की चीजों को इसमें पारित करते हैं। अंतर केवल इतना है कि अब संकलक आपको यह नहीं बताएगा कि आपने कब गलती की।

निश्चित रूप से, इस दृष्टिकोण का एक फायदा है जो कि स्थिर भाषाओं में, 'इस फ़ंक्शन को स्वीकार करता है कि कुछ भी कर सकता है जो छाल कर सकता है', आपको एक स्पष्ट Barkerइंटरफ़ेस लागू करना होगा । फिर भी, यह एक मामूली लाभ की तरह लगता है।

क्या मैं कुछ भूल रहा हूँ? मैं वास्तव में एक गतिशील रूप से टाइप की गई भाषा का उपयोग करके क्या प्राप्त कर रहा हूं?

Comments

makeItBark(collections.namedtuple("Dog", "bark")(lambda x: "woof woof"))। यह तर्क एक वर्ग भी नहीं है , यह एक अनाम नाम है। बत्तख टाइपिंग ("अगर यह एक तरह से बंद हो जाता है ...") आपको अनिवार्य रूप से शून्य प्रतिबंध और कोई सिंटैक्टिक ओवरहेड के साथ तदर्थ इंटरफेस नहीं करने देता है। आप इसे जावा जैसी भाषा में कर सकते हैं, लेकिन आप बहुत सारे गंदे प्रतिबिंब के साथ समाप्त होते हैं। यदि जावा में एक फ़ंक्शन के लिए एक ArrayList की आवश्यकता होती है और आप इसे एक और संग्रह प्रकार देना चाहते हैं, तो आप SOL हैं। अजगर में जो ऊपर भी नहीं आ सकता है।

— फॉशी

इस तरह का प्रश्न पहले पूछा गया है: यहाँ , यहाँ , और यहाँ । विशेष रूप से पहला उदाहरण आपके प्रश्न का उत्तर देने के लिए लगता है। हो सकता है कि आप इसे अलग बनाने के लिए आपका फिर से वर्णन कर सकें?

— log

ध्यान दें कि C ++ में उदाहरण के लिए, आपके पास एक टेम्पलेट फ़ंक्शन हो सकता है जो किसी भी प्रकार T के साथ काम करता है जिसमें एक bark()विधि होती है, जिसमें कंपाइलर शिकायत करते हैं जब आप कुछ गलत पास करते हैं, लेकिन वास्तव में एक इंटरफ़ेस घोषित किए बिना जिसमें छाल () होता है।

— विल्बर्ट

@ घोषी पायथन में तर्क अभी भी एक विशेष प्रकार का है - उदाहरण के लिए, यह एक संख्या नहीं हो सकती है। यदि आपके पास वस्तुओं का अपना स्वयं का तदर्थ कार्यान्वयन है, जो अपने सदस्यों को कुछ कस्टम getMemberफ़ंक्शन के माध्यम से पुनर्प्राप्त करता है, makeItBarkतो आप को dog.barkइसके बजाय बुलाया जाता है dog.getMember("bark")। क्या कोड काम करता है कि सभी लोग स्पष्ट रूप से अजगर की मूल वस्तु प्रकार का उपयोग करने के लिए सहमत हैं।

— डोभाल

@ घोष Just because I wrote makeItBark with my own types in mind doesn't mean you can't use yours, wheras in a static language it probably /does/ mean that.जैसा कि मेरे जवाब में कहा गया है, सामान्य तौर पर ऐसा नहीं है । जावा और सी # के लिए यही स्थिति है, लेकिन उन भाषाओं में अपंग प्रकार और मॉड्यूल सिस्टम हैं, इसलिए वे स्थिर टाइपिंग के प्रतिनिधि नहीं हैं। मैं makeItBarkकई वैधानिक रूप से टाइप की जाने वाली भाषाओं में पूरी तरह से सामान्य लिख सकता हूं , यहां तक ​​कि गैर-कार्यात्मक व्यक्ति जैसे C ++ या D.

— Doval

Answer 1

डायनामिक-टाइप की गई भाषाएं यूनि-टाइप की जाती हैं

टाइप सिस्टम की तुलना में, गतिशील टाइपिंग में कोई फायदा नहीं है। डायनेमिक टाइपिंग स्टैटिक टाइपिंग का एक विशेष मामला है - यह एक स्टेटिक-टाइप की गई भाषा है जहाँ हर वेरिएबल में एक ही प्रकार होता है। आप प्रत्येक चर प्रकार के होने के द्वारा जावा (माइनस कंसिस्टेंसी) में एक ही चीज प्राप्त कर सकते हैं Object, और प्रकार के "ऑब्जेक्ट" मान होने पर Map<String, Object>:

void makeItBark(Object dog) {
    Map<String, Object> dogMap = (Map<String, Object>) dog;
    Runnable bark = (Runnable) dogMap.get("bark");
    bark.run();
}

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

एक विधिवत टाइप की हुई भाषा में बत्तख की छाल बनाना

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

class Barkable a where
    bark :: a -> unit

यह बाधा व्यक्त करता है कि कुछ प्रकार aको बार्केबल माना जाता है, एक barkफ़ंक्शन मौजूद होना चाहिए जो उस प्रकार का मान लेता है और कुछ भी नहीं लौटाता है।

फिर आप Barkableबाधा के संदर्भ में सामान्य कार्य लिख सकते हैं :

makeItBark :: Barkable a => a -> unit
makeItBark barker = bark (barker)

यह कहता है कि makeItBarkकिसी भी प्रकार की संतोषजनक Barkableआवश्यकताओं के लिए काम करेगा । यह एक के समान लग सकता है interfaceजावा या सी # में है, लेकिन यह एक बड़ा फायदा है - प्रकार निर्दिष्ट करने के लिए की जरूरत नहीं है सामने किस प्रकार कक्षाएं वे पूरा करते हैं। मैं कह सकता हूँ कि प्रकार Duckहै Barkableकिसी भी समय है, भले ही Duckएक तीसरे पक्ष के प्रकार मैं नहीं लिखा था है। वास्तव में, यह फर्क नहीं पड़ता कि के लेखक Duckएक नहीं लिखा था barkसमारोह - जब मैं भाषा कि बताओ मैं बाद-तथ्य यह प्रदान कर सकते हैं Duckको संतुष्ट करता है Barkable:

instance Barkable Duck where
    bark d = quack (punch (d))

makeItBark (aDuck)

यह कहता है कि Ducks छाल कर सकते हैं, और उनके छाल कार्य को चुटकी बनाने से पहले बतख को छिद्रित करके कार्यान्वित किया जाता है । उस रास्ते से, हम makeItBarkबतख पर कॉल कर सकते हैं।

Standard MLऔर OCamlइसमें और भी अधिक लचीला है कि आप एक ही प्रकार के वर्ग को एक से अधिक तरीकों से संतुष्ट कर सकते हैं । इन भाषाओं में मैं कहता हूं कि पूर्णांकों पारंपरिक आदेश का उपयोग कर आदेश दिया जा सकता है और फिर बिलकुल पलट गया और कहते हैं कि वे कर रहे हैं कर सकते हैं भी विभाज्यता द्वारा orderable (जैसे 10 > 5क्योंकि 10 5 से विभाज्य है)। हास्केल में आप केवल एक बार क्लास टाइप कर सकते हैं। (इससे हास्केल को स्वचालित रूप से पता चल जाता है कि barkबतख पर कॉल करना ठीक है ; एसएमएल या ओकेएमएल में आपको स्पष्ट होना चाहिए कि आप किस bark फ़ंक्शन को चाहते हैं, क्योंकि एक से अधिक हो सकते हैं।)

संक्षिप्ति

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

सही लेकिन बीमार टाइप के कार्यक्रम

निष्पक्ष होने के लिए, स्टैटिक टाइपिंग जरूरी कुछ कार्यक्रमों को नियमबद्ध करता है जो तकनीकी रूप से सही होते हैं भले ही टाइप चेकर इसे सत्यापित न कर सके। उदाहरण के लिए:

if this_variable_is_always_true:
    return "some string"
else:
    return 6

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

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

सेब और संतरे

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

Comments

आप पहले पैराग्राफ के लिए अपने स्रोत का श्रेय देना भूल गया - existentialtype.wordpress.com/2011/03/19/...

@ मैट रे: 1, मैंने यह नहीं माना कि यह महत्वपूर्ण नहीं है; मैंने इसे संक्षिप्तता के तहत संबोधित किया। पुन :: 2, हालांकि मैंने कभी स्पष्ट रूप से यह नहीं कहा, "अच्छा" से मेरा मतलब है "पूरी तरह से अनुमान है" और "में एक मॉड्यूल प्रणाली है जो आपको तथ्य के बाद हस्ताक्षर टाइप करने के लिए कोड से मिलान करने की अनुमति देती है ", जावा की तरह अप-फ्रंट नहीं। सी # का इंटरफेस। पुन: 3, प्रमाण का भार आपको यह समझाने के लिए है कि कैसे दो भाषाओं को बराबर वाक्यविन्यास और विशेषताओं के साथ दिया गया है, एक गतिशील रूप से टाइप किया गया है और दूसरा पूर्ण प्रकार के आक्षेप के साथ, आप दोनों में समान लंबाई का कोड नहीं लिख पाएंगे। ।

— डोभाल

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

— डोभाल

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

— मेसन व्हीलर

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

— जियोर्जियो

Answer 2

यह एक कठिन और काफी व्यक्तिपरक मुद्दा है। " इस मंच का।)

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

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

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

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

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

अंत में, यह तथ्य कि इस तरह की अलग-अलग भाषाएं दोनों बहुत लोकप्रिय हैं और मरने के कोई संकेत नहीं दिखाते हैं, यह दर्शाता है कि लोग प्रोग्रामिंग के बारे में बहुत अलग तरीके से जाते हैं। मुझे लगता है कि प्रोग्रामिंग भाषा की विशेषताएं काफी हद तक मानव कारकों के बारे में हैं - जो मानव निर्णय लेने की प्रक्रिया का बेहतर समर्थन करती हैं - और जब तक लोग बहुत अलग तरीके से काम करते हैं, बाजार एक साथ बहुत अलग समाधान प्रदान करेगा।

Comments

जवाब के लिए धन्यवाद। आपने कहा कि एक कंपाइलर द्वारा कुछ लोगों की पसंद नापसंद को बताया जा रहा है। [..] वे एक खोजपूर्ण प्रोग्रामिंग शैली पसंद करते हैं जहाँ आप एक योजना के बिना वास्तविक व्यापार कोड लिखते हैं जो आपको बताएगा कि कौन से प्रकार और तर्क कहाँ उपयोग करने के लिए हैं। ' यह वह चीज है जो मुझे समझ में नहीं आती: प्रोग्रामिंग म्यूजिकल इंप्रूवमेंट की तरह नहीं है। संगीत में यदि आप गलत नोट मारते हैं, तो यह अच्छा लग सकता है। प्रोग्रामिंग में, यदि आप किसी फ़ंक्शन में कुछ पास करते हैं जो वहां होने वाला नहीं है, तो आपको सबसे अधिक संभावना गंदा कीड़े मिलेगी। (अगली टिप्पणी में जारी है)।

— अवीव कोहन

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

— किलियन फोथ

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

— अवीव कोहन

लोग अक्सर बहुत भिन्न प्रकार की परियोजनाओं के बारे में बात करते हैं (विशेष रूप से आकार के बारे में)। एक पूर्ण ईआरपी प्रणाली कहने की तुलना में एक वेब साइट के लिए व्यावसायिक तर्क बहुत सरल होगा। कम जोखिम है कि आप चीजों को गलत कर लें और कुछ कोड का पुन: उपयोग करने में सक्षम होने का लाभ अधिक प्रासंगिक है। मान लें कि मेरे पास कुछ कोड है जो डेटा संरचना से एक Pdf (या कुछ HTML) उत्पन्न करता है। अब मेरे पास एक अलग डेटा स्रोत है (पहले कुछ REST API से JSON था, अब यह एक्सेल आयातक है)। रूबी जैसी भाषा में पहली संरचना को 'अनुकरण' करना, इसे 'छाल बनाना' और Pdf कोड का पुन: उपयोग करना सुपर आसान हो सकता है।

— थोरस्टेन म्यूलर

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

— फोसि

Answer 3

डायनेमिक भाषाओं का उपयोग करते हुए लिखे गए कोड को स्थिर प्रकार की प्रणाली से जोड़ा नहीं जाता है। इसलिए, युग्मन की यह कमी खराब / अपर्याप्त स्थिर प्रकार प्रणालियों की तुलना में एक फायदा है (हालांकि यह एक महान स्थैतिक प्रकार की प्रणाली की तुलना में धोना या नुकसान हो सकता है)।

इसके अलावा, एक गतिशील भाषा के लिए, एक स्थिर प्रकार प्रणाली को डिज़ाइन, कार्यान्वित, परीक्षण और रखरखाव नहीं करना पड़ता है। यह स्थैतिक प्रकार प्रणाली के साथ भाषा की तुलना में कार्यान्वयन को सरल बना सकता है।

Comments

क्या लोग अंततः अपनी इकाई परीक्षणों (जब एक अच्छे परीक्षण कवरेज को लक्षित करते हैं) के साथ एक बुनियादी स्थिर प्रकार प्रणाली को फिर से लागू करने की प्रवृत्ति रखते हैं?

— डेन

यहाँ भी आप "युग्मन" से क्या मतलब है? यह एक उदाहरण सूक्ष्म सेवाओं वास्तुकला में कैसे प्रकट होगा?

— डेन

@ 1) अच्छा सवाल है, हालांकि, मुझे लगता है कि यह ओपी के दायरे से बाहर है और मेरे जवाब का है। 2) मेरा मतलब इस अर्थ में युग्मन है ; संक्षेप में, विभिन्न प्रकार की प्रणालियाँ उस भाषा में लिखे गए कोड पर विभिन्न (असंगत) बाधाओं को लगाती हैं। क्षमा करें, मैं अंतिम प्रश्न का उत्तर नहीं दे सकता - मुझे समझ में नहीं आता कि इस संबंध में सूक्ष्म सेवाओं के बारे में क्या खास है।

@ डेन: वेरी गुड पॉइंट: मैं अक्सर देखता हूं कि पायथन कवर त्रुटियों में लिखी गई यूनिट टेस्ट मैं एक संकलित भाषा में संकलक द्वारा पकड़ा जाएगा।

— जियोर्जियो

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

— जियोर्जियो