गतिशील रूप से बनाम वैधानिक रूप से टाइप की गई भाषा के अध्ययन [बंद]


69

क्या सांख्यिकीय बनाम टाइप की गई भाषाओं की प्रभावशीलता पर किए गए अध्ययन मौजूद हैं?

विशेष रूप से:

  • प्रोग्रामर उत्पादकता के माप
  • त्रुटि की दर

इसके अलावा कि यूनिट टेस्टिंग के प्रभाव हैं या नहीं।

मैंने दोनों पक्षों की खूबियों की चर्चा की है, लेकिन मैं सोच रहा हूं कि क्या किसी ने इस पर कोई अध्ययन किया है।


8
@bigown, यह मुझे नहीं लगता कि उत्पादकता और दोष के मुद्दे कंप्यूटर विज्ञान के सिद्धांत से संबंधित हैं
विंस्टन एवर्ट

2
@ आइंस्टीन: इस तरह के मुद्दों का अध्ययन करना यह कंप्यूटर वैज्ञानिकों का काम है, न कि प्रोग्रामर का।
मनेरियो

9
@bigown, हाँ इसके कंप्यूटर विज्ञान का मुद्दा है लेकिन इसका कंप्यूटर विज्ञान का सिद्धांत नहीं है। सीएस सिद्धांत अनिवार्य रूप से उन चीजों से संबंधित है जो हम गणितीय रूप से कार्यक्रमों और कंप्यूटिंग के बारे में साबित कर सकते हैं। प्रोग्रामर उत्पादकता के मुद्दे सीएस सिद्धांत प्रश्न नहीं हैं। यहां और स्टैकओवरफ्लो दोनों पर गतिशील टाइपिंग की चर्चा हुई है। Cstheory पर कोई नहीं रहा है।
विंस्टन एवर्ट

8
विषय पर पूरी तरह से सवाल। यह प्रश्न उन टूल के सबसे महत्वपूर्ण गुणों पर चर्चा करता है जिनका हम प्रोग्राम में उपयोग करते हैं।
फ्रैंक शियरर

4
@ आइंस्टीन: टाइपिंग सिस्टम सीएस सिद्धांत में हैं, लेकिन व्यावहारिक अध्ययन नहीं करते हैं।
डेविड थॉर्नले

जवाबों:


42

कुछ पढ़ने का सुझाव दिया:

स्थैतिक टाइपिंग पर बिल्कुल नहीं, लेकिन संबंधित:

विषय पर या सामान्य रूप से कार्यक्रमों के स्थैतिक विश्लेषण पर कुछ दिलचस्प लेख या निबंध:

और जो लोग सोच रहे होंगे कि यह सब क्या है:

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

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

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


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

पुन: टूलींग, मेरा कहना है कि यह आपकी भाषा पर निर्भर करता है - स्मॉलटाक में उत्कृष्ट उपकरण हैं, जिसमें रिफ्लेक्टरिंग ब्राउज़र शामिल है जिसे ग्रहण करने के लिए (मुझे बताया गया है) अभी तक पकड़ना है।
फ्रैंक शीयर

@ फ्रेंक शीयर, जब से मैंने रूबी (जावा से आने वाली) के साथ शुरुआत की है, मैंने महसूस किया है कि हेयरस्टाइल का कहना शायद स्मॉलटाक पर लागू नहीं होता है। न ही मेरा मंत्र गतिशील रूप से टाइप किए गए लैंग्स में स्वचालित रीफैक्टरिंग के बारे में असंभव है। मैं पूरी तरह से हेयरस्टाइल के "व्यक्तिगत रूप से" खंड से सहमत हूं। स्मॉलटॉक के पाठ्यक्रम की अनदेखी करना :) यह कुछ हद तक उचित है, क्योंकि स्मॉलकॉम के बाद से, मृत नहीं है, निश्चित रूप से उस लोकप्रियता का आनंद नहीं ले रहा है जो पायथन या रूबी के पास है (अब अक्टूबर 2010 में) )।
डैन रोसेनस्टार्क

3
@haylem, व्यक्तिगत रूप से मैं आपको यह महसूस कराने के लिए धन्यवाद देता हूं कि मैं दुनिया का एकमात्र व्यक्ति नहीं हूं जो गतिशील भाषाओं में काम करता है लेकिन, जब कोई विकल्प दिया जाता है, तो कई बार सांख्यिकीय रूप से टाइप की जाने वाली भाषाएं (एक ही मामला, जावा बनाम JRuby या ग्रूवी)।
डैन रोसेनस्टार्क

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

