किस प्रोग्रामिंग लैंग्वेज में सबसे मुश्किल से मुश्किल कीड़े मिलते हैं? [बन्द है]

54

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

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

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

संपादित करें: हार्ड-टू-बग बग का पूरी तरह से मनमाना स्पष्टीकरण: पुन: पेश करने के लिए 15 मिनट से अधिक समय लेता है, या 1 घंटे से अधिक का समय लगता है।

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

— मैग्नस वोल्फेल्ट को दर्शाता है
स्रोत

10

मैं इस विषय में किए गए कुछ शोध देखना चाहता हूँ! न केवल "मेरे वास्तविक सबूत से पता चलता है कि एकमात्र भाषा जिसे मैं जानता हूं वह राजा है" लेकिन बड़ी परियोजनाओं से बग दर, और इसी तरह।

— फ्रैंक शियरर

@Frank .. अगर आपके पास A LOT (और I mean A LOT) समय है, तो आप शायद ओह्लॉह से बाहर कुछ आँकड़ों को माइन कर सकते हैं, बशर्ते कि आप हजारों कोड रिपोजिटरीज़ से उस फिक्स्ड बग्स की पहचान कर सकें।

— टिम पोस्ट

वह जहां केवल टिप्पणियों की अनुमति है। कोई अन्य निर्देश नहीं :)

— विक्टर हर्डुगासी

4

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

— विंस्टन इर्वर्ट

@ आइंस्टीन सहमत।

— मैग्नस वोल्फेल्ट

58

भाषा के प्रकार की प्रणाली जितनी अधिक शक्तिशाली होगी, संकलन समय पर उतने ही अधिक कीड़े पकड़े जाएंगे।

निम्न आकृति कुछ प्रसिद्ध प्रोग्रामिंग भाषाओं की तुलना उनके प्रकार के सिस्टम की शक्ति, सादगी और सुरक्षा के संदर्भ में करती है। [ स्रोत ]

वैकल्पिक शब्द

* असुरक्षित निर्माणों का उपयोग करने की क्षमता में फैक्टरिंग।

"असुरक्षित" कीवर्ड और संबद्ध पॉइंटर मशीनरी के कारण C # असुरक्षित पंक्ति में भर जाता है। लेकिन अगर आप इन के बारे में सोचना चाहते हैं तो एक तरह का इनलाइन विदेशी फंक्शन मैकेनिज्म सी # स्काईवर्ड को टक्कर देने के लिए स्वतंत्र है।

मैंने हास्केल '98 को शुद्ध लेकिन जीएचसी हास्केल के रूप में चिह्नित किया है जो कि असुरक्षित * कार्यों के परिवार के कारण शुद्ध नहीं है। यदि आप असुरक्षित * को अक्षम करते हैं, तो उसी के अनुसार जीएचसी हास्केल को कूदें।

— मिसिंगफैक्टर
स्रोत

8

ये जबरदस्त है!

7

मुझे ग्राफिक में कॉमन लिस्प नहीं मिला: (let ((itbe '())) ... )...

— duros

7

क्या? PHP के लिए बाईं ओर कोई स्थान नहीं बचा था?

— प्रेस्ता

7

सी # सुरक्षित बिंदुओं की अनुमति देता है : सभी सूचक अंकगणित की जाँच की जाती है। इसलिए, मेरा मानना है कि यह जावा के साथ होना चाहिए।

— एलेक्स दस ब्रिंक

11

@missingfaktor: मुझे लगता है कि C # अच्छी तरह से तैनात नहीं है। सी # अनुमति देता है और बाद में प्रोग्रामिंग शैलियों को बढ़ावा देता है। इसे सबसे खराब चीज से नहीं मापा जाना चाहिए।

— बैक

20

मेरी राय में हास्केल आपको त्रुटियों के कुछ सामान्य स्रोतों से बचने में मदद करता है:

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

— LennyProgrammers
स्रोत

11

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

— मेसन व्हीलर 12

5

कई अच्छे बिंदु, लेकिन त्रुटि के कुछ वर्गों को हटाते समय (अनपेक्षित दुष्प्रभाव, अप्रत्याशित प्रकार के रूपांतरण) हास्केल त्रुटि की एक पूरी नई श्रेणी जोड़ता है: अंतरिक्ष लीक। (हालांकि null, वहाँ कोई नहीं है , वहाँ है undefined, जो हर प्रकार का एक सदस्य है।)

— j_random_hacker

5

@ मेसन: यदि आप इसे नहीं लिखते हैं, तो आपके पास बग नहीं हो सकते हैं :)

— माइकल के

2

मुझे लगता है कि मुफ्त भोजन के रूप में ऐसी कोई चीज नहीं है - आपके पास आसानी से मिल सकने वाले कीड़े, या आसानी से लिखने वाला कोड हो सकता है, लेकिन दोनों नहीं :)

— बेंजोल

6

@ मेसन वास्तव में एक "औसत प्रोग्रामर" क्या है? सवाल "क्या प्रोग्रामिंग भाषा ..." के साथ शुरू होता है, "जो सी, सी ++ और जावा के बीच नहीं है ...";)

