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

• नियम 1: यह अनुमान नहीं लगाया जा सकता कि प्रोग्राम अपना समय कहाँ खर्च करेगा। bottleneck अक्सर अप्रत्याशित जगहों पर आते हैं, इसलिए जब तक वास्तव में यह साबित न हो जाए कि वही bottleneck है, तब तक speed सुधारने की कोशिश न करें
• नियम 2: measurement पहले। speed tuning केवल measurement के बाद करें, और optimization पर तभी विचार करें जब code का कोई एक हिस्सा पूरे सिस्टम पर हावी हो
• नियम 3: जटिल algorithms छोटे n पर धीमे होते हैं। जटिल algorithms में बड़े constants होते हैं, इसलिए जब तक n अक्सर बड़ा न हो, सरल तरीका अपनाएँ। n बड़ा हो तब भी पहले नियम 2 लागू करें
• नियम 4: जटिल algorithms में bugs ज़्यादा होते हैं और उन्हें implement करना कठिन होता है। सरल algorithms और सरल data structures का उपयोग करना बेहतर है
• नियम 5: data ही मुख्य है। सही data structure चुनकर और उसे अच्छी तरह व्यवस्थित करके, algorithm लगभग अपने-आप स्पष्ट हो जाता है। प्रोग्रामिंग का केंद्र algorithms नहीं, बल्कि data structures हैं

संबंधित दर्शन और उद्धरण

• नियम 1 और 2, Tony Hoare के “premature optimization is the root of all evil” वाले कथन के समान अर्थ रखते हैं
• Ken Thompson ने नियम 3 और 4 को “संदेह हो तो सरल तरीका (Brute Force) अपनाओ” के रूप में पुनर्व्याख्यायित किया
• नियम 3 और 4, KISS (Keep It Simple, Stupid) design philosophy के उदाहरण हैं
• नियम 5 का उल्लेख Fred Brooks ने पहले ही 『The Mythical Man-Month』 में किया था,
  और इसे अक्सर “smart objects का उपयोग करके simple code लिखो” के रूप में संक्षेपित किया जाता है

[GN⁺]

Hacker News की राय

• इससे Jonathan Blow की talk याद आ गई
  उन्होंने productivity के नज़रिए से बात की थी। Braid के शुरुआती development में उन्होंने लगभग हर चीज़ को simple array के रूप में implement किया, और केवल bottleneck आने पर ही बदला
  “speed या memory से भी ज़्यादा महत्वपूर्ण है, एक program को implement करने में लगने वाला ज़िंदगी का समय” — यह बात खास लगी

  • games में बहुत सारे मिलते-जुलते objects को प्रति सेकंड 60 frames या उससे अधिक पर बार-बार process करना पड़ता है, इसलिए simple array-based structure एक reasonable default है
  • game development में 16ms के भीतर frame render करना होता है, इसलिए fixed-size tables और linear search आम pattern हैं। यह dynamic allocation की unpredictability से बचने के लिए किया गया structural choice है
  • यह नज़रिया games के बाहर के सामान्य development पर भी लागू होता है। हम सब deadlines और cost constraints के भीतर काम करते हैं, इसलिए engineering time खुद एक cost है
  • फिर भी games की सीख को सामान्य programming पर ज्यों का त्यों लागू करते समय सावधानी रखनी चाहिए। games में reuse से अधिक special-purpose code केंद्र में होता है, जबकि सामान्य software ज़्यादा data-centric होता है
  • मेरे मामले में मैं array की जगह hash map से शुरुआत करने वाला type हूँ

• अगर Rule 1 को सच में स्वीकार कर लिया जाए, तो Rule 3~5 स्वाभाविक रूप से पीछे-पीछे आते हैं
  जब यह मान लेते हैं कि bottleneck का अनुमान नहीं लगाया जा सकता, तो simple code लिखना और measure करना ही एकमात्र तर्कसंगत strategy बन जाती है
  असल में सबसे आम विफलता early optimization नहीं, बल्कि early abstraction होती है। ज़रूरत न होने वाली flexibility के लिए complex layers बना दी जाती हैं, और वही maintenance cost बढ़ा देती हैं

  • “abstraction स्वाभाविक रूप से उभरनी चाहिए, उसे पहले से design नहीं करना चाहिए” — यह बात मैं team के भीतर अक्सर quote करता हूँ
  • early abstraction developer time बर्बाद करती है, technical debt बढ़ाती है, और bugs की संभावना भी बढ़ाती है। अक्सर यह ‘भविष्य की समस्याओं की तैयारी’ के नाम पर पैदा होती है
  • संबंधित paper के रूप में Philip Wadler का लेख देखना उपयोगी है
  • मैं performance से ज़्यादा readability और maintainability को महत्व देता हूँ। इसलिए मेरे लिए Rule 4 बुनियादी है, और Rule 1 उसका परिणाम है
  • मैंने अत्यधिक विभाजित complex config files का मामला देखा है। अंत में सिर्फ 8 simple YAML files ही काफी थीं

• 90 के दशक में रात 2 बजे dataset search feature implement करने का अनुभव रहा है
  थकान में मैंने पहले linear search से implement किया और बाद में ठीक करने का सोचा, लेकिन असल में 4 घंटे के test में सिर्फ 6 सेकंड का ही फर्क निकला
  आखिरकार मैंने उसे बदला, लेकिन कोई सार्थक अंतर नहीं था

  • छोटे n पर linear search उल्टा तेज़ भी हो सकती है
  • लेकिन O(n²) algorithm में यह जोखिम रहता है कि “deploy तो हो जाएगा, पर आखिरकार production में फट पड़ेगा”

