चर को एक प्रकार की आवश्यकता क्यों है?

Question

तो हम लिखते हैं:

Customer c = new Customer();

डिजाइन ऐसा क्यों नहीं है कि हम लिखें:

c = new Customer();
c.CreditLimit = 1000;

कंपाइलर एक ग्राहक को सी पॉइंट आउट कर सकता है और ग्राहक के सदस्यों को सी पर आमंत्रित करने की अनुमति दे सकता है?

मुझे पता है कि हम लिखना चाहते हैं:

IPerson c = new Customer();
IPerson e = new Employee();

इतना लिखने में सक्षम होने के लिए:

public string GetName(IPerson object)
{
    return object.Name
}

string name = GetName(c); // or GetName(e);

लेकिन अगर हमने लिखा है:

c = new Customer();
e = new Employee();

हम अभी भी लिख सकते हैं:

public string GetName(object)
{
    return object.Name
}    

string name = GetName(c); // or GetName(e);

कंपाइलर उपरोक्त कोड के बारे में तुरंत शिकायत कर सकता है यदि ऑब्जेक्ट c संदर्भों का प्रकार नाम संपत्ति का समर्थन नहीं करता है (क्योंकि यह जांच सकता है कि विधि के भीतर कौन से सदस्य तर्क / पैरामीटर पर उपयोग किए जाते हैं), या रनटाइम शिकायत कर सकता है।

यहां तक ​​कि C # के डायनामिक कीवर्ड के साथ, हम अभी भी एक चर 'प्रकार' (रनटाइम पर निर्धारित) का उपयोग कर रहे हैं। लेकिन एक चर को एक प्रकार की आवश्यकता क्यों है? मुझे यकीन है कि एक अच्छा कारण होना चाहिए, लेकिन मैं इसके बारे में सोच भी नहीं सकता!

Comments

यही कारण है कि पायथन और रूबी (और अन्य) जैसी गतिशील भाषाएं हैं। इस सवाल का कोई जवाब नहीं है । यह एक तथ्य है कि कुछ भाषाएं प्रकार की घोषणाओं का उपयोग करती हैं और कुछ भाषाएं नहीं करती हैं।

— S.Lott

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

— S.Lott

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

— मेसन व्हीलर

var x = 1; - क्या आपका मतलब 32 बिट, 64 बिट, 16 बिट नंबर है? बाइट? नाव? दोगुना? दशमलव? यह सिर्फ आदिम लोगों के साथ काम कर रहा है।

— नौकरी

आप varC # में उपयोग कर सकते हैं और जहाँ आप एक चर घोषित करना चाहते हैं, उसके बारे में अधिक जानना हमेशा अच्छा होता है।

— डैनियल लिटिल

Answer 1

लेकिन एक चर को एक प्रकार की आवश्यकता क्यों है?

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

Comments

कृपया नीचे बताएं।

— फ्रेड फू

इसके अलावा, डायनेमिक टाइपिंग एक प्रदर्शन लागत पर आती है, क्योंकि रनटाइम के दौरान टाइप जानकारी की जांच की जानी चाहिए।

— चार्ल्स साल्विया

@CharlesSalvia: अच्छी बात है, जवाब में कहा।

— फ्रेड फू

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

— फ्रेड फू

@sturdytree हालांकि यह सच नहीं भाषाओं है कि वास्तव में देखते हैं कि है typeless प्रकार की जाँच के साथ चर, वहाँ भाषाओं होती है प्रकार निष्कर्ष । यह कहना है, भाषा आपके चर के उपयोग को देखती है और आपके उपयोग से प्रकार को घटाती है। यदि कोई संघर्ष है (जैसे आप प्रदर्शन करते हैं a = new Bar()और फिर बाद में कक्षा से एक विधि कहते हैं Baz), संकलक एक त्रुटि उठाता है। हास्केल और ओकेम्ल जैसी भाषाओं ने अग्रणी प्रकार का अनुमान लगाया, लेकिन यह varकीवर्ड के साथ C # में मौजूद है ।