— अगोस डे

18

परंपरागत रूप से कीड़े खोजने के लिए सबसे कठिन बहु-थ्रेडेड अनुप्रयोगों में दौड़ की स्थिति है जैसा कि वे हैं

प्रजनन करना लगभग असंभव है
बहुत सूक्ष्म हो सकता है

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

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

संपादित करें: जावा Executorsमें हार्ड भागों के और भी अधिक भाग। आपको व्यक्तिगत कार्यों को Callableइंटरफ़ेस के अनुरूप बनाने की आवश्यकता है ।

— उपयोगकर्ता 1249 को प्रकट करता है
स्रोत

5

++ दौड़ की स्थिति। आप इसे दोबारा कह सकते हैं।

— माइक डनलैवी

हाँ। यह ध्यान रखें कि सामान्य रूप से समानांतर कंप्यूटिंग कठिन है, भाषा सहायता के साथ भी। (आम लिस्प मैक्रोज़ कठिन हैं, भाषा समर्थन के बावजूद, क्योंकि वे जो करते हैं वह बहुत शक्तिशाली है। समान प्रिंसिपल।)

— डेविड थॉर्नले

एर्लांग के बारे में क्या?

— मालफिस्ट

@ मालफिस्ट, मुझे जवाब देने के लिए एर्लैंग के बारे में पर्याप्त जानकारी नहीं है। शायद आपको एक सवाल खोलना चाहिए यदि आप वास्तव में जानना चाहते हैं?

2

एरलंग एक कार्यात्मक प्रोग्रामिंग है जिसे मल्टीथ्रेडिंग को सरल और सुरक्षित बनाने के लिए डिज़ाइन किया गया है। आप चर साझा नहीं करते हैं, आप संदेश पास करते हैं। इसे विकिपीडिया पृष्ठ पढ़ें।

— मलफिस्ट

13

Ada को इसलिए डिज़ाइन किया गया है ताकि रन-टाइम के बजाय जितना संभव हो सके संकलन-समय पर पकड़ा जाए। इसका मतलब यह है कि अक्सर जावा में कहे जाने वाले समतुल्य की तुलना में एडा में एक कार्यक्रम प्राप्त करने में लगभग 10 गुना अधिक समय लगता है, लेकिन जब यह संकलन करता है तो आप बहुत अधिक आश्वस्त हो सकते हैं कि कार्यक्रम के होने पर बग के पूरे वर्ग खुद को प्रकट नहीं करेंगे। Daud।

— मार्क पिम
स्रोत

7

+1 सूचना के लिए, सही ढंग से, कि Ada कंपाइलर में उन चीजों को पकड़ता है जिन्हें अन्य भाषाएं अनदेखा करती हैं। -1 का अर्थ है कि इसका मतलब यह है कि संकलन करने के लिए एक Ada कार्यक्रम प्राप्त करने में 10x लंबा समय लगता है। Ada प्रोग्रामर को पुरस्कृत करता है जो DESIGNS !!! उसका कोड, जो सोचता है !!! पागल टाइपिंग शुरू करने से पहले वह क्या कर रहा है। मेरा व्यक्तिगत अनुभव, रक्षा कार्य के लिए एडीए में प्रोडक्शन प्रोग्रामिंग करना, यह था कि एड कोड को सी / सी ++ या फोरट्रान की तुलना में संकलन करने में अधिक समय नहीं लगता था, लेकिन बाद में एडीए कोड को काफी कम परेशानी हुई। प्रैट एंड व्हिटनी ने कुछ ऐसा ही देखा।

