- जितना अधिकांश लोग कल्पना करते हैं, उससे कहीं अधिक सिस्टम पुराने हार्डवेयर पर भी पर्याप्त रूप से चल सकते हैं
- यदि वास्तविक सॉफ़्टवेयर ऑप्टिमाइज़ेशन किया जाए, तो ऐसी दक्षता हासिल होने की संभावना बहुत अधिक है
- दुर्लभ कंप्यूटिंग संसाधनों के बाज़ार मूल्य संकेत सॉफ़्टवेयर दक्षता के लिए प्रेरणा देते हैं
- मौजूदा इंटरप्रेटर-आधारित माइक्रोसर्विस प्रोडक्ट्स को native code से बने monolithic architecture में बदलने की आवश्यकता है
- दूसरी ओर, यदि बहुत सस्ते और स्केलेबल compute resources उपलब्ध न हों, तो नवोन्मेषी नए प्रोडक्ट्स का विकास कहीं अधिक दुर्लभ हो सकता है
1 टिप्पणियां
Hacker News की राय
यह कहा जा सकता है कि बाज़ार में bug से भरा और अक्षम software भी उतना ही बिकता है जितना perfect software, क्योंकि दोनों में से जो software बनाना सबसे सस्ता है वही आगे निकलता है। यह ‘lemon market’ जैसी कहानी है: बाज़ार हर चीज़ को मानो high-quality समझकर खरीदता-बेचता है, लेकिन वास्तव में quality घटाकर cost कम की जाती है। खरीदार खरीदने से पहले high-quality और low-quality में फर्क नहीं कर पाते, इसलिए दोनों की demand कृत्रिम रूप से लगभग समान हो जाती है। इसकी वजह information asymmetry है। यह पहले से सच है, और AI में भी तेजी से सच होता जा रहा है। उपयोगकर्ता sophisticated machine learning applications और सिर्फ ‘AI’ नाम लगे washing machine के बीच फर्क नहीं कर पाते। ‘AI’ का label अपने-आप price premium दिलाता है, इसलिए उपयोगकर्ता washing machine के लिए ज़्यादा भुगतान करते हैं। इसी तरह, यदि खरीदार यह मानकर खराब software के लिए पैसे दे कि यह ‘experts द्वारा design और लिखा गया software’ है, तो वह मूल रूप से वही बात है। लगभग सारा software IC1-3 level पर लिखा जाता है, और ज़्यादातर कंपनियों में QA वाला अकेला व्यक्ति quality improvement का एकमात्र संकेतक बन जाता है। कभी-कभी interns ‘LGTM’ का मंत्र जपते हुए सुधार की उम्मीद करते हैं, लेकिन असल में वह भी कम ही होता है.
मैंने quality से अलग पहचान रखने वाला software startup बनाने की कोशिश की थी। मुझे पूरा भरोसा था कि अगर product बेहतर होगा तो लोग उसे पहचानेंगे और वह सफल होगा, लेकिन वास्तव में ऐसा नहीं हुआ। Growth हुई, पर इतनी धीमी कि profitable होने से पहले ही पैसा खत्म हो गया। मैंने जो सीखा वह यह था कि low cost, और उसके साथ आने वाली low quality, competitive market में competitive advantage बन जाती है। कॉलेज के दिनों से यह बात सुनता आया था, लेकिन इस अनुभव ने इसे हड्डियों तक महसूस करा दिया। यही वजह है कि बाज़ार में सब कुछ औसत होता जाता है, और किसी चीज़ के लोकप्रिय होते ही उसकी high quality भी बिगड़ने लगती है। Product जितना scale करता है, cost cutting का pressure उतना बढ़ता है। लोग सस्ता खरीदना चाहते हैं, इसलिए कोई न कोई cost (यानी quality) घटाकर और सस्ता दे देता है। कंपनियाँ survival और profit के लिए न्यूनतम ही चुकाती हैं। हाँ, कभी-कभी exceptions होते हैं, लेकिन अंत में बात gradual cost reduction तक ही पहुँचती है। शायद इस phenomenon का कोई नाम होगा; यह lemon market से थोड़ा अलग है। बाज़ार collapse नहीं करता, लेकिन हर जगह stable mediocrity बना देता है.
इस दृष्टिकोण पर आपत्ति है कि ‘बाज़ार’ हर चीज़ को high-quality की तरह बेच रहा है। यहाँ ‘high-quality’ का मतलब बहुत महत्वपूर्ण है। यह सुनने में ऐसा लगता है कि poor performance ही low quality है, लेकिन वास्तव में Teams, Slack, Jira जैसी performance के लिए बदनाम apps के competitors में ऐसे products हैं जिनकी performance उनसे कहीं बेहतर है। फिर भी अगर उपयोगकर्ताओं से कहा जाए कि Slack की जगह terminal UI, बिना video chat, बिना emoji वाला Weechat चुनें, तो ज़्यादातर लोग दूसरे को ही lower-quality मानेंगे। Performance भी बस एक feature है। उदाहरण के लिए, Chrome की शुरुआती सफलता उसकी speed की वजह से थी, और Python developers भी performance gains के कारण uv/ruff की ओर जा रहे हैं। लेकिन अगर Slack 5 सेकंड की जगह 10ms में खुल जाए, तो भी अधिकतर users को शायद फर्क नहीं पड़ेगा.
मैं इस बात से सहमत नहीं हूँ कि inefficient software बाज़ार की lemon market structure की वजह से है। यह तभी लागू होता है जब information asymmetry हो। ज़्यादातर मामलों में लोग कुछ bugs को नज़रअंदाज़ कर सस्ता दाम पसंद करते हैं। अगर बहुत कठोर QA और multi-engineer code check process से होकर pricing की तुलना करें, तो बात साफ हो जाती है। छोटे स्तर पर, मैंने एक छोटे bookstore के लिए software बनाया था। मैंने उसे जल्दी बनाया और बहुत ज़्यादा charge भी नहीं किया। वह perfect नहीं था, लेकिन कोई समस्या आती तो मैं तुरंत ठीक कर देता था, और ग्राहक भी यह समझता था कि यह अच्छा सौदा है, इसलिए संतुष्ट था.
मैंने बड़ी कंपनियों में भयानक HR, expense, time tracking, और insurance portals इस्तेमाल किए हैं। वे इतने खराब थे कि शक होता था कि जिसने इनके लिए payment approve किया, क्या उसने कभी खुद यह product इस्तेमाल भी किया था। अगर हमारी टीम bug और UI nightmare से भरा product ग्राहक के सामने रखे, तो तुरंत डाँट, पदावनति, या शायद नौकरी जाने जैसी स्थिति बन जाए.
बाज़ार द्वारा ‘buggy, inefficient software’ खरीदने की असल बात यह है कि बाज़ार <i>support</i> खरीदता है। यह Google जैसी कंपनी पर भी लागू होता है, और उन कंपनियों पर भी जिनमें human support कम है। ‘Support’ कई रूपों में आता है — documentation, videos, blog information, मदद करने वाले लोग, मेरे environment (OS, browser आदि) का support, मैं जो काम करना चाहता हूँ उसका support, वगैरह। सबसे खराब ERP को भी जीवित रखने वाली पहली चीज़ आखिरकार असली इंसान ही होते हैं। Support का होना या न होना product की मौत-जीवन रेखा तय करता है। यदि कोई छोटी टीम लड़ाई जीतना चाहती है, तो ‘support की ज़रूरत’ कम करना और किसी दूसरे dimension में support जोड़ना समझदारी है। सबसे आसान तरीका इंसानों को जोड़ना है। और अपनी strengths को ठीक से communicate भी करना चाहिए। Support के हर प्रकार का मूल्यांकन अलग है; जैसे open source code बनाम proprietary code। बहुत से लोग code से ज़्यादा support को महत्व देते हैं, इसलिए अगर support ज़्यादा मिले तो वे proprietary विकल्प चुनते हैं.
मुझे Costco में खरीदारी पसंद होने की एक बड़ी वजह यह है कि वे आम तौर पर कूड़ा सामान नहीं बेचते। उनका filter हमेशा मेरे standards से नहीं मिलता, लेकिन फिर भी वह एक अर्थपूर्ण quality filter है.
भले ही users software quality और performance के आधार पर निर्णय ले सकें, मेरी खुली app list देखें तो कोई भी app सिर्फ बेहतर performance के कारण replace नहीं की जा सकती। जैसे Docker, iterm2, WhatsApp आदि मैं बहुत specific कारणों से इस्तेमाल करता हूँ। सिर्फ fastest solution मौजूद होने से मैं switch नहीं कर सकता। शुरुआत से ही मेरी requirements पूरी करने वाले software का होना, performance benchmark से भी अधिक महत्वपूर्ण कारक है.
99% software performance को ध्यान में रखे बिना लिखा जा रहा है। HN पर भी performance improvement को खुद एक तरह का taboo समझा जाता है। L4/5 level से ऊपर के engineers में भी performance intuition की कमी अक्सर होती है। Business perspective से भी, जब तक hardware उस software को चला पा रहा है, efficiency की परवाह नहीं की जाती। और जब समस्या आती भी है, तो पहले अतिरिक्त hardware जोड़कर ही हल ढूँढा जाता है.
मौजूदा market structure में buggy और inefficient software इसलिए हावी है क्योंकि जब भी चाहो hardware खरीदकर उसे चला सकते हो। Software hardware की processing capacity को भरते हुए फूलता रहता है — “Andy gives, Bill takes away” वाला नियम। इसलिए lean, high-quality software बनाने का incentive नहीं है। लेकिन अगर ऐसा दौर आ जाए जब cutting-edge chips मिलना बंद हो जाएँ — जैसे geopolitical crisis, बड़े पैमाने पर factories का नष्ट होना वगैरह — तब resource-efficient software का आर्थिक मूल्य बहुत बड़ा हो जाएगा। फूला हुआ software फिर चल ही नहीं पाएगा। Carmack का कहना है कि ऐसी स्थिति में optimization के लिए इतना headroom है कि अंततः पुराने chips पर भी software चलाने के तरीके निकाले जा सकते हैं.
अच्छी तरह design किया गया software वह होता है जिसे बदलना आसान हो। इसके विपरीत, bugs से भरे spaghetti code के ढेर को कोई छूना नहीं चाहता, इसलिए वही हमेशा बना रहता है। शुद्ध evolutionary नज़रिए से देखें तो अंत में bad software का ही प्रभुत्व हो जाता है.
used car market lemon market इसलिए है क्योंकि अच्छी तरह maintain की गई कार और टूटने की कगार पर खड़ी कार में फर्क करना मुश्किल है। लेकिन new car market पर यह लागू नहीं होता, क्योंकि वहाँ कड़ा नियंत्रण है। Software हमेशा नया होता है। जैसे दशकों में car quality बढ़ी है, वैसे software quality भी बढ़ाई जा सकती है। कुछ standards पूरे होने पर ही बेचने देना चाहिए, serious bugs हों तो recall होना चाहिए, और जानबूझकर defective product बेचने पर सज़ा होनी चाहिए। बाकी लगभग हर industry ऐसे ही चलती है.
Web 2.0 के ‘perpetual beta’ और SaaS model के आने से users की patience भी बदल गई है। Microsoft ने कई पीढ़ियों तक यह धारणा बिठाई कि ‘software का टूटना स्वाभाविक है’। जब सब लोग खराब software के आदी हो जाते हैं, तो उन्हें अच्छे software की value समझ में कम आने लगती है.
मैंने सचमुच वह AI sticker लगा washing machine खरीदी थी। Marketing पर हँसी आई, लेकिन कीमत reasonable थी, इसलिए खरीद ली.
शायद बात केवल security flaws की हो रही है। Performance या दूसरे bugs से भरे Excel या Photoshop को लोग जल्दी छोड़ देंगे। लेकिन security को users तब तक पहचानते ही नहीं जब तक समस्या हो न जाए, और hack हो जाने पर भी कारण नहीं समझते। Developers के लिए incentive नहीं है। Performance में भी एक स्तर के बाद optimization पर और resource लगाना लोग पसंद नहीं करते। यह diminishing returns का नियम है.
हो सकता है users AI की sophistication और केवल दिखावे वाले ‘AI washing machine’ में फर्क न कर पाएँ, लेकिन अच्छा AI उपयोगकर्ता को खुद information asymmetry से पार पाने में मदद भी कर सकता है। आखिरकार अगर अच्छे AI को चुनने का तरीका हो, तो समस्या हल हो सकती है.
मैं यह नहीं मानता कि ‘सबसे सस्ता software’ बनाना हर हाल में सचमुच सस्ता होता है। Startup level पर जल्दी-जल्दी जोड़ा गया software सस्ता पड़ सकता है, लेकिन scale बढ़ने पर वही अधिक महँगा बन जाता है। Airlines तक एक olive कम करके cost बचाती हैं, तो यह सवाल उठता है कि developers से optimization करवाना inefficient क्यों माना जाता है। हम नए features जोड़ते जाते हैं, लेकिन users को हर update के साथ product और धीमा लगता है। उल्टा अगर product तेज हो जाए तो लोग उसकी तारीफ़ करते हैं। Engineers MBA की तरह व्यवहार करते हुए बस ‘इसकी value नहीं है’ दोहराते रहते हैं। लेकिन software bug fix की ‘value’ काफी हद तक subjective होती है। Engineer का काम bugs ठीक करना है। Brand भी महत्वपूर्ण है, लेकिन आज के बड़े brands अपने brand value को नज़रअंदाज़ कर रहे हैं। शायद इसलिए कि consumers आसानी से switch नहीं करते, लेकिन switch करने पर भी अक्सर बस नया UI मिलता है और सीखने के लिए और चीज़ें बढ़ जाती हैं (यहाँ तक कि Apple भी अब intuitive नहीं रहा).
आज की दुनिया में पुराना hardware भी शायद काम चला सकता है, लेकिन CPU और hardware वैसे भी लगातार तेज हो रहे हैं, इसलिए code को और efficient बनाने की खास वजह नहीं बचती.
information asymmetry की समस्या FOSS या proprietary ‘shared source’ products में दूर की जा सकती है। Code को सीधे देखकर अंदाज़ा लगाया जा सकता है कि overall quality अच्छी है या नहीं। भले ही असली bug न मिले, function length, comments, naming जैसी चीज़ों से conscientious development culture का पता चल जाता है। सच कहूँ तो, जब किसी महँगे proprietary product का db schema बेतरतीब दिखता है, तो भरोसा नहीं बनता.
bad software की production (maintenance) cost लंबे समय में ज़्यादा पड़ती है.
इसलिए brand quality का संरक्षक बनता है.
जैसे खाने में toxicity, expiry, और addictive additives बेचने पर कानून से रोक है, वैसे ही software पर भी regulation होना चाहिए। लेकिन GDPR बनने से पहले तक regulation लगभग बेअसर था, और आज भी violations रोज़मर्रा की बात हैं.
1980 के बाद से computing power लगभग 1000 गुना बढ़ी है। अगर dynamic array bounds checking से होने वाला performance loss 5% मान लें (असल में यह इससे भी काफी कम है), तो checking चालू रखकर भी हम 950 गुना तेज computers इस्तेमाल कर सकते थे। अगर 1980 में जाकर लोगों से पूछा जाता कि ‘कम bugs, आसान debugging, और 950 गुना तेज computer’ चाहिए या ‘सीधे 1000 गुना तेज लेकिन उतने ही bug वाले और debug करना ज्यादा मुश्किल computer’, तो ज़्यादातर लोग 950 गुना वाला चुनते। लेकिन हमने अंत में 1000 गुना वाला चुना। निजी तौर पर मुझे लगता है कि 1000x वाले लोगों ने स्थिति खराब कर दी.
लेकिन वह 1000x performance bounds checking में नहीं, बल्कि endless abstraction और inefficiency में बर्बाद हो गई.
मैंने एक बार vendors को मजबूर किया था कि वे अपना धीमा और bug-filled software Sparc 20 पर चलाएँ। नतीजतन उन्होंने software optimize किया, और वही कंपनी के market success की नींव बना। Optimization competitive advantage है.
यह बात सिर्फ 1980 के बाद के लंबे अंतराल पर लागू हो सकती है। एक हालिया वीडियो का सार यह था कि “आज के computers, 20 साल पहले के computers से उतने तेज नहीं हैं जितना लोग समझते हैं; खास optimization किए बिना यह महसूस भी नहीं होता।” लेखक ने compiler optimization जैसी चीज़ों को नज़रअंदाज़ किया, लेकिन असल में performance improvement लोगों के अनुमान से कहीं कम रहा; कहा गया कि 15 साल में सिर्फ दोगुना हुआ.
आपने array bounds checking का cost 5% कहा, लेकिन हर algorithm इतना simple नहीं होता। Processing count के हिसाब से सिर्फ checking जोड़ने से cost 3-4 गुना तक बढ़ सकती है। कुछ specific workloads में अगर checking अनिवार्य कर दी जाए तो language की competitiveness ही खत्म हो सकती है। ज़्यादातर cases में यह मायने नहीं रखता, लेकिन safe और general mode अलग-अलग रखना बेहतर होगा.
अगर केवल bounds checking की बात करें तो cost कम हो सकता है, लेकिन safe languages का overhead कहीं बड़ा होता है। GC languages में memory usage कई गुना बढ़ सकता है.
large numbers का नियम मत भूलिए। एक system में performance का 5% कम होना बड़ी बात नहीं लगती, लेकिन दुनिया के सारे computing environments में 5% loss जुड़ जाए तो उसका प्रभाव बहुत बड़ा होगा.
मैं short-term gains पसंद करने वाली human nature से सहमत हूँ, लेकिन dynamic bounds checking अपने-आप security issue हल नहीं करती। अंतिम समाधान अभी भी नहीं है.
हम आज यहाँ इसलिए पहुँचे हैं क्योंकि हम browser से बँधे हुए हैं.
पहला जवाब लगभग सही निष्कर्ष है। सिर्फ यह तथ्य कि C अब भी व्यापक रूप से उपयोग में है, दिखाता है कि समस्या की जड़ stack के निचले स्तर पर मौजूद inefficiency है.
‘5%’ वाला आधार संदिग्ध लगता है। यह cost किस benchmark पर निकाला गया, भरोसा नहीं होता। हर बार array में value डालते समय check किया जाए तो शायद cost दोगुने से भी अधिक हो जाए — यह सवाल उठता है.
आज की ज़्यादातर programming languages array bounds checking को default रूप से support करती हैं.
Node.js पहली बार आया था तब की स्थिति याद आती है। Client और server coding को जोड़ना उसका बड़ा लाभ था, लेकिन अब वह security nightmare बन गया है। इसलिए छोटे codebase वाली minimal languages के भी अपने फायदे हैं.
काश लोगों को जल्दी समझ आ गया होता कि एक string gigabytes का data रख सकती है, तो null-terminated strings शायद गायब हो जातीं और सबकी तकलीफ़ कम होती.
1000 गुना तेज products का आनंद लेने वाले 1000Xers असल में बहुत छोटी संख्या हैं। आम users के desktop software आज भी धीमे ही हैं.
सच तो यह है कि speed लगभग 100,000 गुना बढ़ी है। सिर्फ clock ही 1000 गुना, cores 10 गुना, instructions AVX वगैरह से 10 गुना, architecture के स्तर पर मिलाकर 1-2 million गुना तक तेजी आई, फिर भी perceived speed पर असर नहीं दिखता.
किसी ने Robert Barton का वह कथन उद्धृत किया जिसमें उन्होंने ऐसे लोगों को ‘low cult के high priests’ कहा था.
1980 के बाद से देखें तो बहुत तेजी आई, लेकिन 2005 के बाद देखें तो सुधार लगभग 5 गुना ही है.
clock 2000 गुना, SIMD वगैरह से IPC 80 गुना, cores को मिलाएँ तो कुल मिलाकर 1-2 million गुना तक गति बढ़ी, लेकिन ज़्यादातर programs के लेखक बस इतना सोचते हैं कि ‘चल रहा है, तो उतनी ही speed है।’ Optimization के बारे में सोचने वाले लोग बहुत कम हैं, HN users में भी.
2001 के आसपास 1GHz CPU को basic software के runtime baseline की तरह मान लेना चाहिए था। AI experience भी काफी निराशाजनक रहा। उम्मीद थी कि LLM language translation, code optimization जैसी चीज़ें अच्छे से कर पाएगा, लेकिन वास्तविकता वैसी नहीं है। मैंने खुद AI से Unix
sedcode को JVM language में port करवाया था, लेकिन basic से आगे जाते ही वह पूरी तरह विफल रहा। अंततः इस पूरे रुझान का लक्ष्य ‘jobs कम करना’ है, software quality बढ़ाना नहीं। AI आगे और अधिक bad software पैदा करेगा.यही तो JavaScript है, और यही users का भविष्य भी.
Google (और Facebook) में काम करते हुए मैंने महसूस किया कि hardware कितनी सस्ती चीज़ है और code optimization अधिकतर मामलों में कितनी कम value रखता है। 10 साल पहले भी Google में datacenter resource management ज़रूरी था और हर project का budget होता था। CPU, HDD, flash जैसे resources के बीच exchange करके relative cost निकाली जाती थी। भले flash hard drive से 20 गुना महँगा हो, लेकिन actual bottleneck को ध्यान में रखें तो कई बार flash ही सस्ता पड़ता था। इन resources को software engineer time (1 SWE = 1 person-year) में भी convert किया जाता था। अगर optimization से 5000 CPU cores से अधिक बचत न हो, तो यह उल्टा घाटे का सौदा था। सिर्फ बड़े projects में optimization मायने रखता था; बाकी जगह code वैसे भी जल्दी replace हो जाता था, इसलिए optimization बेकार समझा जाता था। Web usability के संदर्भ में mouse interface भी बहुत inefficient है, जबकि 30-40 साल पहले के text terminals कहीं अधिक efficient थे। उम्मीद थी कि ‘web standardize होकर अगले चरण में जाएगा’, लेकिन ऐसा नहीं हुआ। आज भी हर हफ्ते नया framework आता है, और वही scrollbar तक hardware compatibility तोड़कर फिर से implement किया जा रहा है। इस समस्या का समाधान मुझे नहीं पता.
मुझे लगता है यह सोच सिर्फ उन कंपनियों पर लागू होती है जिनकी engineering cost बहुत ऊँची है, margins बड़े हैं और projects कई हैं। जहाँ भी थोड़ा भी अतिरिक्त पैसा बन रहा हो, वहाँ engineers को optimization पर लगाना बेहतर है। व्यवहार में, हर कंपनी बस Google की नकल करती है और economic logic से अलग फैसले लेती है; यह बहुत-सी समस्याएँ समझा देता है.
मैं भी Google से हूँ। Google CPU-per-usage optimization की बात जरूर करता है, लेकिन वास्तव में उसने दो बातों पर बहुत ज़ोर दिया: latency और overall server utilization। दोनों upper org के अहम KPI थे, इसलिए इन पर भारी engineering resources लगाए जाते थे। Machines जितनी ज़्यादा हों, उतना कम खाली रखना चाहते हैं, और latency-sensitive businesses में लोग सिर्फ कुछ milliseconds घटाने के लिए भी बहुत प्रयास करते हैं.
Google का logic इसलिए चलता है क्योंकि वह ऐसी company है जहाँ प्रति core cost बहुत बड़ी है। ज़्यादातर सामान्य कंपनियों पर यह बिल्कुल लागू नहीं होता। यह मॉडल Facebook/Google/Netflix जैसी scale वाली कंपनियों में ही काम करता है.
Google ने बेहतर compression और binary serialization formats भी अपनी profitability सुधारने के लिए ही बनाए.
शीर्षक देखकर मुझे लगा था कि Carmack low-end hardware पर software optimization की आलोचना कर रहे होंगे। वास्तव में ऐसा नहीं है; वे hardware progress रुक जाने वाली एक thought experiment की बात करते हैं, और निष्कर्ष में कहते हैं कि “अगर cheap और scalable computing न हो, तो innovative products कम हो जाते हैं।”
यह कल वाली thread से जुड़ी हुई बात है.
“cheap और scalable computing के बिना innovation घटता है” इस निष्कर्ष पर एक प्रतिक्रिया यह है कि smartphone के बाद से हमने लगभग कोई वास्तविक innovation देखा ही नहीं, और चूँकि capital hardware progress पर निर्भर है, नए products भी अब मूल रूप से पुराने products से अलग नहीं रहे.
निजी तौर पर मैं इस दावे से सहमत नहीं हूँ। अगर कुछ समय के लिए feature development रुक भी जाए, तो पर्याप्त तैयारी के बाद innovation फिर लौट आएगा। एक गिरावट आ सकती है, लेकिन वह स्थायी नहीं होगी.
असली बिंदु यह है कि “bloat” सिर्फ wastage नहीं, बल्कि आर्थिक incentives से पैदा हुई developer productivity है। कम जटिल languages के बजाय ज्यादा productive tools चुनने से अधिक लोगों को hire करना और cost कम करना संभव होता है.
अगर hardware की उम्र planned obsolescence की तुलना में 5 या 10 साल और बढ़ाई जा सके, तो e-waste, rare minerals की खपत, और greenhouse gas emissions में भारी कमी लाई जा सकती है। लेकिन software market इन externalities की cost नहीं उठाता। Release के बाद test, fix, repeat करना long-term design से कहीं सस्ता पड़ता है। Game industry के कुछ हिस्सों ने high-performance + revenue का formula खोज लिया है, लेकिन यह व्यापक नहीं है। Enterprise/consumer software में performance की बजाय बस उस न्यूनतम सीमा का ध्यान रखा जाता है जिसे user बर्दाश्त कर ले। लगातार नए features और बदलाव के कारण performance पर ध्यान देना कठिन हो जाता है, और budgets में error rate मानकर ही margin छोड़ा जाता है। अपेक्षाकृत ‘ready state’ में release करने के मॉडल की तुलना में यहाँ complexity और change risk कहीं अधिक है.
पिछले 10 साल से भी ज़्यादा समय से हम पूरे exchange matching engine को single thread पर चला रहे हैं। कम-से-कम serialized trade processing के मामले में computing power उतनी तेजी से नहीं बढ़ी है। जब तक आप millions of TPS तक नहीं पहुँचते, cluster में scale out करने की ज़रूरत भी नहीं पड़ती। उल्टा, design को simple रखकर single machine पर काम चलाया जा सकता है.
यही बात सच में frustrate करती है। कई system architects अपनी उपस्थिति दर्ज कराने के लिए systems को अनावश्यक रूप से complex बनाते रहे, और उससे सिर्फ नए issues पैदा हुए। मूल design से ही अधिकांश requirements पूरी हो जातीं, और आज की local computing power के साथ single machine processing भी आराम से संभव है.
मुझे जिज्ञासा है कि order matching को parallel क्यों नहीं किया जा सकता। क्या sort जैसी log reduction लागू करके parallel processing संभव नहीं हो सकती? या matching process में simple sorting के अलावा बहुत कम computation होने के कारण यह लाभकारी नहीं होगा?
सिर्फ simple processing हो तो single thread संभव है, लेकिन अगर हर transaction पर complex computation करना पड़े तो नहीं। मगर वास्तव में कौन-सा processing इतना complex होता है, यह domain knowledge के बिना समझना कठिन है.
अगर development tools का evolution जारी रहता, तो पहले RAD से पूर्ण native GUI आसानी से बनाया जा सकता था, लेकिन आज Electron हावी है। स्थिति यह है कि कई web browsers अपने-अपने Chromium-based variants के रूप में साथ-साथ installed रहते हैं.
अंततः यह resource allocation की economics का सवाल है। क्या developers को software optimization पर समय लगवाना चाहिए, या नए features बनवाने चाहिए? अगर दूसरा विकल्प ज्यादा revenue लाता है, तो वही चुना जाएगा। उल्टा अगर optimization ज्यादा महत्वपूर्ण हो, तो उसी हिसाब से काम होगा.
economics वाली बात से सहमत हूँ, लेकिन मूल समस्या यह है कि software कंपनियाँ अपनी negative externalities पूरे समाज पर डाल देती हैं। अतिरिक्त energy consumption, wastage, और बढ़ते e-waste की उन्हें परवाह नहीं होती.
यह technical/financial debt दूसरों पर थोपकर ढेर सारा कचरा बढ़ाने वाली संरचना है। कई बार optimization का वास्तविक लाभ न भी हो, फिर भी बस servers जोड़ते जाने की आदत दुखद है.
‘features जोड़ना ज्यादा महत्वपूर्ण है’ — यह case पर निर्भर करता है। मैं latest macOS, Windows, Android के अधिकांश नए features इस्तेमाल नहीं करता, और efficient environment व security को ज़्यादा महत्व देता हूँ। Design software में भी नए features से ज़्यादा efficiency improvements की अपेक्षा रहती है। कभी-कभी तो 10 साल पुराने Illustrator/Photoshop की इच्छा होती है। Music production software में नए features ज़रूर उपयोगी हो सकते हैं, लेकिन अगर वे efficiency खराब करें तो स्वीकार्य नहीं लगते। Code editor के लिए VSCode ही काफी है; बस काश वह और तेज व हल्का होता.
मेरे जीवन में efficiency बहुत महत्वपूर्ण है। उदाहरण के लिए, जब मैं रसोई में कुछ लेने जाता हूँ, तो साथ में कचरा या बर्तन भी ले जाता हूँ ताकि दो बार काम न करना पड़े। Software में भी कुछ ऐसा ही है। लेकिन ‘महँगा engineer time लगाकर optimize करना’ और ‘RAM/resources बढ़ा देना’ — इनमें दूसरा लगभग हमेशा सस्ता पड़ता है। जब समस्या काफी बड़ी हो जाती है तभी optimization लाभकारी बनता है। आख़िरकार बाज़ार तय करता है कि कौन-सा विकल्प बेहतर है। अगर extra hardware से मिलने वाला लाभ घटने लगे, तो ध्यान optimization की ओर जाएगा। Moore’s law अभी अपनी सीमा तक नहीं पहुँचा, इसलिए फिलहाल स्थिति ऐसी ही है.
अंततः यह demand की समस्या है। अगर consumers faster software को अधिक महत्व देंगे, तो वे उसके लिए ज़्यादा पैसे भी देंगे; लेकिन व्यवहार में, अगर performance कम हो लेकिन कीमत सस्ती हो, तो लोग वही चुन लेते हैं.
यही तो ‘enshitification’ की परिभाषा है.
Electron apps की performance को लेकर शिकायतें बहुत हैं, लेकिन Linux laptop पर कामकाजी environment को सहने योग्य बनाने वाली बड़ी innovations में यह एक है। उदाहरण के लिए, Teams meeting में बिना install किए आसानी से शामिल हुआ जा सकता है। लोग Winamp के code optimization को याद करें, लेकिन व्यवहार में Electron apps की accessibility सुविधाजनक है.
हाल में Balatro खेलते हुए लगा कि यह आज भी ऐसा game है जिसमें simple computation और basic graphics ही चाहिए, फिर भी उसकी minimum spec लगातार बढ़ती जा रही है। हैरानी होती है कि ऐसा game, जो शायद 90s के hardware (Pentium II + 3dfx) पर भी चल सकता था, अब practically modern laptop जैसी specs माँगता है.