प्रोग्रामिंग के बारे में आपका पसंदीदा उद्धरण क्या है? [बन्द है]


जवाबों:


231

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

- ब्रायन डब्ल्यू। कर्निघन


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

6
अन्यथा सच कहावत की एक वाहवाही: मत भूलो कि एक आरेख आपके मस्तिष्क की शक्ति को बढ़ा सकता है। आप "बड़ी बात की याद रखने वाली संरचना" को गैर-वाजिब कागज पर स्वैप कर सकते हैं।
टिम विस्क्रॉफ्ट

1
मैं उद्धरण से प्यार करता हूं लेकिन इसका निहितार्थ यह है कि हमें अपने प्रयास का 50% भाग पहली बार कोडिंग में लगाना चाहिए।
जॉन हॉपकिंस

4
मुझे लगता है कि निहितार्थ यह है कि आपको उस प्रोग्रामर के आग्रह से बचना चाहिए कि वह कुछ करने के लिए 'चतुर' तरीके का उपयोग कर सकता है, जब थोड़ा लंबा, अधिक स्पष्ट तरीका कुछ ठीक काम करता है।
फिशटोस्टर

2
लेकिन क्या होगा अगर यह "सही" कोड है? "डीबग" करने का कोई तरीका नहीं है।
मतीन उलूक

183

पानी पर चलना और एक विनिर्देशन से सॉफ्टवेयर विकसित करना आसान है अगर दोनों जमे हुए हैं।

- एडवर्ड वी बेरार्ड


वर्ष का उद्धरण, मैं इसे एक का उपयोग करने जा रहा हूं
गॉर्ट्रन

मुझे इससे नफरत है। यह कभी ऐसा नहीं है, इसलिए कौन परवाह करता है?
जेपी अलीोटो

138

यह हमेशा आपकी अपेक्षा से अधिक समय लेता है, तब भी जब आप हॉफस्टैटर के नियम को ध्यान में रखते हैं।
  - हॉफस्टेडर्स लॉ


72
ब्रेन स्टैक ओवरफ्लो।
नाथन टेलर

3
@ जो डी: मैं उत्सुक हूं कि आप एक एकल गैर-पुनरावर्ती वाक्य में एक पुनरावर्ती अंग्रेजी वाक्य कैसे लिखेंगे ।
जॉन प्यूडी

4
यह "छोटे" के पर्याप्त छोटे मूल्यों के लिए अभिसरण हो सकता है
म्यूविसिल

3
+1 - मुझे डगलस हॉफ़स्टैटर के साथ शीर्ष अरब प्रोग्रामर में खुद को गिनने पर गर्व है।
पीटर टर्नर

@gf: जब यह स्रोत को बाद में परिभाषित करने में (एक डैश के साथ) रूपांतरित हो जाता है, तो अग्रणी परिचय को वारंट नहीं किया जाता ("A: Blah।" -> "Blah। - A")। यह उद्धरण का हिस्सा नहीं निकाल रहा है।

126

हमेशा इस तरह से कोड करें जैसे कि आपका कोड बनाए रखने वाला आदमी एक हिंसक मनोरोगी होगा जो जानता है कि आप कहां रहते हैं।

- रिक ओसबोर्न


12
ऐसा लगता है कि मैं कोड को बनाए रखना चाहता हूं कि मैं चाहता हूं कि मुझे पता था कि निर्माता कहां रहता था, लेकिन शायद यह एक अच्छी चीज है जो मैं नहीं करता।
WalterJ89

"किलर ऐप" शब्द का नया अर्थ लाता है। मुझे लगता है कि अंत में मनोरोगी के कोड को बनाए रखने के बाद वह हमेशा परेशान रहता है।
वेबबिडीव

8
@webbiedave आप ReiserFS पर काम करते हैं? :)
नील एटकन

यदि हत्यारे को आपकी नौकरी मिल गई तो कंपनी को वास्तव में आपसे घृणा करनी चाहिए।
मतीन उलूक

118

आपके पास परियोजना हो सकती है:

  • समय पर किया गया
  • बजट पर किया गया
  • ठीक से किया

दो चुनें।

- अनजान



5
मुझे एक समान त्रिकोण की याद दिलाता है, लेकिन महिलाओं के साथ। "आपकी एक प्रेमिका हो सकती है: स्मार्ट है, आकर्षक है, एक अच्छा व्यक्तित्व है।"
अधिकतम दोपहर

