सॉफ्टवेयर से मोहभंग

 (tonsky.me)
5 पॉइंट द्वारा GN⁺ 2023-10-24 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • आधुनिक सॉफ्टवेयर ने hardware की प्रगति को दक्षता·सरलता·परिपक्वता के रूप में लौटाने के बजाय, “computer काफी तेज़ है” इस धारणा पर भरोसा करते हुए अक्षमता को सामान्य बना दिया है
  • Web scrolling, Google Inbox में email खोलने में 13 सेकंड, Windows 10 update में 30 मिनट, text editor में input lag जैसे बुनियादी काम भी उम्मीद से धीमे महसूस होते हैं
  • Android system 6GB, Windows 10 4GB, Google Keyboard 150MB, Electron apps और Slack के उदाहरण दिखाते हैं कि apps और platforms का फूलना performance, complexity और reliability की लागत में बदलता है
  • OS·app·browser updates और iOS 11 में 32-bit app support बंद होने की तरह, कभी ठीक चलने वाला software भी समय के साथ धीमा पड़ सकता है या टूट सकता है
  • बेहतर software बनाने के लिए engineers को अपने बनाए systems की performance·structure·limits समझनी चाहिए, और कम resources में तेज़ व predictable results देने चाहिए

Performance बर्बाद करने वाला software

  • आधुनिक software को अक्सर इस तरह स्वीकार कर लिया जाता है कि वह संभव performance के सिर्फ 1% या 0.01% पर चले तो भी ठीक है
  • Cars, buildings और airplanes जहां भौतिक सीमाओं या optimal रूपों के करीब जाते हैं, वहीं software अपनी अक्षमता को “computer काफी तेज़ है” कहकर सही ठहराता है
  • “Programmer का समय computer के समय से महंगा है” वाली कहावत यह सच्चाई छिपा सकती है कि computer time अभूतपूर्व रूप से बर्बाद हो रहा है
  • रोज़ चलने वाले Python program को Rust में दोबारा लिखकर 1.5 सेकंड से 0.06 सेकंड कर दिया, लेकिन 6 घंटे की भरपाई होने में 41 साल से ज़्यादा लगेंगे—यह tweet efficiency बहस का प्रतिनिधि उदाहरण माना जाता है

असहनीय रूप से धीमा basic अनुभव

  • आज के portable computers चांद पर उतरने के दौर के computers से हजारों गुना शक्तिशाली हैं, लेकिन latest MacBook Pro पर भी web page को 60fps पर smoothly scroll करना मुश्किल है
  • Google का बनाया Inbox, Google Chrome में एक email खोलने में 13 सेकंड लेता है
    • Content के बजाय खाली सफेद box को animate करना, web page की performance सीमा के अनुरूप किया गया समझौता जैसा है
    • 120Hz displays के mainstream हो जाने पर भी web community की एक response देखने के लिए 60Hz भी स्थिर नहीं माना जाता
  • Windows 10 update में 30 मिनट लगते हैं, और तुलना की जाती है कि उतने समय में SSD format करके नया build download और install कई बार किया जा सकता है
  • आधुनिक text editors में 42 साल पुराने Emacs से ज्यादा input lag है
    • हर keypress पर सिर्फ एक छोटा rectangular area update करना हो, तब भी इसे 16ms में process नहीं कर पाते—ऐसा बताया जाता है
    • 3D games इसी 16ms में पूरी screen render, input processing, world calculation और resource management कर लेते हैं
  • तेज़ hardware अब बेहतर software चलाने के बजाय, वही काम और धीमे करने वाले software चलाने में इस्तेमाल हो रहा है

फूले हुए apps और platforms

  • Web apps सिर्फ ads block करने से 10 गुना तेज़ हो सकते हैं, और AMP कोई नई technology नहीं बल्कि फूले हुए हिस्से हटाने वाला common-sense समाधान जैसा है
  • Android system बिना किसी app के भी 6GB है, Windows 95 30MB था और Windows 10 4GB है
    • Windows 10, Windows 95 से 133 गुना बड़ा है, लेकिन basic features बहुत अलग नहीं माने जाते
    • Android, Windows 10 से भी 1.5 गुना बड़ा है
  • Google Keyboard आम तौर पर 150MB, Google app 350MB, और Google Play Services 300MB लेते हैं
    • आलोचना इस तरह की जाती है कि Google Keyboard तो screen पर तीस keys खींचने वाला app है—क्या वह पूरे Windows 95 से 5 गुना ज्यादा complex है?
    • Google Play Services इस्तेमाल न करने पर भी हटाया नहीं जा सकता
  • Basic apps install करने के बाद photos के लिए लगभग 1GB ही जगह बचना उस दौर से contrast करता है जब OS·apps·data सब floppy disk में रखे जाते थे
  • Electron-based Todo app में Xbox 360 controller driver, 3D graphics rendering, music playback और webcam capture तक शामिल हो सकते हैं
  • Slack, chat और simple text editor जैसा app होने के बावजूद, loading speed और memory usage के कारण भारी app की category में आता है
  • Apps जितने बड़े होते जाते हैं, control खोना, complexity cost, performance loss और reliability debt उतना बढ़ता है; अत्यधिक भारी apps को normal नहीं मानना चाहिए

समय के साथ सड़ता software

  • 3 साल पहले 16GB Android phone भी काफी था, लेकिन Android 8.1 के दौर में apps बिना किसी खास वजह के दोगुने होते गए और इस्तेमाल मुश्किल हो गया
  • iPhone 4s iOS 5 के साथ announce हुआ था, लेकिन iOS 9 चलाना उसके लिए भारी है, और iOS 9 मूल रूप से बहुत ज्यादा बेहतर भी नहीं है—ऐसा pointed out किया जाता है
  • iOS 11 ने 32-bit app support बंद कर दिया, जिससे जिन apps के developer नहीं हैं या जिन्हें update नहीं किया गया, वे फिर कभी दिखना बंद हो सकते हैं
  • एक tweet quote किया गया है कि DOS programs 1980s के बाद से कई computers पर बिना बदलाव चलते हैं, लेकिन JavaScript apps अगले Chrome update में भी टूट सकते हैं
  • आज ठीक चल रहा web page भी 10 साल के भीतर किसी भी browser में सही से न चल सके, ऐसा हो सकता है
  • वही काम करने के लिए नया phone और नया MacBook खरीदा जाता है, लेकिन अंत में वही apps और धीमे चलाने की स्थिति दोहराई जाती है