19

कल ही मैंने यह अध्ययन पाया है: इकाई परीक्षण पर्याप्त नहीं है। आपको स्टैटिक टाइपिंग भी चाहिए।

मूल रूप से लेखक ने एक उपकरण का उपयोग एक गैर-स्थैतिक टाइपिंग भाषा से एक स्थिर टाइपिंग एक (अजगर से हैसेल) में बदलने में सक्षम किया

फिर उन्होंने कई ओपन सोर्स पायथन प्रोजेक्ट्स का चयन किया, जिसमें उचित मात्रा में टेस्ट यूनिट्स भी शामिल थे, और स्वचालित रूप से उन्हें हैसेल में बदल दिया।

हास्केल के अनुवाद में चर के प्रकार से संबंधित त्रुटियों की एक श्रृंखला का पता चला: परीक्षण इकाइयों द्वारा त्रुटियों की खोज नहीं की गई थी।


4
गतिशील टाइपिंग का असुविधाजनक सच।
डेन

6
"हास्केल में अनुवाद में चर के प्रकार से संबंधित त्रुटियों की एक श्रृंखला का पता चला: परीक्षण इकाइयों द्वारा त्रुटियों की खोज नहीं की गई थी।": एक गतिशील रूप से टाइप की गई भाषा के साथ आपको अपने कोड के गुणों को मैन्युअल रूप से परीक्षण करना होगा जो एक सांख्यिकीय रूप से है। संकलित भाषा स्वचालित रूप से संकलक द्वारा जाँच की जाती है। यह अधिक समय लेने वाली और त्रुटि-प्रवण दोनों है। +1
जियोर्जियो

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

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

10
  • स्टीफन हैनबर्ग लेख (पिछले पोस्ट में लोरिन होचस्टीन द्वारा संदर्भित) एसीएम पेपर " स्टेटिक एंड डायनामिक टाइप सिस्टम्स के बारे में एक प्रयोग " (2010) की चर्चा से जुड़ा हुआ है।
  • निष्कर्ष: गतिशील भाषा में समान गुणवत्ता के लिए उत्पादकता अधिक थी।
  • संभावित पक्षपात / वैधता के मुद्दे: प्रायोगिक विषय सभी छात्र थे। इसके अलावा, प्रोग्रामिंग कार्यों की सीमित विविधता (विषयों को एक स्कैनर और पार्सर को लागू करने के लिए कहा गया था)।
  • एसीएम पेपर " क्या प्रोग्रामिंग भाषाएं उत्पादकता को प्रभावित करती हैं? " (2007) डेलोरे, नूडसन और चुन द्वारा।
  • निष्कर्ष: C # C ++ और Java की तुलना में JavaScript, Tcl, Perl अधिक उत्पादक है। अजगर और PHP बीच में आते हैं।
  • संभावित पक्षपात / वैधता के मुद्दे: गुणवत्ता का कोई माप नहीं (जैसे कि बग की खोज के बाद रिलीज)। विश्वसनीयता का कोई माप नहीं है (क्या सॉफ्टवेयर टाइप की गई भाषाओं में अधिक भरोसेमंद है?) नमूना पूर्वाग्रह - सभी परियोजनाओं को खुले स्रोत सीवीएस रिपॉजिटरी से लिया गया था। इसके अलावा, कमजोर और दृढ़ता से टाइप की गई भाषाओं (यानी संकेत) के बीच कोई अंतर नहीं है।
  • थीसिस " सॉफ्टवेयर उत्पादकता और गुणवत्ता का अनुभवजन्य अध्ययन " (2008) माइकल एफ Siok द्वारा
  • निष्कर्ष: प्रोग्रामिंग भाषा की पसंद उत्पादकता या गुणवत्ता को महत्वपूर्ण रूप से प्रभावित नहीं करती है। हालांकि, यह श्रम लागत और "समग्र सॉफ्टवेयर प्रोजेक्ट पोर्टफोलियो के भीतर गुणवत्ता" को प्रभावित करता है।
  • संभावित पक्षपात / वैधता के मुद्दे: एवियोनिक्स डोमेन के लिए प्रतिबंधित। प्रोग्रामिंग भाषाओं को सभी सांख्यिकीय रूप से टाइप किया जा सकता था। मैंने थीसिस नहीं पढ़ी, इसलिए मैं इसकी कठोरता का मूल्यांकन नहीं कर सकता।
    मेरी राय। यद्यपि कमजोर सबूत हैं कि गतिशील रूप से टाइप की गई भाषाएं अधिक उत्पादक हैं, यह निर्णायक नहीं है। (1) कई कारक हैं जिन्हें नियंत्रित नहीं किया गया था, (2) बहुत कम अध्ययन हैं, (3) उपयुक्त परीक्षण पद्धति का गठन करने के बारे में बहुत कम या कोई चर्चा नहीं हुई है।

