गतिशील रूप से टाइप की गई भाषाएं डेवलपर को निर्दिष्ट करने की अनुमति क्यों नहीं देतीं?


14

डायनामिक रूप से टाइप की गई भाषाएं, मुझे पता है कि डेवलपर्स कभी भी चर के प्रकारों को निर्दिष्ट नहीं करते हैं, या कम से कम उसके लिए बहुत सीमित समर्थन है।

उदाहरण के लिए, जावास्क्रिप्ट ऐसा करने के लिए सुविधाजनक होने पर किसी भी प्रकार के चर को लागू करने के लिए कोई तंत्र प्रदान नहीं करता है। PHP आपको कुछ प्रकार के तर्कों को निर्दिष्ट करने देता है, लेकिन तर्कों के लिए देशी प्रकारों ( intऔर string, आदि) का उपयोग करने का कोई तरीका नहीं है, और तर्कों के अलावा किसी अन्य प्रकार के लिए लागू करने का कोई तरीका नहीं है।

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

ऐसी सीमा क्यों है? क्या यह तकनीकी / प्रदर्शन कारणों से है (मुझे लगता है कि यह जावास्क्रिप्ट के मामले में है), या केवल राजनीतिक कारणों से (जो कि, मेरा मानना ​​है, PHP का मामला है)। क्या यह अन्य गतिशील रूप से टाइप की जाने वाली भाषाओं के लिए एक मामला है जिससे मैं परिचित नहीं हूं?


संपादित करें: उत्तर और टिप्पणियों के बाद, यहाँ एक स्पष्टीकरण के लिए एक उदाहरण है: मान लें कि हमारे पास सादे PHP में निम्न विधि है:

public function CreateProduct($name, $description, $price, $quantity)
{
    // Check the arguments.
    if (!is_string($name)) throw new Exception('The name argument is expected to be a string.');
    if (!is_string($description)) throw new Exception('The description argument is expected to be a string.');
    if (!is_float($price) || is_double($price)) throw new Exception('The price argument is expected to be a float or a double.');
    if (!is_int($quantity)) throw new Exception('The quantity argument is expected to be an integer.');

    if (!$name) throw new Exception('The name argument cannot be an empty string.');
    if ($price <= 0) throw new Exception('The price argument cannot be less or equal to zero.');
    if ($price < 0) throw new Exception('The price argument cannot be less than zero.');

    // We can finally begin to write the actual code.
    // TODO: Implement the method here.
}

कुछ प्रयासों के साथ, इसे फिर से लिखा जा सकता है ( PHP में अनुबंधों द्वारा प्रोग्रामिंग देखें ):

public function CreateProduct($name, $description, $price, $quantity)
{
    Component::CheckArguments(__FILE__, __LINE__, array(
        'name' => array('value' => $name, 'type' => VTYPE_STRING),
        'description' => array('value' => $description, 'type' => VTYPE_STRING),
        'price' => array('value' => $price, 'type' => VTYPE_FLOAT_OR_DOUBLE),
        'quantity' => array('value' => $quantity, 'type' => VTYPE_INT)
    ));

    if (!$name) throw new Exception('The name argument cannot be an empty string.');
    if ($price <= 0) throw new Exception('The price argument cannot be less or equal to zero.');
    if ($price < 0) throw new Exception('The price argument cannot be less than zero.');

    // We can finally begin to write the actual code.
    // TODO: Implement the method here.
}

लेकिन एक ही विधि निम्नानुसार लिखी जाएगी यदि PHP वैकल्पिक रूप से मूल प्रकार के तर्कों को स्वीकार करेगी:

public function CreateProduct(string $name, string $description, double $price, int $quantity)
{
    // Check the arguments.
    if (!$name) throw new Exception('The name argument cannot be an empty string.');
    if ($price <= 0) throw new Exception('The price argument cannot be less or equal to zero.');
    if ($price < 0) throw new Exception('The price argument cannot be less than zero.');

    // We can finally begin to write the actual code.
    // TODO: Implement the method here.
}

कौन सा लिखना कम है? कौन सा पढ़ना आसान है?


1
आप वैकल्पिक रूप से कुछ डायनामिक टाइप की गई भाषाओं में प्रकार निर्दिष्ट कर सकते हैं - जैसे, कॉमन लिस्प में।
एसके-तर्क

काफी डायनामिक टाइप की गई भाषाएं एक प्रकार को बाध्य करने के लिए
जातियों का

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