Quality expectations का गिरना

  • Web page में problem आए तो कारण देखने के बजाय refresh दबाने को कहा जाता है
  • Web apps compatible browsers में भी “random” JavaScript errors उगल सकते हैं
  • आलोचना की जाती है कि web pages और SQL database design इस उम्मीद पर बने हैं कि rendered web page देखते समय data बदलेगा नहीं
  • Collaboration features अक्सर “best effort” स्तर पर रह जाते हैं, जिससे data खोने जैसे रोज़मर्रा के scenarios छिपे रहते हैं
    • “कौन-सा version रखें?” जैसे dialogs का मतलब लगभग यह होता है कि अपने कामों में से किसे नष्ट करना है, चुनिए
  • Linux में arbitrarily processes kill करने वाला design होने पर भी servers पर यह सबसे popular operating system है
  • Dell monitor, AirDrop, Bluetooth के उदाहरण दिखाते हैं कि devices के भीतर का software और complex specifications ऐसा अनुभव बनाते हैं जो periodic reset या किस्मत पर निर्भर करता है
  • भरोसेमंद ढंग से काम करने वाली कोई चीज़ deliver करनी हो तो बनाई गई चीज़ को अंदर-बाहर समझना पड़ता है, लेकिन अत्यधिक फूले systems में यह मुश्किल है

Programming tools और development practices की अव्यवस्था

  • Package management, build systems, compilers, language design, IDE जैसे basic elements में भी तेज़, efficient और long-lasting maturity कम ही दिखती है
  • Build systems के पास हर change की जानकारी होने के बावजूद वे समय-समय पर सब कुछ मिटाकर फिर से करने को कहते हैं
    • इन्हें reliable, predictable और reproducible न बनाया जा सके, ऐसा कोई कारण नहीं माना जाता
    • NPM को कई वर्षों तक “कभी-कभी काम करता है” वाली स्थिति में बताया गया
    • एक tweet quote किया गया है कि rm -rf node_modules Node.js/JavaScript development में unavoidable जैसा दिखता है
  • Compilers और pre/post-processing में minutes या hours लगना स्वीकार कर लिया जाता है, जो “programmer का समय important है” वाली बात से टकराता है
  • Hadoop को एक PC पर चलाने से भी धीमी स्थिति में चुनने के उदाहरण दिखाते हैं कि programmers हमेशा rational decisions नहीं लेते
  • Machine learning और “artificial intelligence” ने software को भरोसा न किए जा सकने वाले guesses के दौर में पहुंचा दिया है—ऐसी आलोचना की गई है
    • एक tweet quote किया गया है कि जिन apps/services में “artificial intelligence” या “machine learning” लिखा हो, उन्हें unreliable, unpredictable और results explain करने में मुश्किल मानकर पढ़ा जाता है
  • Linux के ऊपर VM चलाना और VM के अंदर Docker रखना इस संकेत के रूप में देखा जाता है कि programs·languages·runtime environments को साफ-सुथरे तरीके से व्यवस्थित करना हमें नहीं आता
    • Go का single executable बड़ा advantage माना जाना यह दिखाता है कि बस mess न होना भी success समझा जा रहा है
  • Dependencies किसी simple problem को “पूरे package solution” से solve करने की कोशिश में adoption cost और दूसरी dependencies भी साथ ले आती हैं
  • Programs को बिना reboot के कई साल चलाना मुश्किल है, कभी-कभी कुछ दिन भी मुश्किल होते हैं—ऐसा pointed out किया जाता है
    • Process restart, database restart, हर 20 मिनट में app restart करने वाला watchdog, duplicated resources include करना और compressed transfer—ये ठीक करने के बजाय जल्दी आगे बढ़ने के तरीके हैं
  • ये practices engineering नहीं बल्कि आलसी programming हैं; engineering का मतलब है बनाई गई चीज़ की performance·structure·limits को गहराई से समझना

जमा हुई complexity और market की उदासीनता

  • मौजूदा software बस-चलने-लायक code के ऊपर फिर बस-चलने-लायक code चढ़ा हुआ है, और यह बढ़ता व complex होता जा रहा है, जिससे बदलने के मौके घटते हैं
  • स्वस्थ ecosystem में कभी-कभी पीछे हटकर आगे बढ़ने की प्रक्रिया चाहिए, लेकिन 25 साल में नया OS kernel नहीं देखा गया और अब दोबारा लिखने के लिए यह बहुत complex हो चुका है—ऐसा pointed out किया जाता है
  • Browsers में भी edge cases और historical problems के कारण layout engine को जमीन से फिर लिखना मुश्किल है
  • आज की progress ऐसी लगती है जैसे monolith problem solve करने के लिए microservices, microservices problem solve करने के लिए Docker, और Docker problem solve करने के लिए Kubernetes लाकर आग में घी डाला जा रहा हो
  • एक tweet quote किया गया है कि XML-based declarative settings से YAML-based microservices settings तक आ गए, लेकिन पुराने XML में कम से कम schema तो था
  • Users engineers द्वारा दी गई चीज़ें स्वीकार करने को मजबूर हैं, और Android app 350MB, अटकती scrolling, “काम न करे तो reboot” जैसी स्थितियों में भी विकल्प बहुत कम हैं
  • अगर competing products भी सभी धीमे, बड़े और low-quality हों, तो competitive pressure बनना मुश्किल है
    • iPhone/iOS और अन्य smartphones, Chrome और अन्य browsers की तरह कभी-कभी तनाव पैदा करने वाले products आते हैं, लेकिन यह लंबे समय तक नहीं चलता—ऐसा माना जाता है
  • Engineers का काम होना चाहिए कि वे दिखाएं आधुनिक computers से performance, reliability, quality और availability के मामले में क्या संभव है