— जॉन आर। स्ट्रोह डे

1

@ जॉन आर स्ट्रॉह, जो मैं समझता हूं, वह कोड संकलित करने के लिए समय के बारे में बात नहीं कर रहा है, बल्कि कोड को संकलित करने का समय है।

— मालफिस्ट

ओह कोड को संकलित करने के बारे में सहमत हुए। मुझे प्रोग्रामर द्वारा उसके नाइट पिकिंग के बारे में भाषा सीखने के लिए किए गए बहुत सारे सेक्सिस्ट कमेंट्स याद हैं। आम तौर पर वेल की तर्ज पर, यदि आप किसी महिला के बाद एक भाषा का नाम रखते हैं ...

— माइकल शॉ

@Ptolemy, अगर नावों को महिलाओं के नाम पर रखा जा सकता है (जाहिरा तौर पर अमेरिकी वाहक को छोड़कर) तो प्रोग्रामिंग लैंग्वेज भी हो सकती हैं। बल्कि इसे "USS रोनाल्ड रीगन" :) की तुलना में "Ada" नाम दिया है

1

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

— जेम्स एडम

7

पहली परिभाषा: एक मुश्किल-से-ढूंढा हुआ बग, जैसा कि मैं समझता हूं, यह एक बग है जिसे फिर से बनाया जा सकता है लेकिन इसका कारण ढूंढना मुश्किल है।

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

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

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

यह पहले से ही मेरी सूची को पूरा करता है; अन्य चीजें जैसे मजबूत टाइपिंग से कम समय में बग को पकड़ने में मदद मिलती है, लेकिन बाद में उन बग्स को ढूंढना मुश्किल नहीं होगा।

वह सब देखते हुए, मैं कहूंगा कि जावा और C #, और JVM और .net दुनिया में कई अन्य भाषाएं, हार्ड-टू-फाइंड बग्स से बचने के लिए उपयुक्त हैं।

— user281377
स्रोत

मैनुअल लॉकिंग एक "आसान करने के लिए उपयोग तुल्यकालन तंत्र" हो सकता है, लेकिन यह वास्तव में केवल "उपयोग करने के लिए सरल है, लेकिन आप मज़ाक के समय में हैं क्योंकि आप उस गतिरोध का पीछा करते हैं"। और, ठीक है, आप काफी कुछ भाषाओं में अभिनेता-आधारित संगामिति कर सकते हैं।

— फ्रैंक शियरर

फ्रैंक: कम से कम लॉकिंग काफी सरल है, इसलिए हर कोई इसे बिना खर्च किए दिन बिता सकता है, पता लगा सकता है कि किस एपीआई का उपयोग करना है आदि

— user281377

फिर एक दृष्टिकोण यह है कि एक संगामिति समाधान जो "इतना सरल है कि हर कोई इसे कर सकता है" पूर्व-शालाओं को टेबल आरी देने जैसा है।

— डेविड थॉर्नले

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

— user281377

+1 इस परिभाषा के लिए "कितना बड़ा स्कोप है जो बग संभावित रूप से प्रभावित कर सकता है"। मेरे पास गतिशील भाषाओं के साथ कुछ बहुत ही खराब कीड़े थे जहां गलत डेटा प्रकार की एक वस्तु को बग के रूप में खुद को प्रकट करने से पहले कोड (डैक टाइपिंग के लिए धन्यवाद) में बहुत दूर मिला।

— जियोर्जियो

7

चूंकि एक्सेल सबसे ज्यादा इस्तेमाल किया जाने वाला डीएसएल है, इसलिए मैं एक्सेल के साथ जाऊंगा। (पाठ्यक्रम के VBA को छोड़कर)

यह बिल फिट बैठता है:

यह हमेशा पुन: पेश करना आसान है (यहां एक स्प्रेडशीट है - यह काम नहीं कर रहा है)
बग को ढूंढना बहुत आसान है, क्योंकि यह पूरी तरह से "कार्यात्मक" है - उस सेल से शुरू करें जो गलत है और इसके सभी निर्भरता का पता लगाता है।