— क्वांटिकल

Answer 2

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

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

उदाहरण के लिए मान लीजिए कि आपके पास निम्न विधि है:

public addCustomerContact(Customer client, Employee contact) {
   ...
} 

यह संभव होगा, यदि आपके पास अपने कोड में एक ग्राहक bobऔर एक कर्मचारी jamesहै, तो गलती से कॉल करने के लिए addCustomerContact(james, bob), जो कि अमान्य है। लेकिन यदि कंपाइलर चर के प्रकारों को नहीं जानता है, तो यह आपको चेतावनी नहीं दे सकता है कि आपने एक अमान्य कॉल किया है, इसके बजाय, रनटाइम पर कोई त्रुटि होती है ... और चूंकि डायनामिक-टाइप की गई भाषाएं जांच नहीं करती हैं विधियों में दिए गए मापदंडों के प्रकार, वह समस्या तब होती है जब आपका कोड jamesऑब्जेक्ट के ग्राहक-केवल गुणों , या कर्मचारी-केवल ऑब्जेक्ट के गुणों का उपयोग करने का प्रयास करता है bob। यह लंबे समय के बाद हो सकता है कि जोड़ी (जेम्स, बॉब) को ग्राहक संपर्कों की सूची में जोड़ा गया।

अब, आप आश्चर्य हो सकता है, क्यों संकलक अभी भी प्रकार के अनुमान नहीं लगा सकता jamesऔर bob, और अभी भी हमें चेतावनी दी है? यह कभी-कभी संभव हो सकता है, लेकिन अगर चर का वास्तव में कोई प्रकार नहीं है, तो हम निम्नलिखित कार्य कर सकते हैं:

var james;
var bob;
if (getRandomNumber() > 0.5) {
   james = new Customer();
   bob = new Employee();
} else {
   james = new Employee();
   bob = new Customer();
}

किसी भी वैरिएबल को किसी भी मूल्य को सौंपना पूरी तरह से कानूनी है, क्योंकि हमने कहा कि चर का कोई प्रकार नहीं है। इसका मतलब यह भी है कि हम हमेशा एक चर के प्रकार को नहीं जान सकते हैं, क्योंकि यह निष्पादन के विभिन्न रास्तों के आधार पर विभिन्न प्रकारों का हो सकता है।

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

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

Comments

धन्यवाद थिओडोर "लेकिन यदि कंपाइलर चर के प्रकारों को नहीं जानता है, तो यह आपको चेतावनी नहीं दे सकता है कि आपने एक अमान्य कॉल किया है" जैसा कि आप उल्लेख करते हैं, संकलक उन वस्तुओं के प्रकारों को जान सकते हैं जो चर इंगित करते हैं।

— तगड़ा

Theodore: आपके उदाहरण में james / bob, हमें प्रोग्रामर के रूप में पता होना चाहिए कि हमने अपने चर (और अच्छे नामकरण मदद) का उपयोग कैसे किया है और इसलिए मुझे इसके साथ कोई समस्या नहीं दिखती है। जब आप कहते हैं कि "हम हमेशा एक चर के प्रकार को नहीं जान सकते हैं" तो मेरा मतलब है कि हम हमेशा उस वस्तु के प्रकार को नहीं जान सकते हैं जो चर इंगित करता है, लेकिन संकलक इस काम कर सकता है और इसलिए गलत सदस्यों के बारे में चेतावनी देता है। लागू (यानी हम स्थैतिक जाँच कर सकते हैं)।

— तगड़ा

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

— थियोडोर मर्डॉक

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

— तगड़ा

-1; मजबूत / कमजोर टाइपिंग स्टैटिक / डायनेमिक टाइपिंग के लिए ऑर्थोगोनल है। सी सांख्यिकीय रूप से कमजोर टाइप किया गया है; लिस्प और पायथन दोनों गतिशील रूप से दृढ़ता से टाइप किए गए हैं।

— फ्रेड फू

Answer 3