यह मत भूलो कि अपवाद मौजूद हैं, हालांकि वे दुर्लभ हैं - इस पर भरोसा मत करो।
मिरिकिया चीरा

5
@Maxpm: मैंने सुना संस्करण "द 4 एस का: स्मार्ट, सेक्सी, साने, सिंगल। पिक 3." है।
मेसन व्हीलर

1
इसलिए, जब समय और बजट में कोई अड़चन नहीं है तो आप इसे ठीक से नहीं कर सकते। जानकार अच्छा लगा।
अंटसन

111

कुछ लोग, जब एक समस्या का सामना करते हैं, तो सोचते हैं "मुझे पता है, मैं नियमित अभिव्यक्ति का उपयोग करूंगा।"
अब उन्हें दो समस्याएं हैं।

- जेमी ज़विंस्की


5
एक कालातीत क्लासिक
फैक्टर मिस्टिक

5
कुछ लोग, जब किसी समस्या का सामना करते हैं, तो सोचते हैं "मुझे पता है, मैं <कुछ समस्या को लागू करने का उपयोग करूंगा।" अब उन्हें दो समस्याएं हैं।
कैलम रोजर्स

40
कुछ लोगों को जब एक समस्या का सामना करना पड़ता है, तो वे सिर्फ StackOverflow पर पोस्ट नहीं करते हैं
मैट एलेन

5
कुछ लोग नियमित अभिव्यक्तियों को नहीं समझते हैं, और उनसे नफरत करते हैं क्योंकि अन्य करते हैं।
परिक्रमा

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

110

सिद्धांत रूप में, सिद्धांत और व्यवहार में कोई अंतर नहीं है। लेकिन, असलियत में, होता है।

- जन ला वैन डे स्नेसेचुट


27
मैंने यह भी सुना है "सिद्धांत और व्यवहार के बीच का अंतर सिद्धांत में अभ्यास की तुलना में छोटा है।"

1
रोजर पाटे का सूत्रीकरण मैंने सुना है, जिसे ओलिन शॉवर्स ने "हिस्ट्री ऑफ़ टी" में लिखा है। पॉल ग्राहम यहाँ इसके बारे में बात करते हैं: paulgraham.com/thist.html
माइकल एच।

2
मैं कहूंगा कि यदि कोई सिद्धांत अभ्यास करने के लिए अनुवाद नहीं करता है, तो सिद्धांत बस अधूरा है।
री मियाँसाक

105

आप निर्माण स्थल पर प्रारूपण तालिका या स्लेजहेमर पर एक इरेज़र का उपयोग कर सकते हैं - फ्रैंक लॉयड राइट

बिल्कुल नहीं एक प्रोग्रामिंग उद्धरण लेकिन यह सबसे निश्चित रूप से लागू होता है।


14
अत्यधिक लागू IMO
जॉन मैकइंटायर

3
सौभाग्य से हमारे लिए जब अधिकांश सॉफ्टवेयर गलत हो जाता है तो यह लोगों को नहीं गिराता और मार देता है।
नील ऐतकेन

8
सिवाय इसके कि जब वह एरियन 5 (फ्लाइट 501) को उड़ाता है, या विकिरण के उच्च स्तर वाले लोगों को खुराक देता है ...
फ्रैंक शियरर

2
विडंबना यह है कि मेरा मानना ​​है कि फ्रैंक लॉयड राइट के कई और अधिक भवन जर्जर हो चुके हैं।
मैक्सएम 5

1
@TomWij, @Walter, @Roger: कृपया अपने साइट से इस साइट को गंदा करने से बचना चाहिए। अगर मैं मनमुटाव सुनना चाहता हूं, तो मैं meta.stackoverflow.com पर जाऊंगा। यह वह जगह है जहाँ आपको यह आकर्षक और कालातीत वार्तालाप होना चाहिए।
डैन रोसेनस्टार्क

103

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

- रिक कुक


98

कोड की लाइनों द्वारा प्रोग्रामिंग प्रगति को मापना वजन द्वारा विमान निर्माण प्रगति को मापने के समान है।
  - बिल गेट्स



3
यह कई स्तरों पर सच है। एक रत्न।

3
निश्चित रूप से महत्वपूर्ण अंतर यह है कि विमान का अंतिम भार ज्ञात है जबकि सॉफ्टवेयर का अंतिम LOC काउंट अज्ञात है।
मिमी