फिर भी दिखते alternatives

  • Martin Thompson के LMAX Disruptor, SBE, Aeron impressive, simple और efficient examples माने जाते हैं
  • Raph Levien का Xi editor सही principles को ध्यान में रखकर बनाया गया माना जाता है
  • Jonathan Blow ने अपने game के लिए language बनाई, और उनके laptop पर 5 लाख lines of code 1 सेकंड में पूरी तरह fresh compile हो सकती हैं
    • यह incremental build या intermediate cache नहीं, बल्कि पूरा fresh compile result है
  • तेज़ programs लिखने के लिए genius या magic की जरूरत नहीं; बस उन्हें trendy toolchain जैसे विशाल कचरे के ढेर पर न बनाएं—ऐसा माना जाता है

बेहतर software के लिए मांग

  • Software engineering को मौजूदा स्थिति पर नहीं रुकना चाहिए, बल्कि बेहतर होना चाहिए; वही चीज़ दोहराकर और धीमे व बड़े रूप में बनाने की जरूरत नहीं
  • आज का development progress से ज्यादा ऐसे toolchain पर business goals किसी तरह पूरा करने जैसा है जो खुद लड़खड़ाते हैं
  • Local optimization में उलझने के परिणामस्वरूप हम फूले और inefficient state के आदी हो गए हैं—ऐसा pointed out किया जाता है
  • Engineers बेहतर tools से बेहतर apps कई गुना कम resources में तेज़, predictable और reliable तरीके से बना सकते हैं, और उन्हें ऐसा करना चाहिए
  • Reliable, predictable, high-quality products deliver करने के लिए पूरी तरह समझना जरूरी है कि क्या और क्यों किया जा रहा है; “जो मिला है वही है” वाला बहाना स्वीकार्य नहीं है

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

2 टिप्पणियां

 
xguru 2023-10-24

इस लेख का कोरियाई अनुवाद पहले ही आ चुका है, इसलिए आप वही देख सकते हैं.

https://tonsky.me/blog/disenchantment/ko/

मैंने इसे सीधे अनुवाद लिंक में बदल दिया है.
 