1
क्लोजर एक ऐसी भाषा का एक उदाहरण है जो आमतौर पर गतिशील रूप से टाइप किया जाता है, लेकिन आप वैकल्पिक रूप से "टाइप संकेत" के माध्यम से चर प्रकार दे सकते हैं (यह आमतौर पर केवल वहीं किया जाता है जहां संकलन-समय प्रकार की जानकारी के प्रदर्शन लाभ प्राप्त करने की आवश्यकता होती है)
मीकेरा

1
ग्रूवी एक गतिशील रूप से टाइप की गई भाषा का एक और उदाहरण है जो एक प्रकार को निर्दिष्ट करने की अनुमति देता है।
एरिक विल्सन

जवाबों:


17

स्टेटिक टाइपिंग होने की बात सांख्यिकीय रूप से यह साबित करने की क्षमता है कि आपका प्रोग्राम प्रकारों के संबंध में सही है (नोट: सभी इंद्रियों में पूरी तरह से सही नहीं)। यदि आपके पास एक स्थिर प्रकार की प्रणाली है, तो आप अधिकांश समय टाइप त्रुटियों का पता लगा सकते हैं।

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

प्रकार की जानकारी को व्यक्त करने के लिए, आपको भाषा का एक हिस्सा चाहिए जो अत्यधिक सरल नहीं हो सकता है। जल्द ही आपको पता चलेगा कि जानकारी intपर्याप्त नहीं है; आप कुछ पसंद करेंगे List<Pair<Int, String>>, फिर पैरामीट्रिक प्रकार, आदि। यह जावा के बजाय सरल मामले में भी पर्याप्त भ्रमित हो सकता है।

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

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

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


1
+1, हालांकि परीक्षण केवल दिखा सकते हैं कि कुछ स्थितियों में त्रुटियां नहीं होती हैं। वे एक सबूत के लिए एक खराब प्रतिस्थापन हैं कि (प्रकार) त्रुटियां असंभव हैं।
इंगो

1
@ इंगो: निश्चित रूप से। लेकिन गतिशील भाषाएँ टिंकरिंग और त्वरित प्रोटोटाइप के लिए बहुत अच्छी हैं, जहाँ आप अपेक्षाकृत सरल विचारों को बहुत तेजी से व्यक्त करते हैं। यदि आप बुलेटप्रूफ उत्पादन कोड चाहते हैं, तो आप बाद में स्थिर भाषा में बदल सकते हैं, जब आपने कुछ स्थिर कोर घटक निकाले होंगे।
9000

1
@ 9000, मुझे संदेह नहीं है कि वे महान हैं। केवल यह बताना चाहता था कि 3 या 4 लंगड़ा टेस्ट लिखना नहीं है, और यह सुनिश्चित नहीं कर सकता है कि प्रकार सुरक्षित हो ।
इंगो

2
@ 9000, यह सच है, और बुरी खबर यह है कि तब भी, व्यावहारिक रूप से असंभव है। यहां तक ​​कि हास्केल या एजडा कोड, उदाहरण के लिए, जैसे, अनुमान पर निर्भर करता है कि रनटाइम में उपयोग की जाने वाली लाइब्रेरी सही है। कहा जा रहा है कि, लगभग 1000 LOC के साथ एक परियोजना में कुछ दर्जन स्रोत कोड फ़ाइलों में फैला हुआ है, यह बहुत अच्छा है जब आप कुछ बदल सकते हैं और आप जानते हैं कि संकलक हर उस रेखा पर इंगित करेगा जहाँ परिवर्तन का प्रभाव पड़ता है।
इंगो

4
खराब लिखित परीक्षण स्थैतिक प्रकार की जाँच के लिए प्रतिस्थापन नहीं हैं: वे हीन हैं। अच्छी तरह से लिखित परीक्षण भी स्थैतिक प्रकार की जाँच के लिए प्रतिस्थापन नहीं हैं: वे श्रेष्ठ हैं।
रीन हेनरिच

8

अधिकांश गतिशील भाषाओं में, आप कम से कम गतिशील रूप से किसी वस्तु या मूल्य के प्रकार का परीक्षण कर सकते हैं ।

और कुछ गतिशील भाषाओं के लिए स्थैतिक प्रकार हीनता, चेकर्स और / या प्रवर्तक हैं: उदा

और पर्ल 6 स्थिर टाइपिंग के साथ एक वैकल्पिक प्रकार प्रणाली का समर्थन करेगा ।


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