5
तो अधिकांश Microsoft उत्पाद मुझे यह एहसास क्यों देते हैं कि मैं अपने हवाई जहाज से जंजीर से जकड़ा हुआ हूँ जो कि रनवे से उतरने के लिए संघर्ष कर रहा है?
शार्पी

86

कंप्यूटर विज्ञान में 2 कठिन समस्याएं हैं: कैश अमान्य होना, नामकरण की चीजें और ऑफ-बाय -1 त्रुटियां।

    - लियोन बम्ब्रिक (@ secretGeek )

(वास्तव में, http://q4td.blogspot.com/search/label/programming से सब कुछ जैसे मैं सूची को क्यूरेट करता हूं।)


मैंने कभी भी एक उद्धरण बिंदु नहीं देखा है कि नामकरण की चीजें कितनी कठिन हो सकती हैं। मैं अचानक एकजुटता महसूस करता हूं।
कोडेक्सआर्कनम

वह 3 चीजें हैं। पहले दो फिल कार्लटन के मूल उद्धरण हैं। @CodexArcanum। चीजों को अच्छी तरह से नाम देना चाल है।
स्टुपरयूजर

@StuperUser जोश! तुम मजाक याद किया!
अगोस

दो सेकंड लगे कि आप के बाद कि बाहर बताया। हर्प डर्प।
19

85

एक महीने में नौ लोग बच्चा नहीं बना सकते।
  - फ्रेड ब्रूक्स, द माइथिकल मैन-मंथ


14
तकनीकी रूप से: 18 लोग एक महीने में एक बच्चा नहीं बना सकते हैं
यहाँ

13
@ हेरेब्वेल्स या 10
वाल्टरजॉ।

14
1 आदमी और 8 महिलाओं के साथ क्या गलत है? मेरे बारे में सिर्फ सही लगता है।

4
यदि हम जुड़वाँ या ट्रिपल के लिए जाते हैं तो हमें कम महिलाओं की आवश्यकता होती है।

12
जबकि पहला बच्चा 9 महीने की विलंबता का सामना करेगा, उचित पाइपलाइनिंग प्रति माह 1 वितरित करना जारी रखेगा ...
ब्रायन नॉबलुच

82

हमें छोटी क्षमताओं के बारे में भूलना चाहिए , समय के 97% के बारे में कहना चाहिए : समय से पहले अनुकूलन सभी बुराई की जड़ है। फिर भी हमें उस महत्वपूर्ण 3% में अपने अवसरों को पारित नहीं करना चाहिए।
  - डोनाल्ड नुथ, स्ट्रक्चर्ड प्रोग्रामिंग टू स्टेट्स गो, जेएसीएम कम्प्यूटिंग सर्वे, खंड 6, संख्या 4, दिसंबर 1974, पृष्ठ 242

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

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

फिर भी हमें उस महत्वपूर्ण 3% में अपने अवसरों को पारित नहीं करना चाहिए। एक अच्छे प्रोग्रामर को इस तरह के तर्क से शालीनता में नहीं लिया जाएगा, वह महत्वपूर्ण कोड को ध्यान से देखने के लिए बुद्धिमान होगा; लेकिन उसके बाद ही कोड की पहचान की गई है। यह अक्सर एक गलती है कि किसी प्रोग्राम के कौन से हिस्से वास्तव में महत्वपूर्ण हैं, इस बारे में एक प्राथमिकता निर्णय लेने के लिए, क्योंकि माप उपकरणों का उपयोग करने वाले प्रोग्रामर का सार्वभौमिक अनुभव रहा है कि उनके सहज अनुमान विफल हो जाते हैं। (...)


2
@ रॉजर पटे: मुझे संदेह है कि आप सही हैं, अधिकांश लोगों को यह महसूस नहीं होता है कि बोली अधिक है।
स्कॉट डोरमैन

5
आशा है कि आप बुरा नहीं मानेंगे कि मैंने थोड़ा और शामिल किया। मुझे लगता है कि यह वास्तव में महत्वपूर्ण है और शायद इससे पूरा पेपर पढ़ने के लिए और अधिक प्रोत्साहन मिलेगा। :)

@ रॉगर पाटे: बिलकुल नहीं!
स्कॉट डोरमैन

5
+1 पूर्ण उद्धरण के लिए धन्यवाद। मुझे कभी नहीं पता था कि इसमें कुछ और था।
इवान प्लाइस