6

यहाँ एक प्रारंभिक बिंदु है:

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


5
गैर-आईईईई लोगों के लिए, मूल सारांश क्या है?
फ्रैंक शियरर

1
@ फ्रेंक शीयर, वे निष्कर्ष निकालते हैं कि प्रोग्रामिंग भाषा उत्पादकता को प्रभावित करती है। वे प्रति वर्ष प्रति प्रोग्रामर प्रति भाषा कोड की लाइनों को माप रहे हैं, मुझे यकीन नहीं है कि उत्पादकता का एक अच्छा उपाय है।
विंस्टन एवर्ट

3
@Winston: यह निश्चित रूप से एक त्रुटिपूर्ण मीट्रिक है। आपको लगता है कि COBOL को इसके द्वारा एक बहुत ही उत्पादक भाषा मिलेगी: कुछ भी उपयोगी करने के लिए बहुत सारी लाइनें लगती हैं, लेकिन वे लिखने में काफी आसान हैं।
डेविड थोर्नले

विंस्टन, डेविड: मुझे पूरा यकीन है कि लेखक यह सुझाव नहीं दे रहे हैं कि लाइनें-ऑफ-कोड उत्पादकता कार्यात्मक उत्पादकता का एक उपाय है । बल्कि, कागज आमतौर पर प्राप्त ज्ञान को चुनौती दे रहा है कि, बाकी सभी समान हैं, प्रोग्रामर भाषा की परवाह किए बिना प्रति बार कोड की समान पंक्तियों को लिखते हैं। दूसरे शब्दों में, पेपर को अनुभवजन्य साक्ष्य का समर्थन करते हुए काम करना चाहिए कि यांत्रिक उत्पादकता (कोड की पंक्तियाँ) कार्यात्मक उत्पादकता का एक अच्छा उपाय नहीं है, और इसे कम से कम भाषा द्वारा सामान्यीकृत किया जाना चाहिए।
Pi Delport

मैं इस से सहमत हूँ। लेकिन यह मेरे मूल प्रश्न का उत्तर देने के लिए काम नहीं करता है।
विंस्टन एवर्ट

1

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

यहाँ कार्यकारी सारांश है:

नियंत्रित प्रयोगों में से, केवल तीन ही एक प्रभाव दिखाते हैं जो किसी भी व्यावहारिक महत्व के लिए पर्याप्त है। C, C ++, Java, Perl, Python, Rexx, और Tcl की तुलना में Prechelt अध्ययन; जावा और डार्ट की तुलना करते हुए एंड्रीकैट अध्ययन; और वीएचडीएल और वेरिलोग के साथ कोलेलि का प्रयोग। दुर्भाग्य से, वे सभी मुद्दे हैं जो वास्तव में एक मजबूत निष्कर्ष निकालना मुश्किल बनाते हैं।

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

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

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

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

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

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

मैंने पाया 0 केस केस स्टडी (जो कि विभिन्न भाषाओं की तुलना पायथन से की गई और अंततः Ocaml पर बसी) में से एक और दिलचस्प चीज़ थी, जो कि मुझे भा गई, लेकिन यह व्यक्तिपरक बात है कि हर कोई अलग तरह से व्याख्या करेगा, जिसे आप देख सकते हैं ।

यह मेरे पास मौजूद धारणा के साथ फिट बैठता है (दुनिया के मेरे छोटे से कोने में, ACL2, इसाबेल / HOL, और PVS सबसे अधिक उपयोग किए जाने वाले उत्तेजक हैं, और यह समझ में आता है कि लोग उद्योग में समस्याओं को हल करते समय अधिक स्वचालन पसंद करेंगे), लेकिन यह है कि व्यक्तिपरक भी।

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

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

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

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


0

मैं ईमानदारी से नहीं सोचता कि स्टैटिक बनाम डायनामिक टाइपिंग असली सवाल है।