तो पेशेवर प्रोग्रामर को यह पता लगाने की जरूरत नहीं है कि क्या

10 + "10"

is "1010" or 20....

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

Comments

यानी, पर्ल एक समझदार भाषा नहीं है? :)

— फ्रेड फू

@larsmans: तथ्य की बात के रूप में, नहीं, यह नहीं है। लेकिन यह विशुद्ध रूप से राय है।

— NotMe

@ क्रिस हैली: मुझे खुशी है कि यह अब तथ्य की बात है। कृपया मेरे कार्यस्थल से कभी भी मेरे पर्ल-प्यार करने वाले सहयोगियों को मनाने के लिए;)

— फ्रेड फू

10 + "10" टाइप पूर्णांक की वस्तु और टाइप स्ट्रिंग के ऑब्जेक्ट पर '+' ऑपरेटर का उपयोग कर रहा है। कंपाइलर एक त्रुटि जारी करेगा। मेरा प्रश्न चर के प्रकार से है, वस्तु से नहीं।

— तगड़ा

यह है वैध सी: यह सूचक अंकगणित।

— dan04

Answer 4

मान लें कि आपके पास एक चर one(1 पर सेट) है और मूल्यांकन करने का प्रयास किया गया है one + one। यदि आपके पास प्रकार का कोई विचार नहीं था, तो 1 + 1 अस्पष्ट होगा। आप तर्क दे सकते हैं कि 2 या 11 सही उत्तर हो सकते हैं। यदि संदर्भ नहीं दिया जाता है तो यह अस्पष्ट हो जाता है।

मैंने देखा है इस SQLite जहां डेटाबेस प्रकार अनजाने लिए स्थापित किया गया में होने VARCHARके बजाय INTऔर जब आपरेशन किया गया था लोग अप्रत्याशित परिणाम मिल रहे थे।

C # में यदि संदर्भ एक प्रकार का है, तो आप varकीवर्ड का उपयोग कर सकते हैं ।

var c = new Customer();
var e = new Employer();

संकलित समय पर सी और ई को बांझ प्रकार के साथ संकलित करेंगे।

Comments

पायथन में, 1 + 1हमेशा प्रकार होता है int, लेकिन इसे घोषित करने की कोई आवश्यकता नहीं है। सवाल यह है कि चर का एक प्रकार क्यों होता है, मूल्यों का नहीं ।

— फ्रेड पू

क्षमा करें आप मेरे उदाहरण में उपयोग variablesनहीं valuesहोने पर देखने के 1 + 1लिए थे। मुझे लगता है कि यह स्पष्ट नहीं था।

— स्टीफन क्वान

फिर भी, गतिशील रूप से टाइप की गई भाषाएं इससे निपट सकती हैं। पायथन में, one=1; print(one+one)प्रिंट 2। one="1"; print(one+one)प्रिंट करता है 11। SQLite उदाहरण अधिक ठोस है, लेकिन समस्या वहाँ कमजोर टाइपिंग में से एक है, इसलिए यह वास्तव में C # के लिए प्रासंगिक नहीं है।

— फ्रेड पू

मेरी सुझाई गई योजना में, एक = 1 का मतलब पूर्णांक प्रकार की ओर इशारा करते हुए एक चर है (मैं किसी भी प्रकार का कोई सुझाव नहीं दे रहा हूं - वस्तुओं का एक प्रकार होगा)। एक + एक तो अस्पष्ट नहीं होगा (हम दो पूर्णांक वस्तुओं / मानों को जोड़ रहे हैं)

— मजबूती से

हाय @ dan04, मैंने इसे ORDER BYअनजाने में एक VARCHARक्षेत्र पर किया । Stackoverflow.com/questions/9103313/… देखें ।

— स्टीफन क्वॉन

Answer 5

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

यह भी संभव है एक चर करने के लिए है एक प्रकार है, लेकिन आप के लिए नहीं हो सकता बारे में कार्यक्रम में टाइप करें। इसे आमतौर पर टाइप इंट्रेंस कहा जाता है। एमएल, हास्केल, और उनके वंशजों में शक्तिशाली प्रकार का अनुमान है; कुछ अन्य भाषाओं में यह कम रूपों में है, जैसे कि C ++ की autoघोषणाएँ।

