2024 में lean software के लिए अपील

2024 के लिए संक्षिप्त software के लिए अपील

• software का आकार बढ़ने की प्रवृत्ति, यानी 'bloat', अब भी software की सबसे बड़ी कमजोरियों में से एक है।
• संक्षिप्त software विकसित करना user experience को बेहतर बनाने, security risk को कम करने और system की efficiency बढ़ाने के लिए महत्वपूर्ण है।
• developers को software इस तरह design करना चाहिए कि कम code के साथ ज़्यादा functionality दी जा सके।

GN⁺ की राय

• software में 'bloat' की प्रवृत्ति system performance में गिरावट और security vulnerabilities पैदा कर सकती है, इसलिए developers को code optimization और efficient design पर ध्यान देना चाहिए।
• users तेज़ और अधिक सुरक्षित software experience चाहते हैं, इसलिए संक्षिप्त software बाज़ार में competitive advantage हासिल कर सकता है।
• यह लेख developers को मौजूदा software development trends पर फिर से विचार करने और बेहतर software बनाने की प्रेरणा देने में मदद कर सकता है।

[GN⁺]

Hacker News राय

• Vernor Vinge के उपन्यास "A Deepness in the Sky" में मानवता अभी भी प्रकाश की गति से तेज़ तकनीक के बिना तारों के बीच फैली हुई है। अंतरिक्ष यान बहुत पुराने हैं और उनमें अलग-अलग सिस्टमों और सभ्यताओं की तकनीक मिली-जुली है।

  • कंप्यूटर सिस्टम इतने लंबे समय में विकसित हुए हैं कि ज़्यादातर कोड को कोई भी ठीक से नहीं समझता। लोग बस उस कोड का इस्तेमाल करते हैं और उसके ऊपर नई चीज़ें बनाते जाते हैं।
  • एक पात्र लंबे समय से यात्रा कर रहा है और stasis अवस्था में रहा है, इसलिए वह शायद सबसे उम्रदराज़ इंसानों में से एक है। वह अतीत का एक systems engineer है, जो उस दौर की कार्यप्रणाली और कमज़ोरियों को जानता है, इसलिए भविष्य में जब दूसरे लोग उसके ऊपर कई परतें चढ़ा चुके होते हैं और ठीक-ठीक नहीं जानते कि वे क्या कर रहे हैं, तब उसे इसका बड़ा लाभ मिलता है।
  • लगता है Vernor ने एक अहम बात पकड़ी थी।

• npm की ज़्यादातर लाइब्रेरीज़ में बेवजह बहुत ज़्यादा फीचर्स होते हैं। लेखक अच्छे design को नहीं समझते, और हर लाइब्रेरी सब कुछ करने की कोशिश करती है।

  • उदाहरण के लिए, एक string encoding conversion लाइब्रेरी में file load करना, save करना, इंटरनेट से download करना, command line tool देना जैसी सारी चीज़ें भी शामिल होती हैं। लाइब्रेरी को सिर्फ़ एक ही काम करना चाहिए।
  • Rust में भी हालात बेहतर नहीं लगते। Rust docs एडिट करने के लिए भी आपको लगभग 1000 crates install करने पड़ते हैं।
  • समस्या भाषा नहीं है, बल्कि यह है कि कोई भी लाइब्रेरी publish कर सकता है, और लोग सच में ऐसा करते हैं। जो लोग बस "काम पूरा करना" चाहते हैं, वे सबसे ज़्यादा फीचर्स वाली लाइब्रेरी चुनते हैं, और लाइब्रेरी के बाहर कुछ लाइन कोड लिखकर समस्या हल करने की बजाय और फीचर्स माँगते हैं।
  • इसे कैसे हल किया जाए, यह साफ़ नहीं है। एक विचार यह है कि "low dependency" को बढ़ावा देने वाला एक समूह शुरू किया जाए, जो लोग अपनी लाइब्रेरी पर वह badge लगाना चाहें उन्हें प्रोत्साहित किया जाए, और लोगों को लाइब्रेरी चुनते समय वह badge देखने के लिए प्रेरित किया जाए।