— स्कॉट व्हिटलॉक
स्रोत

यह तब तक सही हो सकता है जब तक आप आसानी से खोजे जाने वाले बग को नहीं जोड़ते।

— मौवीसील

+1 एक्सेल के बाद से थोड़ा सा चुटीला है, भाषा नहीं। मुझे एक अच्छी हँसी दे दी :)

— recursion.ninja

2

@ वाशबर्न - ओह, मुझे नहीं पता। मुझे लगता है कि यह एक भाषा के रूप में योग्य है। प्रत्येक कोशिका एक "चर" है। प्रत्येक चर को घोषणात्मक रूप से या तो एक शाब्दिक (जैसे कि 123या ABC) या एक फ़ंक्शन ( =SUM(A2:A5)) के रूप में सेट किया जाता है । Excel तब सभी चर का मूल्यांकन करता है, यह पता लगाता है कि निर्भरता को हल करने के लिए क्या आदेश है, आदि। यह निश्चित रूप से केवल डेटा नहीं है।

— स्कॉट व्हिटलॉक

2

मैं अपने बयान को वापस लेता हूं, यह पता चला है कि एक्सेल ट्यूरिंग कम्प्लीट है ... मैंने पूरी तरह से अनिश्चितता से कुछ सीखा ...

— recursion.ninja

1

"... सच [लिस्प] मास्टर को पता चलता है कि सभी डेटा कोड है।" शायद यह एक्सेल पर भी लागू होता है, पर्याप्त रूप से पर्याप्त है। blogs.msdn.com/b/sriram/archive/2006/01/15/lisp-is-sin.aspx

— James Mishra

7

यह एक कठिन सवाल है क्योंकि अधिकांश बग भाषा की गलती नहीं है - बल्कि वे डेवलपर्स की गलती है कि वे भाषा का उपयोग कैसे करते हैं।

मेरा मानना है कि भाषा सुविधाओं के कई पहलू हैं जो बग की संभावना को प्रभावित करते हैं:

अन्तरक्रियाशीलता - REPLs के साथ गतिशील भाषाएं चल रहे कार्यक्रमों और बहुत छोटे कोड / परीक्षण चक्रों के साथ बातचीत / प्रयोग को प्रोत्साहित करती हैं। यदि आप मानते हैं कि पुनरावृत्ति स्वच्छ सरल समाधानों की खोज करने और बग्स का पता लगाने / समाप्त करने का एक अच्छा तरीका है, तो यह इंटरैक्टिव भाषाओं का पक्ष लेगा।
स्पष्टता - यदि कोड कम है और इसमें बॉयलरप्लेट / आकस्मिक जटिलता कम है, तो बग / तर्क त्रुटियों को देखना आसान है।
टाइप सेफ्टी - अधिक संकलित समय की जाँच, संकलक द्वारा अधिक कीड़े पकड़े जाएंगे इसलिए सामान्य प्रकार की सुरक्षा एक अच्छी बात है। हालाँकि ये आमतौर पर बग ढूंढना मुश्किल नहीं होता है - पूरी तरह से गतिशील भाषा में भी डेटा संरचना में गलत प्रकार आमतौर पर एक बहुत ही स्पष्ट रनटाइम त्रुटि का कारण होगा, और टीडीडी लगभग हमेशा इस तरह के कीड़े उठाता है।
अपरिहार्यता - उत्परिवर्ती राज्य की जटिल बातचीत के कारण बहुत सारे कठिन कीड़े होते हैं। अपरिवर्तनीयता पर जोर देने वाली भाषाओं (हास्केल, क्लीजुर, एरलैंग) को पारस्परिक योग्यता से भारी फायदा होता है
कार्यात्मक प्रोग्रामिंग - कोड लिखने के लिए कार्यात्मक दृष्टिकोण प्रभाव / इंटरैक्शन के जटिल अनुक्रमों के साथ ऑब्जेक्ट ओरिएंटेड कोड की तुलना में अधिक "सही रूप से सही" होते हैं। मेरा अनुभव है कि एफपी मुश्किल कीड़ों से बचने में मदद करता है - मेरा मानना है कि कहीं न कहीं कुछ अकादमिक शोध है जो मुझे वर्तमान में नहीं मिल सकता है।
कंसीडर सपोर्ट - कंसीडर प्रॉब्लम का पता लगाना और डीबग करना विशेष रूप से कठिन है, यही कारण है कि यह इतना महत्वपूर्ण है। जो कुछ भी मैनुअल लॉकिंग की आवश्यकता होती है, वह अंततः विफल होने के लिए बर्बाद हो जाती है (और इसमें समसामयिक दृष्टिकोण के लिए हर वस्तु उन्मुख दृष्टिकोण शामिल है)। इस संबंध में मुझे पता है कि सर्वश्रेष्ठ भाषा क्लोजर है - इसमें संगामिति का प्रबंधन करने के लिए एक अनूठा तरीका है जो एक उपन्यास, विश्वसनीय और रचना योग्य संगामिति ढांचे को प्राप्त करने के लिए अपरिवर्तनीय डेटा संरचनाओं के साथ सॉफ्टवेयर ट्रांस्क्लेशनल मेमोरी को जोड़ती है। अधिक जानकारी के लिए http://www.infoq.com/pretations/Value-Identity-State-Rich-Hickey देखें

