Rob Pike के प्रोग्रामिंग नियम (1989)

 (users.ece.utexas.edu)
2 पॉइंट द्वारा GN⁺ 2023-11-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 1989 में Rob Pike के प्रोग्रामिंग के 5 नियमों पर लेख
  • नियम 1: यह मानकर मत चलो कि प्रोग्राम अपना ज़्यादातर समय कहाँ बिताएगा; bottleneck अप्रत्याशित जगहों पर आ सकते हैं। जब तक bottleneck सिद्ध न हो जाए, speed hack से बचो।
  • नियम 2: speed के लिए tuning करने से पहले हमेशा मापो। केवल तभी optimize करो जब कोड का कोई हिस्सा बाकी हिस्सों पर महत्वपूर्ण प्रभाव डालता हो।
  • नियम 3: जब n छोटा हो, तो जटिल algorithm धीमे होते हैं। अधिकांश मामलों में यही सच है। जटिल algorithm का उपयोग केवल तब करो जब n अक्सर बड़ा हो, और तब भी पहले नियम 2 लागू करो।
  • नियम 4: सरल algorithm और data structure बेहतर होते हैं। वे जटिल चीज़ों की तुलना में bug के प्रति कम संवेदनशील होते हैं और implement करना आसान होता है।
  • नियम 5: सही data structure प्रोग्रामिंग में निर्णायक है। अगर data अच्छी तरह व्यवस्थित है, तो algorithm स्वतः स्पष्ट हो जाएगा।
  • Pike के नियम 1 और 2, Tony Hoare के इस कथन को दर्शाते हैं: "premature optimization सभी बुराइयों की जड़ है।"
  • Ken Thompson ने Pike के नियम 3 और 4 को इस तरह दोबारा कहा: "जब संदेह हो, तो brute force का उपयोग करो।"
  • नियम 3 और 4, KISS (Keep It Simple, Stupid) design philosophy को लागू करते हैं।
  • नियम 5, Fred Brooks की 'The Mythical Man-Month' में कही बात से मेल खाता है, जिसे अक्सर संक्षेप में यूँ कहा जाता है: "smart object का उपयोग करने वाला stupid code लिखो।"

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-11-02
Hacker News की राय
  • 1989 में Rob Pike के programming rules पर एक लेख
  • टिप्पणीकार इस बात से सहमत हैं कि programming का मूल एल्गोरिदम नहीं, बल्कि data structures हैं
  • LeetCode इंटरव्यू algorithms की बजाय data structures पर फोकस नहीं करते, इस बात की आलोचना
  • यह तर्क कि जब n छोटा हो तो जटिल algorithms धीमे होते हैं, और अधिकांश मामलों में n छोटा ही होता है
  • टिप्पणीकार सही data structure चुनने और चीजों को अच्छी तरह व्यवस्थित रखने के महत्व पर ज़ोर देते हैं
  • database के दुरुपयोग और ORM-जनित DB schema के नकारात्मक प्रभाव पर चर्चा
  • ये guidelines over-engineering और समय से पहले optimization से बचाने की रणनीति जैसी लगती हैं
  • कुछ टिप्पणीकारों का कहना है कि performance की छोटी-छोटी बर्बादियां जुड़कर program को धीमा कर सकती हैं
  • "समय से पहले optimization सभी बुराइयों की जड़ है" इस उद्धरण और उसके संदर्भ पर बहस
  • कुछ टिप्पणीकारों का दावा है कि अच्छे programmers पहले से अनुमान लगा सकते हैं कि क्या धीमा पड़ेगा और इस पर पहले से शिक्षाप्रद शर्तें लगा सकते हैं
  • इसके जवाब में यह तर्क कि सरल data पर जटिल algorithms बड़े performance gains ला सकते हैं और कभी-कभी चीजों को और सरल भी बना सकते हैं
  • इस लेख ने कुछ पाठकों के design और complexity के प्रति दृष्टिकोण पर लंबे समय तक प्रभाव डाला
  • नियम 5 की व्याख्या पर चर्चा, "smart objects का इस्तेमाल करने वाला dumb code लिखो" इस वाक्यांश पर कुछ असहमति