यदि आप निंदक थे, तो आप कह सकते हैं कि वैकल्पिक स्थैतिक टाइपिंग दोनों दुनिया में सबसे खराब प्रदान करता है। एक स्थिर प्रकार zealot करने के लिए, यह सभी गतिशील प्रकार विफलताओं को नहीं रोकता है । एक गतिशील प्रकार के पंखे के लिए, यह अभी भी एक सीधी जैकेट है ... यद्यपि पट्टियों के साथ तंग नहीं किया जाता है।


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

4
"लोग आमतौर पर गतिशील भाषाओं का उपयोग करते हैं क्योंकि वे गतिशील रूप से टाइप किए जाते हैं" : जावास्क्रिप्ट का उपयोग किया जाता है क्योंकि यह एकमात्र भाषा है जो अधिकांश ब्राउज़रों द्वारा समर्थित है। PHP का उपयोग किया जाता है क्योंकि यह लोकप्रिय है।
आर्सेनी मौरज़ेंको

2

जावास्क्रिप्ट ने कुछ वैकल्पिक स्थिर टाइपिंग को शामिल करने की योजना बनाई, और ऐसा लगता है जैसे कई परिपक्व गतिशील भाषाएं इस तरह से बढ़ रही हैं-

कारण यह है कि जब आप पहली बार कोड करते हैं, तो आप तेज और गतिशील रूप से टाइप करना चाहते हैं। एक बार जब आपका कोड ठोस हो जाता है, काम कर रहा है और आपके पास कई उपयोग (r) हैं, तो आप त्रुटियों को कम करने के लिए डिज़ाइन को लॉक करना चाहते हैं। (यह उपयोगकर्ताओं और डेवलपर्स दोनों के लिए फायदेमंद है, क्योंकि पूर्व में उनके कॉल पर त्रुटि की जाँच हो जाएगी और बाद वाले गलती से चीजों को नहीं तोड़ेंगे।

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


मुझे उन योजनाओं के बारे में नहीं पता है जो जावास्क्रिप्ट में वैकल्पिक स्थिर टाइपिंग को शामिल करती हैं; लेकिन आशा है कि वे ActiveScript में इतने अत्याचारी नहीं थे। जावास्क्रिप्ट और जावा दोनों का सबसे बुरा।
जेवियर

यह जेएस 4 (या ईसीएमएस्क्रिप्ट 4) के लिए योजना बनाई गई थी, लेकिन उस संस्करण को विवाद के कारण हटा दिया गया था। मुझे यकीन है कि भविष्य में भी कुछ ऐसा ही दिखाई देगा, कुछ भाषा में। (अजगर में आप इसे डेकोरेटर्स, बीटीडब्ल्यू के साथ सॉर्ट कर सकते हैं।)
मैके

1
डेकोरेटर डायनामिक टाइप चेकिंग, एक प्रकार की अभिक्रियाएँ जोड़ते हैं। आप भाषा के चरम गतिशीलता के कारण, पायथन में व्यापक स्थैतिक प्रकार की जाँच नहीं कर सकते हैं, हालांकि आप जितना कठिन प्रयास करते हैं।
9000

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

बेशक यह बुरा नहीं है! यह नैतिकता का मामला नहीं है। कुछ बिंदु पर, प्रकार को एक या दूसरे तरीके से "चेक" किया जाना चाहिए। यदि आप सी में सीपीयू में * (((* * * 0x98765E) लिखते हैं) तो यह जांच करेंगे कि क्या 0x98765E वास्तव में एक डबल का सूचक है।
इंगो

2

अजगर वस्तुओं करना एक प्रकार है।

आप ऑब्जेक्ट बनाते समय टाइप करते हैं।

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

दरअसल, पायथन में एक मैनुअल टाइप चेक लगभग हमेशा समय और कोड की बर्बादी है।

पायथन में टाइप चेकिंग कोड लिखना केवल एक बुरा अभ्यास है।

यदि किसी दुर्भावनापूर्ण प्रकार का उपयोग कुछ दुर्भावनापूर्ण सोशियोपैथ द्वारा किया गया था, तो पायथन के सामान्य तरीके एक साधारण अपवाद को बढ़ाएंगे, जब प्रकार उपयुक्त होने में विफल रहता है।

आप कोई कोड नहीं लिखते हैं, आपका प्रोग्राम अभी भी विफल रहता है TypeError

बहुत दुर्लभ मामले हैं जब आपको रन-टाइम पर टाइप निर्धारित करना चाहिए।

ऐसी सीमा क्यों है?

चूंकि यह "सीमा" नहीं है, इसलिए यह प्रश्न एक वास्तविक प्रश्न नहीं है।


2
"पायथन ऑब्जेक्ट्स में एक प्रकार होता है।" - सच में? बस के रूप में perl वस्तुओं, PHP वस्तुओं और दुनिया में हर अन्य डेटा आइटम। स्थैतिक और गतिशील टाइपिंग के बीच का अंतर केवल तब होता है जब प्रकार की जाँच होने वाली होती है, अर्थात जब टाइप त्रुटियां स्वयं प्रकट होती हैं। यदि वे संकलक त्रुटियों के रूप में दिखाई देते हैं, तो यह स्थैतिक टाइपिंग है, यदि वे रनटाइम त्रुटियों के रूप में दिखाई देते हैं, तो यह गतिशील है।
इंगो

@Ingo: स्पष्टीकरण के लिए धन्यवाद। मुद्दा यह है कि सी ++ और जावा ऑब्जेक्ट्स को एक प्रकार से दूसरे प्रकार में डाला जा सकता है, जिससे किसी वस्तु का प्रकार कुछ अस्पष्ट हो जाता है, और इसलिए उन कंपाइलरों में "टाइप चेकिंग" थोड़ा मुर्की भी होता है। जहां पायथन प्रकार की जाँच - भले ही वह रन टाइम पर हो - बहुत कम मर्की है। इसके अलावा, सवाल यह है कि गतिशील रूप से टाइप की गई भाषाओं के पास प्रकार नहीं है। अच्छी खबर यह है कि यह सामान्य गलती नहीं करता है।
S.Lott

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

2

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

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

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


0

आपको हास्केल में दिलचस्पी हो सकती है - यह प्रकार है सिस्टम कोड से प्रकारों को संक्रमित करता है, और आप प्रकार भी निर्दिष्ट कर सकते हैं।


5
हास्केल एक बेहतरीन भाषा है। यह किसी तरह गतिशील भाषाओं के विपरीत है: आप प्रकारों का वर्णन करने में बहुत समय बिताते हैं, और आमतौर पर एक बार जब आप अपने प्रकारों को लगाते हैं तो कार्यक्रम काम करता है :)
9000

@ 9000: वास्तव में। एक बार संकलित करने के बाद, यह आमतौर पर काम करता है। :)
मैके

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