— मिकेरा
स्रोत

मेरे जैसे लोग जो कार्यात्मक प्रोग्रामिंग के भावुक समर्थक हैं, इस उत्तर की सराहना करते हैं। अभिव्यक्ति आपके मित्र हैं।

— श्रीधर सरनोबत

1

अब तक का सबसे अच्छा जवाब! मुझे लगता है कि यह बग आवृत्ति के दो विश्लेषणों द्वारा समर्थित है: जानबूझकर- software.com/safety-rank-part-2 और macbeth.cs.ucdavis.edu/lang_study.pdf । वे दोनों दिखाते हैं कि शुद्ध, अधिक कार्यात्मक, अधिक अभिव्यंजक और सुरक्षित भाषा जितनी कम बग है। इसी तरह, वे दोनों दिखाते हैं कि क्लूजुर और रूबी सेफ्टी रूल से बचते हैं, शायद यह संकेत करते हैं कि इंटरएक्टिविटी का एक समान प्रभाव पड़ता है जैसा आपने बताया।

— डिडियर ए।

@DidierA। दुर्भाग्य से ucdavis लिंक टूट गया है (कोई wbm आर्काइव के साथ) - मुझे लगता है कि आपको यह प्रेम देवनबू के पेज से मिला है जो अब एक अद्यतन लिंक की ओर इशारा करता है: जीथब में एक बड़े पैमाने पर प्रोग्रामिंग भाषाओं और कोड की गुणवत्ता का अध्ययन

— icc97

5

भाषा जितनी कम शक्तिशाली होती है, उतने ही कम विकल्प आपको अपना पैर मारने के लिए देते हैं।

जावा और C # जैसी उच्च-स्तरीय भाषाएँ C ++ जैसी निम्न-स्तरीय भाषाओं की तुलना में कम बग उत्पन्न करेंगी।

यह कहते हुए कि मेरा मानना है कि जावा C # से अधिक सुरक्षित है। जावा कृत्रिम रूप से सीमित है ताकि उन्नत ज्ञान के बिना एक औसत प्रोग्रामर इसे मास्टर कर सके और स्थिर कार्यक्रम तैयार कर सके।

— उपयोगकर्ता 8686 को प्रकट करता है
स्रोत

4

+1 के लिए "जितनी कम शक्तिशाली भाषा होती है, उतने ही कम विकल्प आपको अपना पैर मारने के लिए उकसाते हैं।"

— माइकल के

अनुपस्थित डेफिनेशन से चार्ट को लगता है कि C # और C ++ समान रूप से "फ़ुटिंग" पर हैं जहाँ तक खुद को शूट करने में सक्षम होने के नाते और ऊपर जावा को ऊपर उठाता है। ऐसा नहीं है कि मैं चार्ट के उस हिस्से से सहमत हूं, हालांकि। आपको कुछ सी # शूटिंग करने के लिए हुप्स से गुजरने के लिए मजबूर किया जाता है।

— जेसी सी। स्लाइसर

6