प्रकार के निष्कर्ष के खिलाफ मुख्य तर्क यह है कि यह पठनीयता को नुकसान पहुंचाता है। आमतौर पर कोड को समझना आसान होता है जब प्रकार नीचे लिखे जाते हैं।

Answer 6

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

यदि आप निम्नलिखित चर घोषित करते हैं:

myVar      = 5;
myOtherVar = "C";

आप इन चरों के बारे में क्या अनुमान लगा सकते हैं? है myVarपर हस्ताक्षर किए या अहस्ताक्षरित? यह 8-बिट, 64-बिट, या बीच में कुछ है? है myOtherVarएक स्ट्रिंग (प्रभावी रूप से एक सरणी) या एक चार? क्या यह एएनएसआई या यूनिकोड है?

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

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

Comments

अच्छा बिंदु, हालांकि संकलक मूल्य के आधार पर सबसे कुशल प्रकार (उदाहरण के लिए छोटे इंट) का उपयोग कर सकता है, मैं देख सकता हूं कि हम "सी" चाहते हैं कि चर के बजाय एक स्ट्रिंग ऑब्जेक्ट हो ताकि कुछ संचालन करने में सक्षम हो सकें । हालांकि ऐसे मामलों में, हम सिर्फ एक = (स्ट्रिंग) "सी" निर्दिष्ट कर सकते हैं। यह एक स्ट्रिंग ऑब्जेक्ट बनाता है और 'a' (अनकैप्ड वैरिएबल) बस इसे इंगित करता है। मैं इसे स्ट्रिंग a = "C" से अधिक भयानक नहीं देखता;

— तगड़ा

Answer 7

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

मैं यह क्यों कह रहा हूं? क्योंकि इससे आपके प्रश्न का उत्तर मिल जाता है।

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

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

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

मुझे लगता है कि यह कहना बेकार है कि मैं चाल के नियमों को पसंद करता हूं, विशेष रूप से लंबी अवधि के लिए, बड़ी टीम (उर्फ: "गंभीर") परियोजनाएं। कारण: जहां तक ​​मुझे पता है, एक SW प्रोजेक्ट विफलता / स्लिप के सबसे संभावित कारण हैं: अस्पष्ट आवश्यकताएं और खराब डिजाइन (80%! एक अध्ययन से मुझे पता है), और वास्तविक कोडिंग के लिए केवल कुछ प्रतिशत शेष है। सभी नियम और अनुबंध क्लीनर डिजाइन को लागू करते हैं, आगे की सोच रखते हैं, और उचित लोगों द्वारा पहले और निर्णय किए जाने की आवश्यकता होती है। प्रकार के नियमों का मतलब है: कम "स्वतंत्रता" और "शीतलता" - अधिक तैयारी, सोच, मानकों को नियंत्रित करना, टीम वर्क को नियंत्रित करना। मेरे लिए, यह सफलता का एक आवश्यक कारक लगता है, और "घर, मीठा घर" भी है।

मेरे 2 सेंट।

Answer 8

AFIAK गतिशील टाइपिंग वाली सभी भाषाओं की व्याख्या की गई भाषाएं हैं। यह पहले से ही बहुत अक्षम है, गतिशील टाइपिंग की अक्षमता को जोड़ने से समय का बड़ा नुकसान नहीं होगा। एक संकलित भाषा, हालांकि, वास्तव में नाम से चीजों का उल्लेख नहीं किया जाएगा जब यह चल रहा है। (.Net प्रतिबिंब या जैसी सुविधाओं के सामयिक उपयोग को छोड़कर - अंतर्निहित भाषा की तुलना में बहुत धीमी गति से।) उन सभी नामों की खोज धीमी, धीमी, धीमी होने जा रही है।

Comments