GN⁺ 2023-10-24
Hacker News की राय

  • छोटा, साफ़, कम bugs वाला, सुरक्षित, तेज़ और लंबे समय तक टिकने वाला code बनाना निश्चित रूप से संभव है। अगर सूचना युग के शुरुआती दिनों में हम यह कर पाए थे, तो दशकों के अनुभव और शक्तिशाली tools के साथ आज न कर पाने की कोई वजह नहीं है
    ऐसा न करने की वजह यह है कि इसमें पैसा नहीं है—असल में बात इसके उलट के करीब है। VC-funded startups को बचने के लिए पहले market में पहुँचना पड़ता है, और mature संगठनों में भी cost और bloat समस्या नहीं, बल्कि managers की prestige बढ़ाने वाले feature की तरह काम करते हैं। आखिरकार cost customers पर डाल दी जाती है
    “निर्दयी market principles” इस बर्बादी को ठीक क्यों नहीं करते, इसकी वजह शायद यह है कि बेहतर codebase कभी-न-कभी राज्य की चाबी हासिल कर सकता है, लेकिन असली competitive environment pathologies और trends के प्रति बहुत vulnerable है

    • Kagi ने VC funding नहीं ली, फिर भी उसमें suboptimal code, बहुत सारे bugs और इधर-उधर अजीब performance issues हैं। software development को समझने वाले के तौर पर मुझे लगता है कि funding source या company size चाहे जो हो, इससे बचना मुश्किल है; यह software की complexity, available resources और incentives का function है
      हालांकि VC-funded company की तुलना में जो काम आसानी से किया जा सकता है, वह है refactoring और technical debt handling के लिए समय allocate करना। असल में हम अभी 45 दिनों के लिए new feature development पर ज़ोरदार brake लगाकर major technical issues से निपट रहे हैं। अगर उम्मीद हो कि अगले साल acquisition हो जाएगा, तो ऐसा investment करना मुश्किल होता है, और technical debt किसी और की समस्या बन जाता है
      जब तक product develop होता रहेगा, नए bugs और issues आते रहेंगे। “perfect code” सिर्फ उस closed context में संभव है जहाँ अब new features जोड़े ही नहीं जाते
    • “इसमें पैसा नहीं है। असल में उलटा है” — यह बात दोहराने लायक है। यही वह बीमारी है जिसने software को निगल लिया है, और modern software को उसके संभवतः सबसे खराब version में बदल रही है
      मुझे लगता है VC funding model ने industry को इस दिशा में धकेला है। startups लाखों dollars लेते हैं, और investors को लौटाने लायक तेजी से पैसा कमाना पड़ता है, इसलिए app से जितनी जल्दी हो सके पैसा निचोड़ना पड़ता है। जिस काम के साथ ROI metric नहीं जुड़ता, उसमें किसी की दिलचस्पी नहीं होती
    • मुझे नहीं लगता कि पुराना software ज्यादा सुरक्षित था। बस computer users ज्यादा भोले और भरोसेमंद थे। जैसे-जैसे network से ज्यादा machines जुड़ीं, हमने बहुत कुछ सीखा
      मूल रूप से open access, कोई password नहीं या छोटे passwords, unsafe password storage, सब कुछ plaintext, input sanitization की अनदेखी, telnet जैसी चीज़ें थीं
      software के और ज्यादा bloated होने की एक और वजह भी यही है। हमने interactions और risks को देखना शुरू किया, और एक बार देखने के बाद अनदेखा नहीं कर सकते। जिन edge cases को handle करना है वे घट नहीं रहे, बढ़ रहे हैं, और support करने वाला hardware भी ज्यादा हो गया है
      performant code लिखने की प्रक्रिया बेहतर हो सकती है, लेकिन साथ ही baseline उस गति से भी तेजी से ऊपर जा रहा है जिस गति से हम पहुँचते हैं। यह भी दिलचस्प है कि अब हम धीरे-धीरे फिर से password-less direction की ओर जा रहे हैं
    • मैं सहमत हूँ कि incentives align नहीं हैं। कुछ industries ऐसी हैं जहाँ performance और correctness की वास्तविक value होती है। अगर लेखक की तरह आप software craftsmanship को महत्वपूर्ण मानते हैं, तो ऐसे क्षेत्र में जाना काम का आनंद लेने का सबसे अच्छा तरीका है
    • सरल शब्दों में, आप code release नहीं करते, बल्कि features release करते हैं। आप automatic dependency injection, elegant abstractions या शानदार compiler tricks release नहीं करते; आप ऐसे new features release करते हैं जिनके लिए customers पैसा देंगे
      high unit test coverage, जो refactoring को दर्दनाक बनाती है, अक्सर feature release में बाधा डालती है—और मेरी राय में test-driven development fanatics जितना मानना चाहते हैं, उससे कहीं ज्यादा बार। industry की कई “best practices” उन लोगों की बनाई unrealistic dogma जैसी हैं जो ऐसी companies में हैं जिन्होंने product-market fit पहले ही पा लिया है और जहाँ पैसा अपने-आप छपता है

  • मेरे पास अभी भी किसी तरह इस्तेमाल लायक HP MS200 all-in-one है। 2017 में मैंने इसे garage sale से सस्ते में खरीदा था, और Linux डालने पर Chrome load होने के बाद Skype web version पर full-screen video call या YouTube full-screen देखना भी संभव था
    हाल में इसे फिर से लिया और बच्चे के लिए computer बनाने से पहले FC38 और latest Chrome install किया, तो YouTube videos slideshow बन गए। settings कितनी भी बदलने पर बात नहीं बनी, इसलिए RAM को 2GB से 3GB किया, और यह 6 साल पहले जैसे 720p full-screen playback level पर लौट आया
    यानी वही काम करने के लिए memory 1.5 गुना, 1GB ज्यादा चाहिए हो गई। मुझे पता है कि लोग कहते हैं 16GB minimum है, लेकिन इस बेकार machine पर भी Chrome लगभग idle web browser होते हुए memory footprint करीब 30GB दिखाता है। ज्यादातर शायद mmap की हुई files होंगी, फिर भी 30GB है

    • YouTube performance difference दिखाने का अच्छा उदाहरण है। video quality latest codecs की वजह से बढ़ी है, लेकिन पुराने या सस्ते machines में latest GPU नहीं होता, इसलिए software decoding करनी पड़ती है, और कभी-कभी JavaScript से process करना पड़ता है—बहुत wasteful, लेकिन हर machine पर चलता है
      इसके उलट, ज्यादातर devices पर battery life में बढ़ोतरी, कम temperature, और कम RAM/disk requirements साफ़ improvement हैं। YouTube पुराने encoding files को server पर duplicate रख सकता है, लेकिन जब ज्यादातर users latest devices से access कर रहे हों तो यह space की बर्बादी बन जाता है
      Chrome की बढ़ी हुई RAM usage का अधिकांश हिस्सा sandbox architecture के विकास से आया है। shared memory और process space sandbox escape attacks में इस्तेमाल हो सकते हैं, इसलिए और isolation जोड़ा गया, और Chrome का हर tab/extension के लिए नया independent process शुरू करना भी बड़ा कारण है
      आजकल ad blockers का भी बड़ा असर है। web खराब होता गया है, इसलिए effective ad blockers बनाना मुश्किल हो गया है और वे ज्यादा resources मांगते हैं। slow software सिर्फ लोगों को परेशान करने के लिए slow नहीं हुआ; कई बार यह dangerous hacks को अच्छे implementation में बदलने और requirements बदलने का नतीजा होता है। FLV अब पर्याप्त नहीं है, और h264 भी h265 और AV1 के फैलने पर 5 साल बाद ज्यादा टिकता नहीं दिखता
    • web browsers असल में अपने-आप में operating systems बन गए हैं। “modern web” में बहुत ज्यादा features हैं, और वही feature भी अक्सर पाँच-छह competing तरीकों से implement होता है। modern hardware पर भी text rendering अकेले भारी बोझ बन सकती है
      modern toolchains “wheel को दोबारा invent मत करो” पर focus करती हैं, लेकिन अगर हर dependency ने wheel का अलग version चुना हो, तो कुछ dependencies खींचते ही same low-level feature की 6 implementations अंदर आ जाती हैं
    • हर बार नया Linux install करते समय मैं default UI को मौका देता हूँ, लेकिन आखिर में MATE पर लौट आता हूँ। मगर इस पुराने machine पर Gnome Shell काफी crisp response दे रहा था, app store भी था और Chrome भी था
      हालांकि जो install हुआ था वह Flatpak था, और bloat महसूस हुआ। अच्छी बात है कि Chrome अभी भी RPM के रूप में सीधे native install किया जा सकता है, और यह सचमुच OS की shared libraries इस्तेमाल करता है
    • मुझे याद है जब Linux/X11 पर graphical web browser चलाने के लिए 8MB चाहिए होता था। शायद वह Netscape Navigator था; 8MB काफी था, और 16MB हो तो थोड़ा ज्यादा आराम था

  • यह लेख मूल दर्द यानी bugs को छूता तक नहीं। लगभग हर software ऐसा लगता है जैसे उसमें जितने हो सकें उतने bugs भरे हों। जब भी software को किसी uncommon path या abnormal flow में इस्तेमाल करना पड़ता है, डर लगता है, और लगभग हमेशा वह fail हो जाता है
    कुछ समय पहले Carvana को कार बेचते समय मुझे Chrome और Firefox के बीच स्विच करते हुए जैसे-तैसे काम पूरा करना पड़ा। Chrome में image upload wizard JS exception दे रहा था, और वह हिस्सा किसी चमत्कार की तरह सिर्फ Firefox में चला, लेकिन बाकी site में इतनी दिक्कतें थीं कि साफ था Firefox पर testing नहीं हुई है
    इससे भी बुरी बात यह है कि non-technical users जब bug से टकराते हैं तो सोचते हैं कि उन्होंने ही कुछ गलत किया है। अगर software bloated और slow हो, लेकिन stable और solid हो, तो अब मैं उसे खुशी-खुशी स्वीकार कर सकता हूँ

    • एक तरफ, यह भरोसा करना मुश्किल है कि आज मौजूद चीजें इतनी अच्छी तरह चल भी रही हैं। हर layer duct tape और chewing gum से चिपकी हुई लगती है, फिर भी सच में काम करती है। मानवता ने जो हासिल किया है, वह हर दिन हैरान करता है
      दूसरी तरफ, लगातार दिखता रहता है कि सब कुछ कितना buggy है, और समझ नहीं आता कि software सच में ज्यादा buggy हो गया है या फिर अंदर की बातें जानने के साथ उम्र बढ़ने पर बड़े corporate-style software development के प्रति मेरी tolerance घट गई है। उन काल्पनिक product managers पर गुस्सा आता है जो साफ UX bugs आसानी से पकड़े जाने के बावजूद कहते हैं, “feature X अभी launch करो”
    • Jonathan Blow का “The End of the World” lecture देखने के बाद से ध्यान देने लगा, तो पता चला कि हम रोजमर्रा में जितने घटिया software experiences स्वीकार करके जीते हैं, उनकी संख्या चौंकाने वाली है
      cost, opportunity cost, pragmatism जैसी दलीलें समझता हूँ और कुछ हद तक सहमत भी हूँ, लेकिन कभी-कभी यह भावना हटाना मुश्किल होता है कि हमने बस आधी-अधूरी बनी दुनिया में रहना स्वीकार कर लिया है
    • जब मैं teenager था और first-gen MacBook Air आया था, एक दोस्त ने पता लगाया कि store demo machine पर Dock के apps को बस तेज़ी से लगातार खोलकर उसे reliably crash कराया जा सकता है। कुछ सेकंड click करने पर machine crash होकर reboot हो जाती थी
      आज भी लगता नहीं कि हालत बेहतर हुई है। छोटे बच्चे जब phone या laptop हाथ में लेते हैं, तो सिर्फ buttons को बहुत तेजी से दबाकर या unexpected order में दबाकर भी modern devices को काफी reliably hang, freeze और crash करा देते हैं। वे उसे physically तोड़ भी नहीं रहे होते, फिर भी modern technology की हालत यही है
      यह क्यों ठीक नहीं हुआ, समझ आता है। लोग उम्मीद करने लगे हैं कि कभी-कभी restart करना पड़ेगा, ऐसे cases में दोष बच्चे पर डालना आसान है, और restart करने से समस्या सुलझ जाती है। फिर भी operating system lifecycle को देखते हुए उम्मीद थी कि अब तक यह बेहतर हो गया होगा
    • https://danluu.com/everything-is-broken/
    • मुझे नहीं लगता कि software पहले से बहुत ज्यादा buggy हो गया है। जिन लोगों ने 90s के आखिर और 2000s की शुरुआत में Windows machines support की हैं, वे जानते हैं

  • C पर लिखे लेख में मैंने यह नहीं कहा था, लेकिन C इस्तेमाल करने का मेरा एक बड़ा कारण यह है कि इससे software को bloated बनाना मुश्किल होता है। features जोड़े जा सकते हैं, लेकिन किसी single feature से executable में 100KB जोड़ना भी आसान नहीं होता
    अभी मैं employed नहीं हूँ, लेकिन “work” के लिए एक powerful machine इस्तेमाल करता हूँ। फिर भी IDE के बजाय Neovim और tmux इस्तेमाल करता हूँ, typical Linux distro नहीं बल्कि heavily modified Gentoo, systemd के बजाय OpenRC, और full desktop के बजाय Qtile नाम का tiling window manager इस्तेमाल करता हूँ
    machine को bloated नहीं होने देता—boot करके अभी-अभी login करने पर सिर्फ 40 processes होते हैं। अभी मैं सचमुच software engineering कर रहा हूँ। C की समस्याओं को effective तरीके से mitigate करते हुए software को छोटा और तेज रखना चाहता हूँ, और उम्मीद है कि किसी दिन उसके ऊपर business बना सकूँगा
    लगता है देखना पड़ेगा कि non-bloated, snappy software के लिए अभी भी market है या नहीं
    https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-i...
    https://gavinhoward.com/2020/12/my-development-environment-a...
    https://gavinhoward.com/2023/06/an-apology-to-the-gentoo-aut...
    https://gavinhoward.com/2023/09/lessons-learned-as-a-user-3-...

    • दिलचस्प नजरिया है। मैं इतना पुराना हूँ कि वह दौर याद है जब C language को सीधे assembly में लिखने की तुलना में bloated माना जाता था
      1980s में WordPerfect, Lotus 123, MS-DOS 1.0, और Microsoft द्वारा acquisition से पहले का SubLogic Flight Simulator जैसे programs assembly में लिखे गए थे। उस समय industry observers मानते थे कि MS Word और MS Excel “bloated” C में लिखे गए थे, इसलिए Microsoft WordPerfect और Lotus 123 की तुलना में नए features पर ज्यादा तेजी से iterate कर सका और दूसरी architectures पर ज्यादा तेजी से port कर सका। वजह यह थी कि competitors assembly में बहुत लंबे समय तक अटके रहे
      personal software में भी वही trade-off दिखता है। ज्यादा lean C/C++ के बजाय ज्यादा high-level और “bloated” C#/Python इस्तेमाल करने पर कुछ काम बहुत जल्दी पूरे हो सकते हैं। मैं C++ में ज्यादा skilled हूँ और छोटे executables पसंद करता हूँ, लेकिन अगर C# मेरा desired काम ज्यादा जल्दी पूरा कर देता है, तो वह advantage मायने नहीं रखता। bloated software की समस्या का हिस्सा मैं भी हूँ
    • मेरे हिसाब से “real engineering” ऐसे फैसलों को trade-offs के spectrum पर रखना है, और project को creators और users की constraints के मुताबिक position करना है। नतीजतन कोई एक extreme तक जा सकता है, लेकिन इसका मतलब यह नहीं कि अलग constraints की वजह से किसी और जगह खड़े लोग “real engineering” नहीं कर रहे
      “दुनिया का सबसे मजबूत और सबसे हल्का पुल बनाऊँगा” एक अद्भुत काम है, और “customer जिस cost को afford कर सके, उसमें sufficiently हल्का और sufficiently मजबूत पुल बनाऊँगा” engineering है
    • आपने कहा कि किसी single feature से executable में 100KB भी जोड़ना मुश्किल है, लेकिन Unicode support करके देखें तो बात बदल जाएगी
    • “C की समस्याओं को effectively mitigate करना” वाले हिस्से को थोड़ा और समझा सकते हैं? जानना चाहता हूँ कि क्या आप language की अपनी समस्याएँ solve करना चाहते हैं, कोई नया C dialect इस्तेमाल कर रहे हैं, glibc static linking की मुश्किलों जैसी ecosystem problems की बात कर रहे हैं, या यह कोई पूरी तरह अलग बात है
    • “मैंने C++ job offer ठुकराया है” वाली बात से सहमत हूँ

  • आधे से थोड़ा ज़्यादा पढ़कर रुक गया, लेकिन मुख्य दावा ऐसा लगा कि software तेज़ होना चाहिए, और उस दर्शन की वैधता के लिए “बस यही सत्य है” जैसे संकेत के अलावा कुछ याद नहीं रहा। इस आपत्ति को माना गया कि कुछ मामलों में efficiency में सुधार, efficiency के पीछे लगाए गए समय की लागत की भरपाई कभी नहीं कर पाता, लेकिन उस तर्क से ठीक से जूझे बिना आगे बढ़ गया
    लेख की एक और मुख्य विशेषता थी data को cherry-pick करना और domains को बहुत ज़्यादा सरल बना देना। “आख़िर software उस समय और जगह का इस्तेमाल करके करता क्या है?” जैसी भावनात्मक अपील कई बार की गई, लेकिन उस सवाल का गंभीरता से जवाब देने की कोशिश नहीं की गई और जवाब न होने को ग़लत जवाब के सबूत की तरह इस्तेमाल किया गया। कई ऐसे software की तुलना भी की गई जिनमें feature parity नहीं थी, जैसे उनमें सिर्फ़ performance का ही फर्क हो
    inefficiency की सामाजिक, पर्यावरणीय और business costs और ज़्यादा efficient software पर कहने को बहुत कुछ है, लेकिन यह भी चर्चा लायक है कि आधुनिक software उन लोगों को भी, जो मूलतः कुछ नहीं बना पाते, अपने लिए ज़रूरी “खराब” चीज़ें बनाने देता है। जैसे structural engineer “काफ़ी मज़बूत” चीज़ चुनते हैं, आधुनिक developers भी अक्सर “काफ़ी तेज़” को लक्ष्य बनाते हैं
    बहस के लिए बहुत समृद्ध मुद्दे हैं, लेकिन यह लेख भावनात्मक गुस्से तक ही रहा और वास्तविक reasoning और arguments से नहीं निपट पाया। कुछ दावों में सच्चाई है, लेकिन मुझे लगता है कि लेख ने खुद साफ़ कर दिया कि वह चर्चा करना ही नहीं चाहता

    • user के नज़रिए से देखें तो software तेज़ होना चाहिए यह सच है। बस सोचिए कि आपने यह comment iPhone 4 पर लिखा या 14 पर, या workstation 4GB RAM वाले Pentium की है या नहीं
      network भी कुछ kbps वाले 2G के बजाय सैकड़ों Mbps वाले 5G या fiber line होने की संभावना ज़्यादा है। आखिर actions words से ज़्यादा बोलते हैं, और अगर पूरा समाज “ज़्यादा तेज़ software” के axiom का पालन करता है, तो इसे सच मान लेना चाहिए
      खासकर यह उसी जगह से निकला axiom है जहाँ से “developer का समय ज़्यादा मूल्यवान है” वाला दावा आता है, फर्क सिर्फ़ इतना है कि किसका समय बचाया जा रहा है
    • अगर महंगे M1 Mac पर code में कुछ सेकंड लगते हैं, तो potential users का काफ़ी बड़ा हिस्सा शायद कुछ मिनट इंतज़ार करे। non-technical users अक्सर इस बेतुकी स्थिति को यूँ ही स्वीकार कर लेते हैं, क्योंकि उन्हें पता नहीं होता कि performance नया hardware खरीदे बिना भी बहुत सुधर सकती है
      अगर developer low-end devices पर भी test नहीं करता, तो उसे यह समस्या बिल्कुल पता नहीं चलेगी। असली समस्या technical पहलू से ज़्यादा यह है कि code बहुत slow है, इस असुविधाजनक सच का सामना करते समय कुछ developers defensive हो जाते हैं और बहस करने लगते हैं। product manager के साथ बैठकर profiling और optimization के लिए समय तय करना चाहिए, और देखना चाहिए कि शुरुआत से फिर से बनाए बिना performance issues को कैसे कम किया जा सकता है
    • भावनात्मक गुस्सा अच्छा लगा। कभी-कभी data उस सच्चाई को धुंधला ही कर देता है जिसे हम पहले से जानते हैं। सबसे अच्छा software बनाने के लिए अपनी पूरी कोशिश करनी चाहिए, यह बताने के लिए data की ज़रूरत नहीं है, और यह लेख वही याद दिलाता है
    • “आधुनिक software लोगों को कोई खराब चीज़ बनाने देता है” में आधुनिक software में ठीक-ठीक क्या खास है, यह समझ नहीं आता। यह भी स्पष्ट नहीं है कि किस आधार पर उसे modern माना जा रहा है
      BASIC और SQL का भी बहुत पहले से उद्देश्य लोगों को कोई “खराब” चीज़ बनाने देना था, और Fortran तथा अब गायब हो चुकी कई languages और technologies के साथ भी यही था
      Python या Java को उदारता से देखें तो भी वे conservative हैं, और 70s की programming language progress को देखते हुए उन्हें असल में anachronistic कहना चाहिए। J या Prolog conceptually Rust या Go से कहीं आगे हैं, लेकिन वे पहले बने थे। C89 से C23 तक जमा हुआ C modern language है या सिर्फ़ C23 modern है, और C89 तथा C23 के बीच सच में इतना बड़ा फर्क है या नहीं, यह भी अस्पष्ट है
      अगर बनाने का समय या कोई काल्पनिक evolutionary tree मानदंड नहीं है, तो जानना चाहूँगा कि modernity को परिभाषित करने का कोई और तरीका है क्या
    • लेख की शुरुआत में “सिर्फ़ software में ही program को संभव performance के 1% या 0.01% पर चलना भी ठीक माना जाता है। लगता है सबको यह ठीक लगता है” वाले paragraph में लेखक ने अपने ही सवाल का जवाब दे दिया। अगर सबको ठीक लगता है, तो आगे बढ़ जाना चाहिए

  • यह पुरानी शिकायत है। जिन कई सुविधाओं को हम स्वाभाविक मानते हैं, उनकी लागत होती है, और वह लागत बहुत जमा होती जाती है। 4K screen में 800x600 से 17 गुना ज़्यादा pixels होते हैं और वह 32-bit color इस्तेमाल करती है, इसलिए आधुनिक displays के लिए graphics का raw size लगभग 68 गुना बड़ा हो जाता है
    पहले static image काफ़ी होती थी, लेकिन अब high-quality high-frame animation standard है। Arial Unicode 15MB का font है, और Windows 95 चलाने वाले ज़्यादातर computers की memory में शायद फिट भी नहीं होता
    हर जगह spell check को अब default माना जाता है, और ऐसी चीज़ें जुड़ती जाती हैं। फिर भी ये computer को बहुत ज़्यादा आरामदेह बनाती हैं। 16-color video mode, या बहुत झुंझलाने वाले workarounds के बिना English के अलावा दो languages साथ में न इस्तेमाल कर पाने वाले दिन याद नहीं आते

    • उन्हीं 4K और Unicode constraints के भीतर भी कई orders of magnitude ज़्यादा efficient apps हैं, इसलिए सिर्फ़ इससे explanation नहीं मिलती
    • cost है, यह सही है, लेकिन वह cost हमेशा worth it नहीं होती। 4K screen चाहिए और उन pixels की कीमत चुकाने को तैयार हूँ
      लेकिन सिर्फ़ इंतज़ार के समय को कम बोरिंग दिखाने के लिए animation नहीं चाहिए। Unicode भी cost चुकाने लायक है
      फिर भी, 1981 की तरह glyphs को single-digit milliseconds में screen पर draw कर पाना चाहिए। pixels और glyphs ज़्यादा हो गए हैं, लेकिन यह possible है; बस priority नहीं है
    • यह समझ आता है कि हर output बहुत ज़्यादा resources खाता है, लेकिन यह explanation चाहिए कि 100 गुना ज़्यादा compute resources इस्तेमाल करने के बाद भी software अब भी दर्दनाक रूप से slow क्यों है
      यह वैसा है जैसे performance BMW के लिए 100,000 dollars दिए हों और engineer कहे कि 0-60mph में 30 seconds लगेंगे, और user performance expert नहीं है इसलिए उसे वैसे ही स्वीकार करना चाहिए

  • मौजूदा संगठन में भी मैंने ऐसा ही रुझान देखा। शुरुआत में जब टीम छोटी थी, तो बारीकियां मायने रखती थीं। चीजें धीमी नहीं होनी चाहिए थीं, animations smooth होने चाहिए थे, scroll speed और loading time महत्वपूर्ण थे, और लक्ष्य user efficiency बढ़ाने के लिए सबसे efficient product बनाना था
    टीम बड़ी होने पर value developer efficiency बढ़ाने की तरफ मुड़ गई। अधिक abstractions, layers और frameworks आ गए, और एक developer का एक दिन बचाने के बदले सभी users के लाखों seconds खर्च करने वाला trade-off स्वीकार्य हो गया
    फर्क visibility में है। management development-side costs देख सकता है, लेकिन थोड़ा तेज execution time, बेहतर caching, या ज्यादा smooth scrolling के लाभ नहीं देख पाता, क्योंकि वे मापे नहीं जाते। जब संगठन उस बिंदु पर पहुंचता है जहां वह केवल measurable numbers की परवाह करता है, तो यह रुझान स्वाभाविक दिखता है

    • आने वाले कुछ वर्षों में LLM code quality और performance पर जो विनाशकारी असर डालेंगे, उसका इंतजार कीजिए। नए programmers की लहर “GPT whisperers” है, जो IDE के अंदर भी chatbot से चिपके रहकर अपना ज्यादातर समय बिताते हैं और chatbot से ही programming करवाते हैं
      बेशक, यह तब तक की बात है जब तक AI उस स्तर तक नहीं पहुंच जाता जहां वह हमारी गलत लिखी चीजें, या AI की गलत लिखी चीजें, और जैसा मूल लेख अनुमान लगाता है, खुद बेहद inefficient AI को भी ठीक कर सके
    • यह सिर्फ measurability नहीं, बल्कि profitability का भी सवाल है। capitalism efficient products नहीं, efficient production पैदा करता है, क्योंकि उसे production system से profit निकालने में ही दिलचस्पी होती है
      cars का optimization बाहरी oil shock आने के बाद ही हुआ, और वह भी बहुत uneven तरीके से। असल में inefficient products अक्सर ज्यादा profitable होते हैं क्योंकि customers को उन्हें अधिक बार replace करना पड़ता है। एक साल बाद फट जाने वाली घटिया iPhone cable Apple को replacement के पैसे बार-बार लेने देती है। white goods ज्यादा बार खराब होते हैं, लेकिन उन्हें सस्ता बनाया जाता है जिससे per-unit profit बढ़ता है। अहम बात sale के बाद usage efficiency नहीं, production efficiency है
      software में capitalism नए automation को जितनी जल्दी हो सके बाहर फेंकने और consumers पर energy और time waste का बोझ डालने के रूप में काम करता है। production chain लगातार standardize और optimize होती जा रही है, ताकि React developers या Kubernetes administrators को warehouse workers की तरह replace किया जा सके, और इससे wages पर दबाव भी बनता है। कुछ automation तो accounting terminology को उलझाकर job को justify करने जैसा self-justification लगता है, और बाकी सब profit के बारे में है

  • हर चीज की cost होती है। अगर computation cost या खराब user experience काफी बड़ा हो, तो efficiency optimize की जाती है। ML models इसका उदाहरण हैं। दूसरे मामलों में optimization नहीं होता, क्योंकि end users कम features स्वीकार करके भी उसे नहीं चाहते
    cars भी पहले बहुत fuel खाती थीं, लेकिन fuel cost और environmental concerns के कारण customers कुछ और चाहने लगे, तो यह बदला। कई engineers भूल जाते हैं कि उन्हें customers के लिए products बनाने के पैसे मिलते हैं
    और लगता है कि मूल लेखक ने कभी पुराने Windows या Linux machine के पूरी तरह boot होने का इंतजार नहीं किया। modern versions बहुत तेजी से boot होते हैं क्योंकि customers यही चाहते थे। phones 24 घंटे on रहते हैं, इसलिए कुछ महीनों में एक बार boot में देर लगना customers को परेशान नहीं करता

    • boot time अब भी बेहद खराब है। खासकर latest AM5/DDR5 systems पर
      मेरा BIOS POST में लगभग 20 seconds लेता है, और कहा जाता है कि यह normal है। उसके बाद OS boot लगभग 10 seconds का है
    • पता नहीं customers के पास meaningful choice या अपनी preference व्यक्त करने का साधन कब था। लंबे समय से यह supply-driven market रहा है, जहां suppliers जो बनाना चाहते हैं वह बनाते हैं और customers बाजार में उपलब्ध चीजें खरीदते हैं
    • school PC पर WordPerfect boot होने में सचमुच कई minutes लगते थे
    • “engineers को customers के लिए products बनाने के पैसे मिलते हैं” यह बात कुछ हद तक सही है, लेकिन software कई मायनों में बिजली या healthcare services की तरह मानव जीवन का core element बन गया है
      यह भी कहा जा सकता है कि doctors या engineers को नई दवाएं या नए power sources develop करने के पैसे मिलते हैं, लेकिन ये क्षेत्र संवेदनशील और महत्वपूर्ण हैं इसलिए इनमें government control की कई layers मौजूद हैं। software में अभी उस स्तर का control नहीं है
    • आंशिक रूप से सही है, लेकिन जब Google या Apple जैसी scale वाली कंपनियां दिशा तय करती हैं, तो उन्हें छोटी या medium companies की तरह customer will का पालन करने का नाटक नहीं करना चाहिए
      उनके पास environment को खुद shape करने की शक्ति है, इसलिए वे “customer demand” के नतीजे को बड़े पैमाने पर दिशा बदल सकते हैं

  • यह लेख 2018 का है, और इस पर पहले भी कुछ discussions हुए थे
    https://news.ycombinator.com/item?id=18012334 (Sep 2018)
    https://news.ycombinator.com/item?id=21929709 (Jan 2020)
    https://news.ycombinator.com/item?id=31798580 (Jun 2022)

  • गहराई से सहमत हूं। developer के रूप में यह याद रखना महत्वपूर्ण है कि हमारे पास choices होती हैं। हम हर चीज पर choice नहीं कर सकते, लेकिन कम खराब alternative चुन सकते हैं
    Node का इस्तेमाल करना जरूरी नहीं है। .NET या JVM ecosystem में भी शानदार और backward-compatible software लिखा जा सकता है, और उम्मीद की जा सकती है कि वह 10 साल बाद भी बिना modification चलेगा
    single-page webpage बनाना भी जरूरी नहीं है। हर click पर page को पूरी तरह reload करने वाला old-school HTML भी अच्छा काम करता है, और इस समय तो शायद उसका latency और कम हो
    desktop app को Chromium से बनाना भी जरूरी नहीं है। UI framework शुरू करने में थोड़ा अधिक काम लगता है, लेकिन quality उसके लायक होती है। decision power हमेशा नहीं होती, लेकिन जब होती है, तो खराब choices से बाहर निकलना चाहिए

    • आजकल “हर चीज SPA होनी चाहिए” वाला mindset दुखद है। GMail जैसी complex app को SPA से फायदा मिलता है, यह समझ आता है, लेकिन बहुत जगह basic CSS/HTML और थोड़े jQuery से वही functionality कहीं कम समय और कहीं कम bugs के साथ बनाई जा सकती है, फिर भी frontend complexity पर जोर दिया जाता है
    • .NET ecosystem में backward-compatible software अच्छी तरह लिखे जा सकते हैं, यह सुनकर खांसी आती है। .NET Core initiative ने सचमुच बहुत सारा code तोड़ दिया, और Microsoft ने बहुत सारी libraries बंद कर दीं। बेशक उनमें से कुछ के पीछे बहुत अच्छे reasons थे, और कई legacy .NET libraries में design choices काफी खराब थीं