सुरक्षा और शक्ति विपरीत रूप से आनुपातिक नहीं हैं (जो कि आपको लगता है कि ;-) हास्केल, उदाहरण के लिए, बहुत शक्तिशाली है और अभी तक पैर में खुद को गोली मारने के बहुत कम तरीके हैं।

— 14

3

यदि भाषा कमजोर है, तो आपको बस एक बड़ा पैर चाहिए।

7

@ मिस्सिंगफैक्टर, ऐसा इसलिए है क्योंकि पैर में खुद को गोली मारना एक साइड इफेक्ट है।

3

आपकी राय में, किस भाषा ने औसत प्रोग्रामर को कम से कम हार्ड-टू-फाइ बग के साथ आउटपुट सुविधाओं की अनुमति देता है?

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

मजबूत टाइपिंग और एक सख्त संकलक जो कई सामान्य त्रुटियों को पकड़ता है।
सहज वाक्यविन्यास जो सामान्य त्रुटियों को प्रोत्साहित नहीं करता है। ("द वर्ल्ड्स लास्ट बग," if (alert = RED) {LaunchNukes;}, उदाहरण के लिए, संकलन नहीं करेगा।)
एक अच्छी तरह से डिज़ाइन किया गया ऑब्जेक्ट मॉडल जो कई सामान्य C ++ OOP त्रुटियों को समाप्त करता है।
सीमा की जाँच और सीमा भाषा में निर्मित, सुरक्षा समस्याओं की संभावना को काफी कम कर देता है।
शायद सबसे तेजी से संकलित आदमी के लिए जाना जाता है, जो आपकी उत्पादकता को बढ़ाता है और एक बिल्ड पर इंतजार करते हुए अपनी विचारधारा को खोने के लिए कठिन बना देता है।
डीबगर विज़ुअल स्टूडियो का डीबगर बड़ा होने पर वैसा होना चाहता है।
मेमोरी मैनेजर में सीधे लीकेज ट्रैकिंग बनाया गया है, जिससे मेमोरी लीक को खोजा जा सके और ठीक किया जा सके।
अपने स्वयं के, संभवतः छोटी गाड़ी के कार्यान्वयन के बिना सामान्य कार्यों को पूरा करने के लिए पूर्वनिर्मित और पूर्व-परीक्षण तरीके प्रदान करने वाला एक बड़ा, परिपक्व मानक पुस्तकालय।
समस्याओं को आसान बनाने के लिए उपयोगी उपकरणों जैसे शक्तिशाली लॉगिंग सिस्टम और एक प्रोफाइलर के साथ जहाज।
सामान्य पुस्तकालय के लिए मजबूत समुदाय समर्थन, जो मानक पुस्तकालय में नहीं हैं, जिसमें एक शक्तिशाली तृतीय-पक्ष संगामिति पुस्तकालय भी शामिल है ।

— मेसन व्हीलर को दर्शाता है
स्रोत

मैं रास्ते से एक डेल्फी जॉकी हूं, लेकिन यह पास्कल जड़ों से दूर चला गया जब इसने मुझे कुछ भी करने के लिए टाइपकास्ट करने की अनुमति दी, एक ला सी / सी ++:var I: Integer; Pointer(I)^ := $00;

— जेसी सी। स्लाइसर

1

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

— मेसन व्हीलर

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

— जेसी सी। स्लीकर

1

@ जेसे: पास्कल के मूल वर्थ संस्करण को वेरिएंट रिकॉर्ड की अनुमति नहीं दी गई? IIRC वे अंततः मजबूत टाइपिंग को हटाने के लिए आमतौर पर इस्तेमाल किया जाता है कि बोरलैंड और अन्य ने इसे सरल बनाने के लिए सिर्फ टाइपकास्ट करने का फैसला किया क्योंकि हर कोई इसे वैसे भी कर रहा था।

— मेसन व्हीलर