मुझे लगता है कि दो पैरामीटर हैं जो पहले आने चाहिए:

  • भाषा में विशेषज्ञता का स्तर: जितना अधिक आप अनुभव करते हैं, उतना ही आप "गोचैट्स" के बारे में जानते हैं और जितना संभव हो आप उनसे बचने / उन्हें आसानी से ट्रैक करने के लिए। यह उस विशेष एप्लिकेशन / प्रोग्राम के बारे में भी सच है जिस पर आप काम कर रहे हैं
  • परीक्षण: मुझे स्टैटिक टाइपिंग बहुत पसंद है (नरक मुझे C ++: p में प्रोग्रामिंग पसंद है) लेकिन वहाँ सिर्फ इतना है कि एक संकलक / स्थैतिक विश्लेषक आपके लिए क्या कर सकता है। बिना जांचे-परखे किसी कार्यक्रम के बारे में आश्वस्त होना असंभव है। और मैं फजी परीक्षण (जब लागू हो) के लिए सभी हूं, क्योंकि आप बस सभी संभावित इनपुट संयोजनों के बारे में नहीं सोच सकते।

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

यदि आप डिकोड्ड कोड लिखते हैं, और प्रत्येक कार्यक्षमता का बड़े पैमाने पर परीक्षण करते हैं, तो आप अच्छी तरह से सम्मानित कोड का उत्पादन करेंगे, और इस प्रकार आप उत्पादक होंगे (क्योंकि आप उत्पाद की गुणवत्ता का आकलन नहीं करते हैं, तो क्या आप उत्पाद की गुणवत्ता का आकलन नहीं कर सकते हैं? )

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


2
यदि यह प्रति-प्रश्न है, तो इसमें प्रश्न कहां है? :) मैं मानता हूं कि अन्य कारक अधिक महत्वपूर्ण हैं फिर स्थिर बनाम गतिशील टाइपिंग। हालाँकि, डायनेमिक टाइपिंग अधिवक्ता बेहतर उत्पादकता का दावा करते हैं और स्टैटिक टाइपिंग अधिवक्ता बेहतर कोड गुणवत्ता का दावा करते हैं। मैं सोच रहा था कि क्या किसी के पास अपने दावों का समर्थन करने के लिए वास्तविक सबूत हैं।
विंस्टन एवर्ट

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

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

0

यहाँ कुछ है:

  • स्टीफन हैनबर्ग। 2010. स्थिर और गतिशील प्रकार प्रणालियों के बारे में एक प्रयोग: विकास के समय पर स्थिर प्रकार प्रणालियों के सकारात्मक प्रभाव के बारे में संदेह। ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग सिस्टम लैंग्वेजेस और एप्लिकेशन (OOPSLA '10) पर ACM अंतर्राष्ट्रीय सम्मेलन की कार्यवाही में। एसीएम, न्यूयॉर्क, एनवाई, यूएसए, 22-35। DOI = 10.1145 / 1869459.1869462 http://doi.acm.org/10.1145/1869459.1869462

  • डैनियल पी। डेलोरेय, चार्ल्स डी। नॉटसन, स्कॉट चुन, "क्या प्रोग्रामिंग भाषाएं उत्पादकता को प्रभावित करती हैं? ओपन सोर्स प्रोजेक्ट्स के डेटा का उपयोग करने वाला एक केस स्टडी", floss, pp.8, FLOSS अनुसंधान और विकास में उभरते रुझान पर पहली अंतर्राष्ट्रीय कार्यशाला (FLOSS) '07: आईसीएसई वर्कशॉप 2007), 2007

  • डेली, एम।; सज़ावल, वी।, फोस्टर, जे।: प्रोग्रेस में काम: रूबी में स्टेटिक टाइपिंग का एक अनुभवजन्य अध्ययन, ऑन-वॉर्ड 2009 में प्रोग्रामिंग लैंग्वेज एंड टूल्स (PLATEAU) की मूल्यांकन और उपयोगिता की कार्यशाला।

  • लुत्ज प्रेचल और वाल्टर एफ। टिची। 1998. प्रक्रिया नियंत्रण लाभ जाँच के लाभ का आकलन करने के लिए एक नियंत्रित प्रयोग। IEEE ट्रांस। Softw। अभियांत्रिकी। 24, 4 (अप्रैल 1998), 302-312। DOI = 10.1109 / 32.677186 http://dx.doi.org/10.1109/32.677186

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