• Rule 5 से मैं पूरी तरह सहमत हूँ
  जितनी कठिन समस्या होती है, उतना ही उसका हल data structures और API के iterative refinement से निकलता है। structure सही बन जाए तो control flow अपने आप स्वाभाविक हो जाता है
  LLM इस तरह की structural thinking में कमजोर हैं। वे complex control flow तो अच्छी तरह सुझाते हैं, लेकिन composable data structure design में उतने अच्छे नहीं हैं

  • मेरे अनुभव में Rule 5 ही लगभग Rule 1 है। एक कहावत है, “code दिखाओ तो भ्रम होता है, लेकिन database schema दिखाओ तो सब स्पष्ट हो जाता है”
  • distributed services में Rule 5 को अक्सर नज़रअंदाज़ किया जाता है। कई HTTP·DB calls में बाँटने के बजाय, एक ही call में process हो सकने वाली structure ज़्यादा efficient होती है

• मैं electronic engineering (E.E.) background से हूँ, और Rule 3 की वजह से career के शुरुआती दौर में कोई बड़ी समस्या नहीं हुई
  लेकिन बाद में बड़े systems पर जाने के साथ n बढ़ा, और complexity वास्तव में महत्वपूर्ण हो गई
  Rob Pike जिस दौर की ‘big iron’ की बात कर रहे थे, वह आज के embedded environment जैसा था

  • मैं Rule 3 से आंशिक असहमति रखता हूँ। छोटे input पर फर्क नहीं पड़ता, लेकिन बड़े input पर Big-O performance महत्वपूर्ण है।
    अगर दो algorithms की implementation difficulty लगभग समान हो, तो मैं बड़े input पर तेज़ वाले को चुनता हूँ
    संबंधित लेख: Less Than Quadratic
  • “fancy” का अर्थ problem domain के अनुसार समझना चाहिए। n छोटा हो तो simple approach बेहतर है, लेकिन n बड़ा हो तो advanced algorithm ज़रूरी हो जाता है
    अक्सर लोग बहुत simple O(n²) approach चुन लेते हैं और production में फटने का अनुभव करते हैं
  • मेरे पिता Fortran के ज़माने से lookup table का खूब इस्तेमाल करते थे। यह बार-बार की गणना कम करने का एक classic optimization तरीका है

• मुझे लगता है Pike के नियम पुराने aphorisms से बेहतर हैं
  “early optimization is the root of all evil” जैसे वाक्य context खो देने पर आसानी से गलत समझे जा सकते हैं
  Pike का version ज़्यादा स्पष्ट है और उसका गलत इस्तेमाल करना कठिन है
  एक पुरानी अभिव्यक्ति थी कि “Rule 5 का सार है: ‘stupid code should use smart objects’”,
  लेकिन object-oriented युग में यह उल्टा complexity को छिपाने वाले गलत विश्वास में बदल गया

  • ऐतिहासिक सोच की कड़ी बनाए रखना महत्वपूर्ण है
  • “पुरानी कहावतों का mental clickbait” वाली अभिव्यक्ति मुझे एक तरह की चतुर उपमा लगती है

• 10 साल से अधिक समय तक एक ही codebase चलाते हुए मैंने Pike के नियमों को पूरी तरह आत्मसात कर लिया है
  KISS/DRY principles का पालन करते हुए, trendy tech की बजाय proven tech बनाए रखना लंबे समय में अधिक स्थिर रहा
  वास्तव में हमारी team के development principles document की सामग्री Pike के नियमों से लगभग मेल खाती है

• 1990 के शुरुआती C++ दौर में, doubly linked list की जगह simple array reallocation अपनाई तो
  bugs गायब हो गए और performance भी बेहतर हो गई।
  मैंने सीखा कि महंगे operations को कम बार करना एक अच्छी strategy है

• “measure किए बिना tuning मत करो” वाले नियम की तुलना Jeff Dean की Latency Numbers Every Programmer Should Know से करें तो दिलचस्प है
  Dean कहते हैं कि पहले से मौजूद knowledge के आधार पर performance का अनुमान लगाया जा सकता है
  अंततः दोनों दृष्टिकोणों में सामंजस्य हो सकता है — design चरण में intuitively fast structure चुनो, और implementation के बाद measurement-based fine-tuning करो

  • वास्तव में तेज़ code दोनों approaches का उपयोग करता है। design चरण में cache efficiency पर ध्यान दिया जाता है, और बाद में profiling से bottlenecks हटाए जाते हैं
  • latency numbers algorithm की theoretical lower bound बताते हैं, लेकिन actual performance implementation और runtime environment के अनुसार बदलती है
  • ‘early optimization’ जिस चीज़ को मना करता है, वह local hacking स्तर की tuning है। overall design में speed को ध्यान में रखना तो स्वाभाविक है

• Rule 1 और 2 केवल नई समस्याओं से निपटते समय ही पूर्ण रूप से लागू होते हैं
  जब एक ही domain में बार-बार systems बनाते हैं, तो bottleneck points का पहले से अनुमान लगाया जा सकता है
  अनुभवी developers के पास design शुरू होने से पहले ही performance का एक मोटा अंदाज़ा होता है

  • मैंने भी ज़्यादातर मामलों में bottlenecks का सटीक अनुमान लगाया है। कई बार prior performance tests के आधार पर approach बदली भी है
  • लेकिन 30 साल के अनुभव के हिसाब से, bottleneck आएगा यह अंदाज़ा सही हो सकता है, पर उसकी सटीक जगह या समय का अनुमान नहीं लगाया जा सकता
  • “Rob Pike क्या ही जानते होंगे” जैसा मज़ाक भी था, लेकिन वे Unix और Go बनाने वाले व्यक्ति हैं। उनके नियमों के पीछे वजह है