Cold-blooded Software

 (dubroy.com)
3 पॉइंट द्वारा GN⁺ 2023-12-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • कुछ software projects warm-blooded होते हैं, जिन्हें बनाए रखने के लिए लगातार development activity चाहिए होती है; और जो activity रुक जाने के बाद भी फिर से आगे बढ़ाए जा सकते हैं, वे cold-blooded के अधिक करीब होते हैं
  • Cold-blooded projects में ऐसी boring technology चुनी जाती है ताकि लंबे समय तक रुके रहने पर भी build और tests टूटें नहीं, और वे ऐसे external service dependencies से बचते हैं जो बदल सकती हैं या गायब हो सकती हैं
  • जिन projects में activity कम होती है, उन्हें फिर से शुरू करते समय dependent service का अधिग्रहण या बंद होना, compiler upgrade, और package support बंद होना maintenance cost बनकर लौटता है
  • Personal projects जैसे code, जिन्हें 1, 2, 3 साल तक छुआ नहीं जाता, उनमें लगातार “heat” बनाए रखना मुश्किल होता है, इसलिए उन्हें शुरुआत से ही low change rate मानकर design करना चाहिए
  • Blog के लिए static site generator 2012 के पहले commit के बाद से Python 2, repository में शामिल 4 third-party modules, local execution, और rsync over ssh deployment के दम पर लगभग बिना बदलाव के लगातार चलता रहा है

Cold-blooded animals की उपमा से project maintenance को समझना

  • 2004 की natural history lecture में professor ने freezer से निकाले गए painted turtle hatchling को camera के नीचे रखकर lecture दिया
  • Painted turtle hatchling उन कुछ species में से एक था जो जमी हुई अवस्था में भी जीवित रह सकती थीं
  • एक घंटे के दौरान turtle ने लगभग न दिखने वाली हरकत से शुरुआत की, और आखिर तक screen का लगभग आधा हिस्सा पार कर गया
  • Warm-blooded animals को body temperature की एक संकरी range बनाए रखनी होती है, और humans में लगभग 37°C के आसपास से हटने पर समस्या होने लगती है
  • Cold-blooded animals surrounding temperature के हिसाब से अपना metabolism adjust करते हैं; गर्म होने पर active होते हैं और body तथा environment जितने ठंडे होते जाते हैं, उतने धीमे चलने लगते हैं
  • Software projects भी इसी तरह बाँटे जा सकते हैं
    • Warm-blooded software तब अच्छी तरह चलता है जब project में लगातार movement और heat बनी रहे
    • अगर इसे 6 महीने रोककर रखा जाए, तो दोबारा निकालने पर यह किसी dead project जैसा हो सकता है

Cold-blooded software की शर्तें और उदाहरण

  • Warm-blooded project को फिर से शुरू करना इसलिए मुश्किल हो जाता है क्योंकि external changes जमा होते जाते हैं
    • CI जिस service पर निर्भर है, उसका acquisition हो सकता है या पैसे खत्म होने से वह काम न करे
    • नई dependency जोड़ते समय compiler upgrade की जरूरत पड़ सकती है
    • कोई दूसरा package support बंद होने की वजह से latest compiler के साथ काम न करे
  • अकेले काम करते हुए, जब inspiration आए तभी बदलाव करने और फिर 1 साल से अधिक समय तक project को न छूने वाले projects को warm-blooded तरीके से चलाना मुश्किल है
  • Cold-blooded project को जमे हुए painted turtle hatchling की तरह, 1 साल बाद भी उसी जगह से फिर शुरू किया जा सकना चाहिए जहाँ वह रुका था
  • इसके लिए boring technology का इस्तेमाल किया जाता है, और build/test scripts को ऐसी external services पर निर्भर नहीं रखा जाता जो बदल सकती हैं, टूट सकती हैं या पूरी तरह गायब हो सकती हैं
  • Dependencies को vendored dependencies की तरह project repository के अंदर शामिल किया जाता है
  • इस blog को चलाने वाला software cold-blooded project का उदाहरण है
    • पहला commit 8 जनवरी 2012 को था, और यह एक पुराने Wordpress installation को replace करने के लिए छोटा static site generator था
    • यह Python 2 में लिखा गया था, 4 third-party modules पर निर्भर है, और सभी project repository में commit किए गए हैं
    • सारी process local पर चलती है, और output rsync over ssh से deploy होता है
    • कुछ छोटी improvements को छोड़कर यह बिना बदलाव के लगातार चलता आया है, और उम्मीद है कि 12 साल बाद भी चलता रहेगा

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

