बतख-टाइपिंग बनाम स्थैतिक टाइपिंग के कुछ फायदे क्या हैं?

Question

मैं ग्रोवी के साथ और अधिक शोध कर रहा हूं और मैं ग्रोवी में चीजों को लागू करने के पेशेवरों और विपक्ष के चारों ओर अपने दिमाग को लपेटने की कोशिश कर रहा हूं कि मैं जावा में नहीं कर सकता/सकती हूं। गतिशील प्रोग्रामिंग अभी भी मेरे लिए एक अवधारणा है क्योंकि मैं गहराई से स्थिर और दृढ़ता से टाइप की गई भाषाओं को खड़ा कर रहा हूं।

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

मैं इस सवाल को ग्रोवी के साथ दिमाग में पूछता हूं लेकिन मुझे समझ में आता है कि यह एक ग्रोवी प्रश्न नहीं है, इसलिए मैं प्रत्येक कोड शिविर से जवाब का स्वागत करता हूं।

Answer 1

अगला, जो बेहतर है: ईएमएसीएस या वीआई? यह चल रहे धार्मिक युद्धों में से एक है।

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

ऐसा नहीं है कि गतिशील टाइपिंग एक नई और अलग बात है: उदाहरण के लिए, प्रभावी रूप से गतिशील रूप से टाइप किया गया है, क्योंकि मैं हमेशा foo* को bar* पर डाल सकता हूं। इसका मतलब यह है कि यह मेरी ज़िम्मेदारी है क्योंकि सी प्रोग्रामर कभी भी bar* पर उपयुक्त कोड का उपयोग नहीं करता है जब पता वास्तव में foo* पर इंगित कर रहा है। लेकिन बड़े कार्यक्रमों के साथ मुद्दों के परिणामस्वरूप, सी ने लिंट (1) जैसे उपकरणों को बढ़ाया, typedef के साथ अपनी टाइप सिस्टम को मजबूत किया और अंत में सी ++ में दृढ़ता से टाइप किए गए संस्करण को विकसित किया। (और, ज़ाहिर है, सी ++ ने बदले में मजबूत टाइपिंग के आसपास तरीकों का विकास किया, जिसमें सभी प्रकार की किस्में और जेनेरिक/टेम्पलेट्स और आरटीटीआई के साथ।

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

Answer 2

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

Answer 3

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

Answer 4

@Chris गुच्छा

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

क्षमा करें, लेकिन मैं यह करने के लिए ...

Answer 5

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

जावा में "map" के रूप में इतना आसान उपयोग करने की कल्पना कीजिए (और नहीं, मेरा मतलब the data structure नहीं है)। यहां तक ​​कि जेनेरिक भी खराब समर्थित हैं।

Answer 6

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

class SimpleResults { 
    def results 
    def total 
    def categories 
} 

जहां results पता चला है Map<String, List<ComplexType>> की तरह कुछ है, जो विधि कॉल का एक निशान का पालन करके ही खोज की जा सकती है:

मेरा सबसे हाल ही पसंदीदा तर्क बतख टाइपिंग के खिलाफ एक Grails परियोजना डीटीओ से आता है विभिन्न वर्गों में जब तक आप पाते हैं कि यह कहां बनाया गया था। टर्मिनली उत्सुक के लिए, totalList<ComplexType> और categories के आकारों का योग के आकार है Map

यह मूल डेवलपर के लिए स्पष्ट हो सकता है, लेकिन खराब रखरखाव पुरुष (ME) का एक बहुत खो दिया है बाल इसे नीचे ट्रैक कर रहे हैं।

Answer 7

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

class SimpleResults { 
    def mapOfListResults 
    def total 
    def categories 
} 

के नामित कुछ संचालन पर एक अनुबंध को परिभाषित मान लीजिए 'calculateRating (ए, बी)' जहां ए और बी एक और अनुबंध का पालन करना। स्यूडोकोड में, यह लिखा होगा:

Long calculateRating(A someObj, B, otherObj) { 

    //some fake algorithm here: 
    if(someObj.doStuff('foo') > otherObj.doStuff('bar')) return someObj.calcRating()); 
    else return otherObj.calcRating(); 

} 

आप जावा में इस लागू करने के लिए चाहते हैं, दोनों ए और बी है कि कुछ इस तरह पढ़ता इंटरफेस किसी तरह लागू करना चाहिए:,

public interface MyService { 
    public int doStuff(String input); 
} 

इसके अलावा अगर आप रेटिंग्स की गणना के लिए आप अनुबंध सामान्यीकरण करने के लिए चाहते हैं (मान लीजिए कि आप रेटिंग की गणना के लिए एक और कलन विधि डालते हैं), तो आप भी एक इंटरफेस बनाने के लिए:

public long calculateRating(MyService A, MyServiceB); 

बतख टाइपिंग के साथ

, आप कर सकते हैं घ अपने इंटरफेस और बस रनटाइम पर भरोसा करें, ए और बी दोनों आपके doStuff() कॉल पर सही ढंग से प्रतिक्रिया देंगे। एक विशिष्ट अनुबंध परिभाषा की कोई आवश्यकता नहीं है। यह आपके लिए काम कर सकता है लेकिन यह आपके खिलाफ भी काम कर सकता है।

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

ध्यान दें कि यह जावा में विशेष रूप से बढ़ता है, जहां वाक्यविन्यास उतना ही नहीं है जितना यह हो सकता है (उदाहरण के लिए Scala की तुलना में)। इसका एक उदाहरण उदाहरण Lift framework है, जहां वे कहते हैं कि ढांचे की एसएलओसी गिनती Rails के समान है, लेकिन परीक्षण कोड में कम लाइनें हैं क्योंकि उन्हें परीक्षणों में टाइप चेक लागू करने की आवश्यकता नहीं है।

Answer 8

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

ग्रोवी मेरे जैसा ही लगता है। निश्चित रूप से आप बहुत संक्षिप्त कोड लिख सकते हैं और निश्चित रूप से कुछ अच्छी चीनी है कि हम संपत्तियों, संग्रहों आदि के साथ कैसे काम करते हैं ... लेकिन यह जानने की लागत कि बिल्ली को आगे और आगे क्यों पारित किया जा रहा है, यह बदतर और बदतर हो जाता है। किसी बिंदु पर आप अपने सिर को खरोंच करते हुए सोचते हैं कि क्यों परियोजना 80% परीक्षण और 20% काम बन गई है। यहां सबक यह है कि "छोटा" "अधिक पठनीय" कोड के लिए नहीं बनाता है। क्षमा करें दोस्तों, इसका सरल तर्क - जितना अधिक आपको सहजता से जानना होगा, उस कोड को समझने की प्रक्रिया को और अधिक जटिल बनाना होगा। यही कारण है कि जीयूआई ने पिछले कुछ वर्षों में अत्यधिक प्रतिष्ठित बनने का समर्थन किया है - निश्चित रूप से सुंदर दिखता है लेकिन डब्लूटीएच चल रहा है हमेशा स्पष्ट नहीं है।

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

ग्रोवी के साथ काम करने वाली एक चीज़ ने मेरे लिए किया है - भयानक बिलकुल घंटे घूमते हैं!

Answer 9

यहां एक परिदृश्य है जहां बतख टाइपिंग काम बचाती है।

यहाँ इकाई परीक्षण के लिए अब

class BookFinder { 
    def searchEngine 

    def findBookByTitle(String title) { 
     return searchEngine.find([ "Title" : title ]) 
    } 
} 

एक बहुत ही तुच्छ वर्ग है:

void bookFinderTest() { 
    // with Expando we can 'fake' any object at runtime. 
    // alternatively you could write a MockSearchEngine class. 
    def mockSearchEngine = new Expando() 
    mockSearchEngine.find = { 
     return new Book("Heart of Darkness","Joseph Conrad") 
    } 

    def bf = new BookFinder() 
    bf.searchEngine = mockSearchEngine 
    def book = bf.findBookByTitle("Heart of Darkness") 
    assert(book.author == "Joseph Conrad" 
} 

हम स्थिर प्रकार की जाँच की अनुपस्थिति के कारण, searchengine के लिए एक expando स्थानापन्न करने में सक्षम थे। स्थैतिक प्रकार की जांच के साथ हमें यह सुनिश्चित करना होगा कि सर्चइंजिन एक इंटरफेस था, या कम से कम एक अमूर्त वर्ग था, और इसका एक पूर्ण नकली कार्यान्वयन तैयार करता था। वह श्रम गहन है, या आप एक परिष्कृत एकल उद्देश्य मॉकिंग ढांचे का उपयोग कर सकते हैं। लेकिन बतख टाइपिंग सामान्य उद्देश्य है, और हमें मदद मिली है।

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

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

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

Answer 10

मेरी राय:

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

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

Answer 11

साथ, टीडीडी + 100% कोड कवरेज + आईडीई उपकरण लगातार मेरे परीक्षण चलाने के लिए, मुझे स्थिर टाइपिंग की आवश्यकता महसूस नहीं होती है। कोई मजबूत प्रकार के साथ, मेरा यूनिट परीक्षण इतना आसान हो गया है (बस नकली वस्तुओं को बनाने के लिए मानचित्र का उपयोग करें)।

//Static typing 
Map<String,List<Class1<Class2>>> someMap = [:] as HashMap<String,List<Class1<Class2>>> 

बनाम

//Dynamic typing 
def someMap = [:]