आप गलत जानते हैं। गतिशील रूप से टाइप की गई भाषाओं के लिए कई कंपाइलर हैं, और उनमें से कुछ काफी तेज़ हैं। उदाहरणों में कॉमन लिस्प, स्कीम और एर्लैंग शामिल हैं।

— रयान क्यूलपेपर

"व्याख्या की गई भाषा" जैसी कोई चीज नहीं है। एक भाषा गणितीय नियमों का एक सार सेट है। एक भाषा को न तो संकलित किया जाता है और न ही उसकी व्याख्या की जाती है। एक भाषा बस है संकलन और व्याख्या कार्यान्वयन के लक्षण हैं, न कि भाषा। प्रत्येक भाषा को दुभाषिया के साथ लागू किया जा सकता है, और हर भाषा को एक संकलक के साथ लागू किया जा सकता है। और बहुत ज्यादा हर भाषा की व्याख्या और संकलित कार्यान्वयन दोनों हैं, उदाहरण के लिए ECMAScript, Ruby और Python के लिए C और कंपाइलर के लिए दुभाषिए हैं।

— जोर्ग डब्ल्यू मित्तग

Answer 9

डायनामिक रूप से टाइप की जाने वाली भाषाओं को अक्सर "ऑब्जेक्ट-ओरिएंटेड" के रूप में जाना जाता है। वो नहीं हैं। वे इनकैप्सुलेशन-ओरिएंटेड हो सकते हैं, लेकिन कभी ऑब्जेक्ट-ओरिएंटेड नहीं। ऑब्जेक्ट ओरिएंटेशन सभी प्रकारों के बारे में है।

"लड़का किराने की दुकान पर अपने भाई की बाइक की सवारी करता है और किराने के सामान से रोटी खाता है।" ऑब्जेक्ट ओरिएंटेशन का उपयोग करके, कोई इस वास्तविक दुनिया के परिदृश्य का वर्णन करने के लिए तुरंत कक्षाओं (प्रकारों) का एक सेट लिख सकता है।

गतिशील रूप से टाइप की गई भाषा में, परिदृश्य को केवल इस प्रकार दर्शाया जा सकता है:

"ऑब्जेक्ट अपने ऑब्जेक्ट को ऑब्जेक्ट पर राइड करता है और ऑब्जेक्ट से ऑब्जेक्ट को खरीदता है"।

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

स्टेटिक टाइपिंग बेहतर कोडिंग दक्षता, पुन: प्रयोज्य और रखरखाव की अनुमति देता है, क्योंकि एकीकृत विकास वातावरण चर के प्रकारों को जानते हैं। चरों के प्रकारों को जानकर, एक IDE स्वतः पूर्णता प्रदान कर सकता है ताकि प्रोग्रामर को यह याद रखने के लिए कक्षा की परिभाषा में वापस न लौटना पड़े कि क्या सदस्य की संपत्ति "backlightControl" या "backLightControl" या "bkLightCtrl" है।

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

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

Comments

मुझे डर है कि मुझे आपके तर्क के पहले भाग पर आपसे असहमत होना पड़ेगा। डायनामिक-टाइप की गई भाषाएं आमतौर पर "ऑब्जेक्ट ओरिएंटेड" होती हैं, लेकिन "क्लास ओरिएंटेड" नहीं। यह एक महत्वपूर्ण अंतर है। आपके उदाहरण में, आप वास्तव में एक भ्रम में जी रहे हैं। आपके पास एक Boyवर्ग हो सकता है , लेकिन मुझे संदेह है कि यह सब कुछ एक वास्तविक दुनिया "लड़का" करता है। हालाँकि, आप गतिशील उदाहरण में (ऑब्जेक्ट सवारी करता है ...), हम इस "लड़के" वस्तु के बारे में एकमात्र महत्वपूर्ण बात जानते हैं - यह सवारी कर सकता है । यह गतिशील प्रकार की भाषाओं का मूल दर्शन है। इसमें + ve s और -ve s है। आपको कौन सा पसंद है, आपकी राय

— चिप