• Antoine de Saint-Exupéry की "Terre des Hommes" में वह पूछते हैं कि क्या आपने कभी आधुनिक विमान को देखकर, उसकी हर साल बदलती रेखाओं का पीछा करते हुए, मनुष्य द्वारा बनाई जाने वाली हर चीज़ के बारे में सोचा है।

  • औद्योगिक प्रयासों, गणना, design और blueprints पर की गई अनगिनत रातों की मेहनत आखिरकार ऐसी वस्तु बनाने पर केंद्रित होती है, जिसमें सरलता का अंतिम सिद्धांत मौजूद हो।
  • फर्नीचर की वक्रता, जहाज़ की keel, विमान के fuselage को धीरे-धीरे वैसा बनाने के लिए जैसे मानव छाती या कंधे की मूल और शुद्ध वक्रता होती है, कई पीढ़ियों के कारीगरों को प्रयोग करने पड़ते हैं।
  • पूर्णता तब नहीं मिलती जब जोड़ने के लिए कुछ न बचे, बल्कि तब मिलती है जब हटाने के लिए कुछ न बचे।

• आज हम जितना कोड इस्तेमाल करते हैं, उसकी मात्रा बेहद विशाल है। उदाहरण के लिए, garage door खोलने के लिए भी 5 करोड़ से अधिक lines of active code की ज़रूरत पड़ सकती है।

  • इतना सारा कोड चल रहा है, लेकिन संभव है कि उसमें से ज़्यादातर का कभी गहराई से review ही न हुआ हो।
  • फिर भी हम वापस npm dependencies install करने की रोज़मर्रा की दुनिया में लौट आते हैं।

• software को इतना जोखिमभरा माना जाता है कि लोगों को सलाह दी जाती है कि वे इसे खुद run न करें, बल्कि इसे "X as a service" providers या "cloud" पर छोड़ दें।

  • यह वैसा है जैसे कहा जाए कि कारें बहुत आसानी से आग पकड़ लेती हैं, इसलिए ड्राइविंग किसी ऐसे expert को सौंप दो जो अपने साथ professional firefighters भी लाता हो।

• software ज़्यादा संक्षिप्त नहीं हो पाता क्योंकि उसके लिए समय, कौशल और महँगे लोग चाहिए होते हैं।

  • एक independent developer के तौर पर, पिछले साल node.js सीखने वाला कोई व्यक्ति node.js, containers, तरह-तरह की AWS hosted DB services, lambda services, object storage, Cloudflare, yaml, react, vite वगैरह को जोड़कर एक दिन में कमज़ोर webapp बना सकता है।
  • तेज़ और कम maintenance cost वाला software लिखना, और उससे मुनाफ़ा कमाना, मुश्किल है।

• पहले के समय में सिस्टम द्वारा दिए गए hooks को standardize करने की कोशिश होती थी ताकि सभी developers उन्हें interface वगैरह के लिए इस्तेमाल करें, और developer का मुख्य काम program logic लिखना हो।

  • ये system calls इस तरह बनाए जाते थे कि code बदलने पर भी वही काम करते रहें, और नए software को ज़्यादा फीचर्स देते हुए पुराने code को बिना समस्या compile और run होने दें।
  • यह सपना जल्दी टूट गया (जैसे DLL problems), और package management का बड़ा हिस्सा सही लाइब्रेरी इस्तेमाल करवाने पर केंद्रित हो गया।
  • अब हमारे पास बहुत अनुभव है, लेकिन सवाल यह है कि क्या वह सपना कभी संभव था, या क्या हम मौजूदा अव्यवस्थित हालात में तेज़, संक्षिप्त, स्थिर और ज़्यादा सुरक्षित software की ओर बढ़ भी रहे हैं।

• Rust पर एक राय यह है कि अगर Rust में C++ की तुलना में प्रति पंक्ति 70% कम vulnerabilities हों, लेकिन Rust में आप सैकड़ों packages खींच लाएँ और lines of code 10 गुना ज़्यादा हो जाएँ, तो vulnerabilities की कुल संख्या फिर भी ज़्यादा हो सकती है।

• अगर 20 साल पहले पता होता कि आज software ऐसा होगा, तो शायद मैं programmer बनना ही नहीं चुनता। सब कुछ बहुत विशाल हो गया है, hardware और software के बीच अंतहीन दौड़ चल रही है, और चीज़ें न बेहतर हो रही हैं, न आसान, न सरल।

• लिंक क्लिक करते ही CTA banner, Google ads और cookie banner सामने आ जाते हैं। cookie banner बंद करते ही एक और Google ad दिखता है, और scroll करने पर वह पीछा करता रहता है। लेख पढ़ते हुए कम से कम तीन और ads दिख जाते हैं।

  • ऐसे माहौल में उस सामग्री को गंभीरता से लेना मुश्किल हो जाता है।