2
यह बहुत अच्छा है कि आपने पूरी बोली पोस्ट की। बहुत से लोग केवल सॉर्ट संस्करण को जानते हैं और पता नहीं है कि वास्तव में नथ का मतलब क्या है।
डेसिच

80

डिबगर बग को दूर नहीं करते हैं। वे केवल उन्हें धीमी गति में दिखाते हैं।

- अनजान


35
या कई मामलों में, उन्हें पूरी तरह से दिखाई देना बंद कर दें।
ग्रीम पेरो

12
@Graeme उन मामलों को हाइजेनबग्स कहा जाता है :)
यहाँ

76

कोड का पहला 90% विकास के समय का पहला 90% होता है। शेष 10% कोड में अन्य 90% विकास समय होता है।

- टॉम कारगिल


किसने कहा कि मूल रूप से?
Paddyslacker

10
मुझे लगता है कि आप पाएंगे कि ९ ०% कोड ९ ०% समय लेता है, और अंतिम १०% कोड अन्य ९ ०% समय लेता है।
FacticiusVir

2
बेल लेबोरेटरीज के टॉम कारगिल: en.wikipedia.org/wiki/Ninety-ninety_rule
बिल कार्विन

1
मुझे यह पता है: 20% साथी 80% बीयर पीते हैं।
ज़ेज़

1
व्यक्तिगत रूप से, मैं कहूंगा कि विकास के समय के पहले 90% के लिए पहले 90% कोड खाते हैं। फिर, शेष 90% कोड विकास के समय के अन्य 90% के लिए जिम्मेदार है।
काज ड्रैगन

70

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


22
मजाकिया, बस मुझे php के बारे में सोचा।
WalterJ89

2
@ WalterJ89: चिंता नहीं! PHP 5.3 तक, PHP को refcounted किया जाता है।
zneak

मैं यह पसंद है!
एमडीवी २२

@ WalterJ89 खैर, मुझे जावा को COBOL, C ++, VB, या अन्य के विपरीत एकल करने का कोई कारण नहीं दिखता है।
मार्क सी

69

कंप्यूटर विज्ञान दूरबीनों के बारे में खगोल विज्ञान से अधिक कंप्यूटर के बारे में नहीं है

- एद्गर दिक्स्ट्रा


4
हाँ, लेकिन यह कंप्यूटर विज्ञान नहीं, बल्कि प्रोग्रामिंग के बारे में माना जाता है । [धूर्त मुसकान]
मार्क सी

प्रोग्रामिंग केवल कंप्यूटर विज्ञान के साथ इकट्ठा किए गए ज्ञान को लागू करना है। आपको प्रोग्राम करने के लिए कंप्यूटर की आवश्यकता नहीं है, कम से कम एक ऐसा नहीं है जिससे अधिकांश परिचित हैं।
डेसिच

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

57

अगर डिबगिंग सॉफ्टवेयर बग हटाने की प्रक्रिया है, तो प्रोग्रामिंग उन्हें अंदर डालने की प्रक्रिया होनी चाहिए।
  - Edsger डिज्कस्ट्रा


24
इसलिए मैं अपनी नौकरी को एनबगिंग के रूप में संदर्भित करना पसंद करता हूं
deceze

9
और रिबगिंग के रूप में रखरखाव ?
जो डी

1
@ जोड नो, "बगवाचिंग"।
मार्क सी

56

केवल दो प्रकार की भाषाएं हैं: वे लोग जिनके बारे में शिकायत करते हैं और जिनका कोई उपयोग नहीं करता है

- ब्रजने स्ट्रॉस्ट्रुप


15
के लिए सी ++ suckage बुरा बहाना
hasen

3
C # एक स्पष्ट प्रति-उदाहरण है।
टिमवी

7
और VB दोनों श्रेणियों में आता है।
क्विक जो स्मिथ

48

एक बूलियन के बारे में सबसे अच्छी बात यह है कि अगर आप गलत हैं, तो आप केवल एक बिट से दूर हैं। - (बेनामी)


सबसे बुरी बात यह है कि आप अधिक गलत नहीं हो सकते हैं?
POSIX_ME_HARDER

46

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

तर्कपूर्ण रूप से बेवकूफ उपयोगकर्ता प्रश्नों का सामना करने वाले प्रोग्रामर का पहला प्रलेखित मामला।


5
एक टी-शर्ट की तरह लगता है! "उपयोगकर्ता त्रुटि: 1832 के बाद से चीजों को गड़बड़ाना"। (तारीख?)
मार्क सी।

42