0

जैसा कि अन्य उत्तरों ने बताया है, प्रोग्रामिंग भाषा को लागू करते समय टाइप करने के दो तरीके हैं।

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

दोनों दृष्टिकोण मान्य हैं, और जिसका उपयोग करना आंशिक रूप से प्रदर्शन जैसे तकनीकी विचारों पर और आंशिक रूप से भाषा के लिए लक्ष्य बाजार जैसे राजनीतिक कारणों पर निर्भर करता है।


0

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

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

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

आशा है कि यह आपकी मदद करता है।


-1

यह बस ऐसा करने के लिए कोई मतलब नहीं है।

क्यों?

क्योंकि DTLs की प्रकार प्रणाली ठीक ऐसी है कि संकलन समय पर निर्धारित नहीं की जा सकती है। इसलिए, कंपाइलर यह भी जांच नहीं कर सका कि निर्दिष्ट प्रकार समझ में आएगा।


1
क्यों? यह किस प्रकार की अपेक्षा करने के लिए एक संकलक को इंगित करने के लिए एक सही समझ में आता है। यह किसी भी प्रकार की प्रणाली की कमी के विपरीत नहीं होगा।
एसके-तर्क

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

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

@ एसके-तर्क: शायद आप मुझे बता सकते हैं कि सीएल में कब और कैसे त्रुटियों का पता चलता है? वैसे भी, @MainMa ने अपने प्रश्न में बहुत अच्छी तरह से यथास्थिति को संक्षेप में प्रस्तुत किया है: यह "शुद्ध रूप से" गतिशील भाषाओं से कोई उम्मीद कर सकता है।
इंगो

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

-1

गो पर एक नज़र डालें, सतह पर यह सांख्यिकीय रूप से टाइप किया गया है, लेकिन उन प्रकार के इंटरफेस हो सकते हैं जो अनिवार्य रूप से गतिशील हैं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.