en.wikipedia.org/wiki/Pascal_(programming_language)#Divisions और en.wikipedia.org/wiki/Pascal_(programming_language)#Criticism साथ ही pascal-central.com/ppl/chapter3.html यह संकेत देता है कि यह इंगित करने के लिए प्रतीत होता है। 1983 में पहला मानक। मैं Wirth द्वारा कुछ संदर्भों को देखता हूं, जो 1974 की तारीख के लिए प्रतीत होते हैं, इसलिए मैं कहूंगा कि यह हां किया। मुझे लगता है कि समस्याग्रस्त भाग इसे इस तरह के रूप में परिवर्तित करने की अनुमति दे रहा था (iethe वैरिएंट फ़ील्ड एक ही मेमोरी ले रहा है, जैसे सी में यूनियनों)। यदि वे बस एक स्कूपिंग तंत्र के रूप में उपयोग किए गए थे और मेमोरी लेआउट सुपरसेट के लिए थे, तो यह अधिक मजबूत टाइप किया जाएगा।

— जेसी सी। स्लाइसर

2

एक बात को ध्यान में रखना समय की बारी है।

पिछले पांच वर्षों से, मैंने मुख्य रूप से जावा (JSF, सीम, आदि) में वेब एप्लिकेशन विकसित किए हैं। हाल ही में मुझे एक नई नौकरी मिली है, और हम पर्ल (कैटलिस्ट और मूस के साथ) का उपयोग कर रहे हैं।

मैं पर्ल में अधिक उत्पादक हूं, मैं जावा में था।

संकलन और (गर्म) तैनात करने की आवश्यकता नहीं है, एक कारण है। मुझे यह भी पता है कि उपयोग के मामलों को लिखना आसान है, क्योंकि इसे अधिक पुनरावृत्त तरीके से किया जा सकता है। और जावा में रूपरेखाएं अनावश्यक रूप से जटिल लगती हैं, कम से कम उन परियोजनाओं के लिए जो मैं इसमें शामिल हूं।

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

— SLU
स्रोत

1

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

— vpit3833
स्रोत

1

"हार्डवेयर के पहनने और आंसू के आसपास काम करते हैं क्योंकि यह उम्र है" ...?

— j_random_hacker

मैंने पढ़ा है कि मिशन के महत्वपूर्ण मशीनों पर चलने वाले कुछ यूनिक्स ओएस सीपीयू, रैम और ऐसे अन्य हार्डवेयर के स्वास्थ्य की जांच करते हैं। serverfault.com/questions/56192/… इस बारे में कुछ गहराई से चर्चा करता है। यदि रैम मॉड्यूल में कुछ लाइनें समय के साथ दोषपूर्ण हो जाती हैं, तो उन दोषपूर्ण मॉड्यूल का उपयोग ओएस द्वारा नहीं किया जाएगा और यह उन्हें उपलब्ध कुल भौतिक मेमोरी में रिपोर्ट नहीं करेगा। इस तरह की चीजें दूसरे हार्डवेयर पर भी की जा सकती हैं।

— vpit3833 19

यह एक दिलचस्प tidbit है, लेकिन मैं नहीं देखता कि यह यहाँ कैसे प्रासंगिक है। आपके लिंक में भी कुछ भी इन सेल्फ रिपेयरिंग यूनिक्स ओएस का उल्लेख नहीं करता है - यह सिर्फ पीसी के हार्डवेयर को तनाव-परीक्षण करने के तरीकों के बारे में बात करता है।

— j_random_hacker 6

1

मैंने इसका मतलब यह बताया कि कार्यक्रम अकेले बग के स्रोत नहीं हो सकते हैं, यह हार्डवेयर या अन्य बाहरी कारक भी हो सकते हैं।

— vpit3833

1

भाषाओं के बारे में बात करने के बजाय भाषा-सुविधाओं के बारे में क्या बात करें

जावा आपको अपवादों (थ्रो ...) के बारे में सोचने के लिए मजबूर करता है और आपको या तो पबल्किस होना चाहिए या इन अपवादों को संभालना चाहिए। क्या यह वास्तव में मुझे त्रुटियों को भूलने से रोकता है या क्या मैं ऐसे अधिक अपवादों का उपयोग कर रहा हूं जो SystemException से प्राप्त हुए हैं जिन्हें इस हैंडलिंग की आवश्यकता नहीं है?
"अनुबंध द्वारा डिजाइन" के बारे में क्या है (http://en.wikipedia.org/wiki/Design_by_contract) जो मुझे पूर्व और पोस्टकंडिशन के बारे में सोचने के लिए मजबूर करता है। मैंने पढ़ा है कि अब c # -4.0 के साथ संभव है।

— k3b
स्रोत