1 टिप्पणियां

 
GN⁺ 2023-12-29
Hacker News की राय

  • Node और JavaScript ecosystem का web framework Express इस समय भी 10 साल से ज़्यादा समय से अपने मुख्य version 4.x.x पर बना हुआ है https://www.npmjs.com/package/express?activeTab=versions
    फिर भी यह हर हफ्ते 1,700 लाख से अधिक डाउनलोड होने जितना व्यापक रूप से इस्तेमाल होता है https://www.npmjs.com/package/express, और भले ही इसमें features कम हों या performance सबसे बेहतरीन न हो https://fastify.dev/benchmarks/ तेज़ और स्थिर development तथा long-term planning संभव होना इसकी बड़ी खूबी है
    पुराने version के security patch बंद होने या अचानक API बदल जाने की चिंता नहीं करनी पड़ती, और Go तो अपनी व्यापक standard library और compatibility promise की वजह से 10 साल से पुराने program भी चला सकता है, इसलिए और भी स्थिर है https://go.dev/doc/go1compat

    • यह जानकर सुखद आश्चर्य हुआ कि Express को पहले ही 13 साल हो चुके हैं
      जब यह पहली बार आया था, तब सिर्फ JavaScript में लिखा होने की वजह से इसे अक्सर घटिया नकली programmers के लिए बना कचरा समझा जाता था, लेकिन बाद में इसने कई कंपनियों को Express पर असली पैसे कमाने वाली शानदार services बनाने में मदद की, और अब तक यह शायद भारी मात्रा में requests संभाल रहा होगा
      आजकल मैं Go में भी बहुत कुछ लिखता हूँ, लेकिन अब भी Express से service बनाना से पूरी तरह संतुष्ट हूँ और कुल मिलाकर इसे अच्छा software मानता हूँ
    • कहा जा रहा है कि Express v5 जल्द ही आने वाला है (https://github.com/expressjs/express/issues/4920)
    • CakePHP भी ऐसी ही स्थिरता देता है, और इसी वजह से RoR से मन हट जाता है
      असल में नापसंद नहीं है, लेकिन लगातार version upgrade के चक्कर की वजह से शायद मैं इसे नहीं चुनूँगा

  • Python, cold-blooded software के उदाहरण के रूप में काफ़ी खराब है
    runtime और tools दोनों तरफ breaking changes लगातार आते रहते हैं, और लिखने वाले की स्थिति यह है कि उसे अभी भी बहुत पहले support खत्म हो चुके Python 2 का इस्तेमाल करना पड़ रहा है
    इससे बेहतर उदाहरण Go या Java जैसी भाषाएँ हैं, जिनका 10 साल पुराना code भी modern tools पर ठीक चलता है, और उससे भी चरम उदाहरण Perl है, जिसका 30 साल पुराना code भी अब तक सही चलता है

    • सही बात है
      software बनाते समय अक्सर ऐसी गलती हो जाती है कि users को कुछ ऐसा करने की छूट मिल जाती है जो असल इरादे में नहीं था, और Java की दुनिया में इसका हल आम तौर पर यह होता है कि नया, ज़्यादा सुरक्षित और ज़्यादा स्पष्ट feature जोड़ा जाए और users को धीरे-धीरे उस पर जाने के लिए कहा जाए
      Python भी कुछ हद तक ऐसा करता है, लेकिन उसके साथ यह भी जुड़ जाता है कि “और जल्द ही पुराना feature बंद कर दिया जाएगा”, जबकि Java ऐसा नहीं करता
      उदाहरण के लिए java.net.URL का equals method खराब design के लिए जाना जाता है और इसे सख्ती से discourage किया जाता है, फिर भी 20 साल से ज़्यादा समय से support किया जा रहा है
      Python Airflow के empty operator ने कुछ समय तक DummyOperator नाम support किया, लेकिन क्योंकि “dummy” शब्द का ऐतिहासिक और सांस्कृतिक रूप से अपमानजनक इस्तेमाल हुआ है, maintainers ने इसे EmptyOperator में बदलते हुए पुराना नाम तोड़ दिया
      upgrade करने पर reference name बदलने से पहले ही code load होने के समय error आता था, और निजी तौर पर मुझे नहीं लगता कि मैं users को इस तरह तोड़ना चाहूँगा
      Java की दुनिया में नाम बदलने जैसी चीज़ के लिए text replacement काफ़ी होता, इसलिए जब तक इसे हटाने की मजबूरी न हो, इसे support मिलता रहता
      इसलिए कुल मिलाकर मुझे लगता है कि Java और Java library dependencies को Python की तुलना में कहीं ज़्यादा बेफ़िक्री से upgrade किया जा सकता है
    • Maven शानदार है
      अगर Java का LTS version इस्तेमाल करें और अच्छी dependencies चुनें, तो चीज़ों को कभी भी दोबारा चलाने लायक बनाया जा सकता है
      Python में machine learning class के दौरान एक dependency ने रातोंरात API में breaking change डाल दिया था, और instructor को इसका पता नहीं चला क्योंकि वह class की तैयारी शुरू करने के कुछ हफ्ते पहले का जो latest version था, वही इस्तेमाल कर रहा था
    • “लगातार breaking changes आते रहते हैं” से आपका मतलब क्या है, यह साफ़ नहीं है
      Python 2 से 3 में जाना breaking change था, लेकिन वह एक बार का बदलाव था, “लगातार होने वाले breaking changes” नहीं
      अगर आप उसी major version पर रहें, तो नए minor version में पुराना code नहीं टूटता; जैसे पुराना 2.x code, 2.7 पर ठीक चलता है और पुराना 3.x code, 3.12 पर भी ठीक चलता है
      minor version बदलावों में नए features जुड़ सकते हैं, लेकिन सिर्फ इसलिए कि पुराना 3.x code async keyword या type hints का इस्तेमाल नहीं करता, वह टूट नहीं जाता
    • सहमत हूँ
      जहाँ संभव हो, Python से बचने की एक वजह यही है
      मुझे कम भरोसा है कि आज लिखा Python code कुछ साल बाद भी चलेगा, और मेरे हिसाब से यह काफ़ी बड़ी समस्या है
    • “10 साल पुराना Java code modern tools पर भी ठीक चलता है” इस बात पर मुझे यक़ीन नहीं है
      नए SDK के साथ 3 साल पुराना Java code चलाने की कोशिश भी करूँ, तो हमेशा कहीं न कहीं कुछ न कुछ टूट जाता है

  • मैं IBM mainframe (z/OS) पर काम करता हूँ, और backward compatibility बनाए रखने के मामले में IBM के आसपास भी बहुत कम लोग दिखते हैं
    मुझे लगता है Microsoft Windows दूसरे स्थान पर है, Linux kernel ABI लगभग तीसरे पर, लेकिन पूरे Linux ecosystem को देखें तो यह उसका सिर्फ़ एक छोटा हिस्सा है
    बाकी ज़्यादातर चीज़ें churn के क़रीब लगती हैं, और open source में compatibility बनाए रखने पर शौक़ से समय खर्च करना चाहने वाले लोग कम ही दिखते हैं
    आर्थिक रूप से यह prisoner’s dilemma जैसा लगता है, जहाँ हर कोई compatibility बनाए रखने की लागत दूसरों पर डालना चाहता है, और नतीजे में सबके लिए बेकार का काम और बढ़ जाता है

    • open source में नई और चमकदार चीज़ों के पीछे भागने की प्रवृत्ति ज़रूर है, लेकिन यह कहना मुश्किल है कि यह सब पर लागू होती है
      उदाहरण के लिए retro computing community को देखें, तो नए hardware को पुराने operating system पर चलाने के लिए driver लिखना कोई दुर्लभ बात नहीं है
    • maintenance के लिए पैसे मिलें तो निश्चित रूप से बहुत मदद मिलती है
      अगर भुगतान न हो, तो आख़िरकार बात इस पर आ टिकती है कि आप जिस platform को बना रहे हैं उससे कितना लगाव रखते हैं, और मैंने ABI stability के प्रति सिद्ध प्रतिबद्धता के कारण Linux kernel को सीधे system calls के ज़रिए target करने का फ़ैसला किया
      दूसरी ओर, जो programming language मैंने खुद बनाई है, उसे मैं जितना संभव हो उतना “perfect” बनाना चाहता हूँ, इसलिए उसे लगातार सुधारते रहने का मन करता है
      कहीं कोई उसे पागलों की तरह इस्तेमाल न करने लगे, इस डर से मैंने README में पहले ही लिख दिया है कि यह अभी शुरुआती development stage में है और unstable है
      मुझे लगता है Ruby या Python बनाने वाले लोग भी ऐसा ही महसूस करते होंगे; जब भाषा अपने बच्चे जैसी लगती है और आप चाहते हैं कि वह सफल हो, तो print के keyword होने जैसी ग़लतियों को ठीक करना ज़रूरी लग सकता है
    • यह सिर्फ़ backward compatibility की समस्या नहीं है; अगर थोड़ी देर तक ध्यान न दिया जाए, तो random वजहों से टूटने की संभावना भी बहुत ज़्यादा होती है
      बल्कि backward compatibility के लिए बनाए गए हिस्से भी अक्सर टूट जाते हैं
      पिछली नौकरी में हमने containerized Node app बनाए थे, और CI, Node source से image build करता था; कुछ समय से बिना छुए पड़े services के deploy अचानक fail होने लगे
      बाद में पता चला कि Dockerfile, support period ख़त्म हो चुकी Ubuntu image पर आधारित था, और update repository archive repository में चली गई थी, इसलिए Dockerfile ठीक किए बिना image build ही नहीं हो सकती थी
      यह उस software का उदाहरण है जो बिना छुए भी टूट जाता है, और इसी वजह से मैं Go और single binary को पसंद करता हूँ
      एक बार release के रूप में package कर दें, तो दोबारा build करने की ज़रूरत नहीं होती, और Distroless Docker image में मेरी binary के अलावा कोई dependency नहीं होती
      मैंने Go को लंबे समय तक इस्तेमाल किया है, लेकिन software के उम्र बढ़ने के साथ खराब होने वाली समस्या कभी नहीं देखी; Node या PHP के साथ जो कई तरह की समस्याएँ महसूस होती थीं, वे ग़ायब हो गईं
      Node की दुनिया में दूसरी सबसे बड़ी समस्या framework के indirection patterns हैं, और पहली package management है
      “मैंने X version install किया, लेकिन Y module को Z version चाहिए” जैसी peer dependency समस्याएँ बार-बार सामने आती रहती हैं

  • GitHub पर library खोजते समय बहुत से engineers आख़िरी commit का समय देखते हैं
    अक्सर यह मान लिया जाता है कि जितनी हाल की commit होगी, library उतनी बेहतर supported होगी
    लेकिन अगर कोई archived project वही काम ठीक-ठीक करता है जो आपको चाहिए, उसमें bugs 0 हों, और वह कई सालों तक stable रहा हो, तो वह किसी सेकंड-हैंड दुकान में छिपा हुआ रत्न मिलने जैसा है
    आजकल बहुत से engineers ऐसी libraries को अपने-आप ख़ारिज कर देते हैं जो “लगातार” update नहीं होतीं, मानो यही अच्छी बात हो

    • किसी library के स्थिर बने रहने के लिए उसका इस्तेमाल होने वाला environment भी स्थिर होना चाहिए
      आधुनिक software development environment में अक्सर ऐसा नहीं होता, और web frontend इसका सबसे आम उदाहरण है जहाँ चीज़ें बार-बार बदलती हैं
      अगर library पूरी तरह standalone हो, तो updates न होने पर भी शायद ठीक रहे, लेकिन web frontend framework पर निर्भर library अगर ecosystem के बदलावों के साथ update न हो, तो समस्या पैदा करती है
    • सख़्ती से कहें तो यह हमेशा सही नहीं होता, लेकिन हाल का update हुआ है या नहीं देखना एक बेहतरीन heuristic है
      मेरे पास वास्तविक आँकड़े नहीं हैं, लेकिन ज़्यादातर मामलों में हाल की activity न होना “पूरा हो चुका और bug-free” नहीं, बल्कि “छोड़ दिया गया” ही होता है
    • मैंने ऐसे graphs देखे हैं जो दिखाते हैं कि programming languages समय के साथ कैसे बदलीं और मूल code का कितना हिस्सा बचा रहा
      कुछ भाषाएँ version 1.0 से लगभग पूरी तरह अलग हो गईं, जबकि कुछ ने अपने अधिकांश लिखे गए code को बनाए रखा और बस उसके ऊपर परतें जोड़ती गईं
      आख़िरकार वही प्रवृत्ति community और ecosystem में भी दिखाई देती है
      मुझे याद है कि Clojure सूची में ऊपर था क्योंकि वह breaking changes लगभग नहीं करता, और 5 साल पहले आख़िरी बार बदली गई library भी मौजूदा language version पर बिलकुल ठीक चलती है
      शायद Lisp family का होने के कारण भी मदद मिलती है, क्योंकि language core को upstream changes के बिना extend किया जा सकता है, हालाँकि स्वाभाविक रूप से उसकी अपनी कमियाँ भी हैं
      फिर भी, इसने मुझे यह सोचना बंद करने में मदद की कि “fresh” मतलब “great” होता है
      आजकल मैं पिछले साल बनी नई library की तुलना में, कई साल पुरानी और लगभग न बदली हुई libraries ज़्यादा इस्तेमाल करता हूँ, और कोई बड़ी समस्या नहीं होती
    • यह language पर निर्भर करता है
      कुछ languages हर 1~2 साल में release होती हैं, और वे ऐसे नए, elegant syntax या standard library abstract data types जोड़ती हैं जो पहले आम लेकिन awkward patterns को replace कर देती हैं
      उस language community में नया syntax लगभग तुरंत “idiomatic” माना जाने लगता है, और पुराने, भद्दे तरीक़े से लिखा code ऐसा माना जाता है जिसे ठीक किया जाना चाहिए
      किसी खास codebase को बदलने की वजह आमतौर पर यह होती है कि नया syntax आने के बाद पुराना तरीका ज़्यादा अस्पष्ट लगता है और maintenance व code review को मुश्किल बना देता है
      तर्क यह होता है कि अगर नया syntax शुरू से मौजूद होता, तो कोई भी पुराने तरीके को अच्छा code नहीं मानता; इसलिए नए developers के लिए readability बढ़ाने और contribution की entry barrier घटाने के लिए code को update करना चाहिए
      ऐसी language में लिखी हुई library अगर 3 साल से ज़्यादा समय तक update न हुई हो, तो यह अक्सर खराब संकेत होता है
      इसका मतलब यह हो सकता है कि developer community से इतना जुड़ा नहीं है कि code को language के नवीनतम रूप को सीख चुके दूसरे developers के लिए आसानी से पढ़े जाने लायक idiomatic रूप में बनाए रखे, और शायद उसे बाहरी PRs लेने में भी रुचि न हो
    • अगर “0 bugs” का मतलब GitHub issues 0 है, तो सावधान रहना चाहिए
      हो सकता है project को छोड़ा हुआ मान लिया गया हो और इसलिए कोई report ही न कर रहा हो, लेकिन उसमें security vulnerabilities मौजूद हों

  • बिना updates के चल सकने वाला software वही है जो शुरू से ही सही तरीके से बनाया गया हो
    अगर software सिर्फ अपने लिए है तो यह अपेक्षाकृत आसान है; 10 साल बाद भी पसंद में बहुत बड़ा बदलाव आने की संभावना कम होती है, और n छोटा होने पर O(n) function होने के बावजूद O(n^2) function का इस्तेमाल करने जैसी छोटी समस्याओं को नज़रअंदाज़ किया जा सकता है
    लेकिन अगर software दूसरे लोग इस्तेमाल करेंगे, तो requirements अलग होती हैं, और पर्याप्त बड़े N पर O(n) function की अहमियत बढ़ने जैसी समस्याएँ सामने आती हैं
    चाहे अपने लिए लिखो या दूसरों के लिए, ऐसी समस्याएँ आ सकती हैं जिनका पहले अनुमान नहीं था
    उदाहरण के लिए, 1GB से बड़ी file process करने पर crash होता है, लेकिन आम तौर पर 100KB से छोटी files ही इस्तेमाल होती थीं इसलिए उस पर ध्यान नहीं गया, और जब ठीक करने जाओ तो हो सकता है आधा फिर से लिखना पड़े
    यहीं यह सोच कि न बदलने वाला software, अक्सर बदलने वाले software से मूल रूप से बेहतर होता है, अपनी सबसे बड़ी आपत्ति पाती है
    हो सकता है जो software नहीं बदलता वह शुरू से ही परफेक्ट रहा हो, लेकिन यह भी हो सकता है कि उसकी गहराई में डरावनी चीज़ें छिपी हों, और पहले से दोनों में फ़र्क करना मुश्किल होता है
    इसका यह मतलब भी नहीं कि तेजी से update होने वाला software, धीरे update होने वाले software से मूल रूप से बेहतर है; update की speed के अलावा भी बहुत से factors होते हैं

    • मेरा मानना नहीं है कि software को कभी बदलना ही नहीं चाहिए
      requirements बदलें तो जाहिर है software भी बदलना चाहिए
      लेकिन 10 साल के दौरान requirements के बदलाव से असंबंधित बहुत कुछ हो सकता है
      open source project छोड़े जा सकते हैं या दिशा बदल सकते हैं, commercial software बंद हो सकता है, company का acquisition हो सकता है, App Store या Play Store के rules बदल सकते हैं, और API गायब हो सकती है या उसकी pricing बदल सकती है जिससे project की economics टूट सकती है
      toolchain, framework, programming language, paradigm, और best practices भी बदलते हैं
      मेरे हिसाब से असली बात यह है कि requirements से असंबंधित बाहरी बदलाव मुझे बदलने पर मजबूर न करें
      यह अच्छा सिद्धांत है, लेकिन हमेशा की तरह इसमें भी trade-off है
      stable और outdated एक ही चीज़ नहीं हैं, और इन दोनों का फ़र्क अक्सर security पर जाकर तय होता है
      अगर किसी महत्वपूर्ण नई requirement को पूरा करना आसान हो, लेकिन उसके लिए vendored library को 7 major versions तक ऊपर ले जाना पड़े और नतीजे में ढेर सारा असंबंधित breakage हो जाए, तो क्या करोगे
      अगर रुके हुए toolset के आदी लोग अब पर्याप्त संख्या में न हों, और कोई नया उसे सीखना ही न चाहे, तो क्या करोगे
      dependencies को सोच-समझकर और conservatively चुनना अच्छी बात है, लेकिन इतनी छोटी रखी गई dependency changes का भी पीछा न करना मुझे एक कदम ज़्यादा लगता है

  • लेख की भावना से सहमत हूँ
    यह बात सचमुच बुरी लगती है कि कुछ ही साल पहले बनाई गई mobile app को भी अब patch करने और update submit करने में दर्जनों घंटे लग जाते हैं
    यह भी दिलचस्प था कि लेखक ने अपने static site generator को cold-blooded software कहा और अंत में बताया कि वह Python 2 पर चलता है
    Python 2 को आजकल install करना लगातार मुश्किल होता जा रहा है, और आखिरकार वह project भी warm-blooded project बन जाएगा

    • मैं नियमित रूप से development नहीं करता, लेकिन एक user के रूप में अक्सर इस्तेमाल किए जाने वाले छोटे hobby projects (iOS और macOS) हैं, और उन्हें latest OS पर compile और run होते रहने लायक बनाए रखता हूँ
      हर बार Xcode upgrade करने पर project को cleanly compile और सही तरह चलाने के लिए छोटी-छोटी चीज़ें ठीक करनी पड़ती हैं, और यह सचमुच बेहद चिढ़ाने वाली बात है जिसे सामान्य मान लेना नहीं चाहिए
      हाल की git history के message लगभग सभी “latest Xcode पर चलने लायक fix” के अलग-अलग रूप हैं
      अगर ये lower-level SDK या OS changes security threats की वजह से ज़रूरी होते तो कुछ हद तक समझ आता, लेकिन लगभग कभी ऐसा नहीं होता
      ज़्यादातर यह API deprecate करने, default warnings जोड़ने, और अब इस framework की जगह उस framework का इस्तेमाल करो जैसी बेवकूफ़ी भरी changes होती हैं
      platform और framework को जान-बूझकर moving target बने रहना बंद करना चाहिए, और खास तौर पर तब जब OS अब बहुत stable और reliable हो चुका हो
      10 साल पुराने project को भी अगर freezer से निकालो, तो उसे 10 साल पहले की तरह cleanly compile और run होना चाहिए
      ये OS vendors trillion-dollar companies हैं, इसलिए backward compatibility में ज़्यादा engineering effort लगने का बहाना मैं नहीं सुनना चाहता

  • मैं अपना personal side project अब भी maintain कर रहा हूँ
    वह 12~13 साल पहले pure PHP से शुरू हुआ था, बाद में उसे Laravel में फिर से लिखा, और फिर लगभग 2017 में Symfony में एक बार और rewrite किया
    freelancer के रूप में full-time काम करते हुए कई बार energy नहीं बचती थी, इसलिए 6~18 महीनों तक सिर्फ 2~3 बहुत छोटे commits ही किए, लेकिन जब समय मिला तो features जोड़े, upgrades किए, experiment किया और सीखा
    लंबे समय तक project maintain करना सीखने में यह बहुत उपयोगी रहा
    dependency updates, गैरज़रूरी चीज़ें हटाना, security updates जाँचना, और simplification के मौके ढूँढना (Vagrant से Docker, Vue + Axios + Webpack आदि से Htmx) जैसी बातें सीखीं, और यह भी सीखा कि किससे बचना चाहिए
    व्यक्तिगत रूप से मैं नए-नए बनी dependencies, microservices, और Kubernetes जैसी complex infrastructure से बचने लगा हूँ
    हाल ही में मैंने कई features बनाए, PHP 8.2 और Symfony 7 में upgrade किया, और ChatGPT-आधारित features भी integrate किए, इसलिए चाहूँ तो शायद 1~3 साल का ब्रेक ले सकता हूँ
    पिछले 4~5 सालों में इस project ने औसत freelancer की एक साल की income के बराबर revenue दिया है, इसलिए यह कोई सोया हुआ गुमनाम side project भी नहीं है

    • PHP में वापस जाना भले भयानक लगता हो, लेकिन मेरे हिसाब से यह backward compatibility निभाने का सचमुच ऐसा उदाहरण है जहाँ वे अपनी कीमत पर भी इसे निभाते हैं
      कई साल इस्तेमाल न करने के बाद जब वापस गया, तो 8 साल पहले छोड़ते समय जैसी भयानक image manipulation functions थीं, वे अब भी ज्यों की त्यों मौजूद थीं
    • मैं सोच रहा हूँ कि Symfony को और native तरीके से सीखूँ, लेकिन जानना चाहता हूँ कि Laravel जैसी चीज़ से Symfony पर जाने की वजह क्या थी

  • लेख में कही बातों के अलावा, मूल रूप से सुरक्षित threat model भी महत्वपूर्ण है
    उदाहरण के लिए, पूरी website को लगातार attackers और spam bots से जूझना पड़ता है, इसलिए वह स्वभाव से warm-blooded के ज़्यादा करीब है
    वहीं TiddlyWiki जैसा static page शायद web पर डालना ही न पड़े, और browser एक बेहद stable platform है, इसलिए वह काफ़ी बेहतर है

  • Cold-blooded project और warm-blooded project के प्रति पसंद का अंतर शायद https://www.cs.utexas.edu/users/EWD/transcriptions/EWD11xx/EWD1175.html में आने वाले Buxton Index से जुड़ा हुआ है

    • लिंक किए गए लेख को पढ़ने पर पता चलता है कि Buxton Index वह समय-अवधि है जो यह दिखाती है कि कोई व्यक्ति या संगठन जैसा कर्ता कितने वर्षों के पैमाने पर योजना बनाता है
      मोहल्ले की एक छोटी किराना दुकान लगभग 0.5 वर्ष, एक सच्चा Christian अनंत, दोबारा चुने जाने की कोशिश करने वाला औसत politician लगभग 4 वर्ष, ज़्यादातर industries उससे थोड़ा लंबा, और quarterly report लिखने वाले managers उससे बहुत छोटा सोचते हैं
      Buxton Index महत्वपूर्ण इसलिए है क्योंकि बहुत अलग-अलग Buxton Index वाले पक्षों के बीच घनिष्ठ सहयोग अनिवार्य रूप से विफल हो जाता है और नैतिक दोषारोपण तक पहुँचता है
      कम अवधि वाला पक्ष सतही और अल्पदृष्टि वाला कहलाता है, जबकि लंबी अवधि वाला पक्ष कर्तव्यच्युत, ज़िम्मेदारी से बचने वाला, या free rider कहा जाता है
      वे एक-दूसरे को बेवकूफ भी समझने लगते हैं
      Buxton Index की खूबी यह है कि यह एक साधारण संख्यात्मक अवधारणा है, इसलिए नैतिक रूप से तटस्थ है, और मतभेद को नैतिक बहस के ऊपर उठाकर देखने में मदद करती है
      academia और industry के सहयोग के बारे में सोचते समय यह खास तौर पर महत्वपूर्ण है
    • यह time preference से बहुत मिलता-जुलता लगता है: https://en.wikipedia.org/wiki/Time_preference

  • यह नाम वाकई बहुत खराब है
    Cold-blooded animals पर्यावरण पर बहुत ज़्यादा निर्भर होते हैं, जबकि warm-blooded animals metabolism के ज़रिए बाहरी तापमान पर निर्भरता कम करते हैं
    कुल मिलाकर यह अनावश्यक रूप से अस्पष्ट है
    बस “बाहरी निर्भरताओं से मुक्त software” कह दें, तो लंबा व्याख्यात्मक अनुच्छेद हटाया जा सकता है

    • यह लेख की मूल समस्या पर ठीक निशाना साधने वाला अकेला जवाब था, और स्वाभाविक रूप से यहाँ किसी ने इसे upvote नहीं किया
      मुझे वैसे भी software development पर वे लेख पसंद नहीं जो nature से ली गई अनुचित उपमाओं के आधार पर सतही निष्कर्षों पर कूद पड़ते हैं, लेकिन जब वे उस उपमा के लक्ष्य रहे प्राकृतिक phenomenon को ही पूरी तरह गलत समझकर ऐसा करते हैं, तो वे और भी बुरे लगते हैं
      painted turtle समेत कुछ प्रजातियाँ जम जाने पर भी बच जाती हैं, यह उनकी cold-bloodedness की वजह से नहीं बल्कि विशेष antifreeze proteins की वजह से है
      दूसरी lizards या cold-blooded animals पिघलने पर अपने ही tissues के फट जाने से नष्ट हो जाएँगे
    • कुछ लोगों ने जैविक व्याख्या को अधिक उदारता से पढ़ा
      https://lobste.rs/s/hitos3/cold_blooded_software#c_mxjzwh