Lean Software के लिए एक गुहार (1995)
प्रोग्रामर आज की धीमी, memory-hungry apps के संदर्भ में Niklaus Wirth के 1995 के “Plea for Lean Software” पर फिर से विचार कर रहे हैं, और तर्क दे रहे हैं कि आधुनिक tools और frameworks अक्सर मामूली सुविधा के लिए विशाल hardware gains को व्यर्थ कर देते हैं। कई लोग उन organizational incentives को दोष देते हैं जो performance के बजाय features ship करने को पुरस्कृत करते हैं, Electron जैसे heavyweight stacks के उदय को, और focused, well-understood components के बजाय broad, generic dependencies पर निर्भरता को। अन्य लोग counter करते हैं कि richer functionality, Unicode, remote editing, और complex system infrastructure अनिवार्य रूप से weight जोड़ते हैं, और कई users तथा companies के लिए trade-off तब तक स्वीकार्य है जब तक perceived speed “good enough” रहे।
OS, बैकग्राउंड सेवाएँ, और उपयोगकर्ता नियंत्रण
- कई लोग व्यावसायिक ऐप्स के बैकग्राउंड सेवाएँ स्वतः शुरू करने की शिकायत करते हैं (VPNs, Steam, chat apps), जो ज़्यादातर अपडेट/टेलीमेट्री के लिए होती हैं, न कि उपयोगकर्ता मूल्य के लिए।
- Windows की आलोचना की जाती है कि वह ऐसी सेवाओं को बंद करना कठिन बनाता है और उपयोगकर्ता सेटिंग्स (जैसे AV policies) को उलट देता है, जबकि macOS को अधिक user-controllable माना जाता है।
- कुछ लोग OS-स्तरीय update services सुझाते हैं जिनके साथ ऐप्स register कर सकें, लेकिन उन्हें संदेह है कि डेवलपर्स custom updaters की बजाय इन्हें अपनाएँगे।
Editors, features, और perceived bloat
- पुराने editors, जो कुछ MB का उपयोग करते थे, अब आधुनिक टूल्स जैसे VS Code/JetBrains की तुलना में “lean” के रूप में पुनर्व्याख्यायित किए जाते हैं।
- एक पक्ष तर्क देता है कि आधुनिक सुविधाएँ (Unicode, emoji, rich remote development, LSP analysis, previews) स्वाभाविक रूप से अधिक संसाधन-उपयोग को उचित ठहराती हैं।
- दूसरे पक्ष का कहना है कि इन सुविधाओं को बहुत कम code के साथ लागू किया जा सकता है; बड़े frameworks और browser engines अक्सर आवश्यकता के बजाय default रूप से चुने जाते हैं।
- Responsiveness और input latency को raw RAM usage से अधिक महत्वपूर्ण माना जाता है।
Dependencies, libraries, और Electron/web stacks
- Shared libraries बनाम bundling पर बहस होती है: DLL-hell और वितरण की कठिनाइयों ने कई लोगों को सब कुछ एक बड़े package में bundling की ओर धकेला।
- कुछ लोग छोटे, purpose-built libraries का समर्थन करते हैं; अन्य reliability और साझा maintenance के लिए mainstream libraries (जैसे बड़े font renderers) को पसंद करते हैं।
- Electron एक lightning rod है: इसे तेज़ iteration और cross-platform dev को सक्षम करने वाला माना जाता है, लेकिन साथ ही waste का प्रतीक भी—कई embedded browsers, उच्च RAM/CPU उपयोग।
- PWAs को एक middle ground के रूप में सुझाया जाता है, हालांकि extra machinery के बिना उनमें native APIs नहीं होतीं।
Organizational incentives और process
- कहा जाता है कि बड़े संगठन features और optimism को पुरस्कृत करते हैं, performance को नहीं; छोटे-छोटे धीमेपन समय के साथ जुड़ते जाते हैं, जब तक सिस्टम असहनीय न लगने लगे।
- Agile/enterprise processes, भारी CI/CD, और बड़ी teams को effort और LOC को बढ़ाने के लिए आलोचना मिलती है, जबकि वास्तविक output कम होता है।
- Performance एक core feature के रूप में उन niches में मौजूद है (trading, search/ads) जहाँ समय सीधे monetized होता है; अन्यत्र इसे अक्सर कम प्राथमिकता दी जाती है।
Hardware, users, और testing
- कुछ लोग तर्क देते हैं कि “hardware is cheap, time is expensive,” जिससे भारी tools का औचित्य बनता है।
- अन्य लोग बताते हैं कि कई users के पास modest machines हैं; कई heavy apps (Slack/Teams, IDEs, browsers, Electron tools) चलाने से systems sluggish हो जाते हैं।
- low-end या पुराने hardware पर testing को software को lean रखने के लिए एक discipline के रूप में प्रस्तावित किया जाता है।
Responsibility और lean-software ethos
- कई लोग ज़ोर देते हैं कि developers को performance की ज़िम्मेदारी लेनी चाहिए, fast-by-design architectures चुननी चाहिए, और gratuitous abstraction तथा generic frameworks से बचना चाहिए।
- अन्य लोग ecosystem और economic forces (shared dependencies, job incentives, management culture) को उजागर करते हैं, जो संरचनात्मक रूप से bloat को बढ़ावा देते हैं।
- performance-focused tools की एक counter-movement को लेकर सावधानीपूर्ण आशावाद है, लेकिन संदेह भी है कि यह व्यापक रूप से bloat trends को उलट पाएगी।