मैंने हमेशा अपने कंप्यूटर के लिए अपने टेलीफोन के रूप में उपयोग करने में आसान होने की कामना की है; मेरी इच्छा पूरी हो गई है क्योंकि मैं अब यह पता नहीं लगा सकता कि मेरे टेलीफोन का उपयोग कैसे किया जाए

- ब्रजने स्ट्रॉस्ट्रुप



39

यूनिकोड समर्थन एक "सुविधा" नहीं है। यह अपेक्षित व्यवहार है।

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


3
अब आपको केवल इस बात पर बहस करनी है कि
मार्टिन बेकेट

@ मॉर्टिन: वास्तव में नहीं, क्योंकि विभिन्न प्रकारों के बीच रूपांतरण दोषरहित है।
बिली ओनली

आरग दर्द! मुझे एक ग्राहक के साथ बहस क्यों करनी है कि नहीं, हम "सिर्फ" अपने पूरे बुनियादी ढांचे को लेटिन -1 पर स्विच नहीं कर सकते हैं ताकि यह उसके लिए असीम रूप से सुविधाजनक हो सके? "आखिर, यहाँ कोई भी उन अजीब विशेष पात्रों का उपयोग नहीं करता, इतना कठिन नहीं है, है ना?"
पिस्कवर

39

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

- रयान कैंपबेल


1
मेह ... मेरे जीवन में आई अधिकांश टिप्पणियों को इस धारणा के तहत लिखा गया है कि टिप्पणियाँ खराब लिखित कोड के लिए बना सकती हैं ..
riwalk

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

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

2
मुझे टिप्पणियाँ लिखने में भी मज़ा आता है, लेकिन आप मेरा बाथरूम नहीं देखना चाहेंगे।
टिमवी

मैं एक बार एक वॉशरूम में था, जहां वास्‍तविक रूप से लंबी-चौड़ी टिप्‍पणियां थीं कि आपको वाशरूम को कैसे और क्‍यों साफ रखना चाहिए। यह साफ नहीं था।
री मियासका

38

मुर्ख चमत्कार करता है, बुद्धिमान व्यक्ति पूछता है।
  - बेंजामिन डिसरायली



@TomWij: जब मैंने इसे संपादित किया तो मेरी टिप्पणी देखें, इन उद्धरणों को अलग-अलग उत्तरों में विभाजित किया गया है।

35

प्रोग्रामिंग सेक्स की तरह है: एक गलती और आपको इसे अपने जीवन के बाकी हिस्सों के लिए समर्थन करना होगा।
  - माइकल सिंज


34

Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher।
  - एंटोनी डे सेंट-एक्सुप्री, फ्रेंच लेखक (1900-1944), टेरे दे होम्स (1939)

(ऐसा प्रतीत होता है कि पूर्णता तब प्राप्त होती है जब जोड़ने के लिए कुछ भी नहीं बचता है, लेकिन जब लेने के लिए कुछ नहीं बचता है।)


और यह संगीत के लिए भी मान्य है
हेनज जेड।


2
@ डेविड केंडल: अच्छा! इसी तरह, हेनरी डेविड थोरो ने कहा, "सरलीकरण, सरलीकरण।" जो मुझे हमेशा लगता है, "सरलीकृत करें।"
बिल करविन

33

जावा को जावास्क्रिप्ट के रूप में कार के लिए कार है।
  - क्रिस हेइल्मन


मेरी कार में कालीन है, इसलिए जावा में जावास्क्रिप्ट है?
कीयो

1
@ कीयो: हाँ, मैंने सोचा था कि इस पर ले लो। मुझे अभी भी लगता है कि बोली वास्तव में चतुर है।
बिल कार्विन

31

जैसा कि एरिक एस। रेमंड द्वारा तैयार किया गया है :

लिनस का नियम

एक बड़े पर्याप्त बीटा-टेस्टर और सह-डेवलपर आधार को देखते हुए, लगभग हर समस्या को जल्दी और किसी को स्पष्ट करने की विशेषता होगी।

या, कम औपचारिक रूप से,

पर्याप्त नेत्रगोलक को देखते हुए, सभी बग उथले हैं।


बंदर / टाइपराइटर नियम मुझे थोड़ा सा लगता है ...
सीन पैट्रिक फ्लोयड

लिनक्स उत्साही लोग बग्स को ठीक करने की तुलना में इस उद्धरण को दोहराने में अधिक समय क्यों लगते हैं?
टिमवी

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