शीत-रक्त सॉफ़्टवेयर

 (dubroy.com)
3 पॉइंट द्वारा GN⁺ 2023-12-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें

ठंडे रक्त वाला सॉफ़्टवेयर

  • 2004 में, कंप्यूटर साइंस का छात्र रहे लेखक ने natural history की एक क्लास के दौरान प्रोफेसर को एक जमी हुई baby painted turtle दिखाते देखा।
  • यह कछुआ उन कुछ प्रजातियों में से एक है जो जमी हुई अवस्था में भी जीवित रह सकती हैं, क्योंकि यह कम तापमान पर अपने metabolism को नियंत्रित कर सकने वाला cold-blooded जीव है।
  • क्लास के दौरान कछुए को धीरे-धीरे हिलते और फिर से जीवंत होते देखना, cold-blooded जीवों के बारे में समझ को और गहरा करता है।

सॉफ़्टवेयर प्रोजेक्ट्स की द्विविधा

  • सॉफ़्टवेयर प्रोजेक्ट्स को भी warm-blooded और cold-blooded प्रोजेक्ट्स में बाँटा जा सकता है।
  • warm-blooded प्रोजेक्ट्स को लगातार सक्रियता की ज़रूरत होती है, और गतिविधि रुकते ही समस्याएँ आने लगती हैं।
  • cold-blooded प्रोजेक्ट्स में लंबे समय तक कम गतिविधि रहने पर भी, दोबारा शुरू करते समय वे लगभग उसी स्थिति से तुरंत चल पड़ते हैं।

ब्लॉग का cold-blooded सॉफ़्टवेयर

  • लेखक के ब्लॉग को चलाने वाला सॉफ़्टवेयर एक cold-blooded सॉफ़्टवेयर है।
  • 12 साल पहले शुरू हुआ यह प्रोजेक्ट सरल है, बाहरी सेवाओं पर निर्भर नहीं है, और इसकी सभी dependencies प्रोजेक्ट repository में शामिल हैं।
  • कुछ छोटे सुधारों को छोड़कर यह बिना किसी बदलाव के अच्छी तरह काम करता रहा है, और उम्मीद है कि यह आगे भी 12 साल तक काम करेगा।

GN⁺ की राय

  • cold-blooded सॉफ़्टवेयर की अवधारणा प्रोजेक्ट की sustainability और maintainability पर महत्वपूर्ण प्रभाव डालती है।
  • यह लेख इस बात पर अंतर्दृष्टि देता है कि technology stack का चयन किसी प्रोजेक्ट की दीर्घायु को कैसे प्रभावित करता है।
  • लेखक का अनुभव सॉफ़्टवेयर डेवलपर्स को लंबे समय तक स्थिर सिस्टम बनाने के तरीके पर एक सीख देता है।

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

1 टिप्पणियां

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

  • Node और JavaScript ecosystem में Express web framework मौजूद है। इसका मौजूदा प्रमुख version 4.x.x branch 10 साल से भी पुराना है, और हर हफ़्ते 1.7 करोड़ से ज़्यादा downloads होते हैं। इसमें कुछ features की कमी है और performance भी सबसे बेहतर नहीं है, लेकिन यह तेज़ और स्थिर development संभव बनाता है, और API changes या security patches की कमी की चिंता किए बिना long-term planning करने देता है, इसलिए बहुत से developers इसे पसंद करते हैं। Go language अपने बड़े standard library और compatibility promise की वजह से इससे भी बेहतर stability देती है, जिससे 10 साल से अधिक पुराने programs भी चलाए जा सकते हैं.

  • अगर software बिना updates के भी अच्छी तरह काम करता है, तो अक्सर इसका मतलब है कि उसे शुरुआत से सही बनाया गया था। निजी उपयोग का software अपेक्षाकृत आसान होता है, क्योंकि पसंद-नापसंद बहुत नहीं बदलती। लेकिन जब हम दूसरों के इस्तेमाल के लिए software लिखते हैं, तो requirements अलग हो सकती हैं और अनपेक्षित समस्याएँ आ सकती हैं। उदाहरण के लिए, बड़े files को process करते समय crash हो सकता है, और इसे ठीक करने के लिए software का आधा हिस्सा फिर से लिखना पड़ सकता है। यही उस दावे के ख़िलाफ़ सबसे बड़ा तर्क है कि जो software कम बदलता है वह ज़रूर बेहतर होता है.

  • Python लगातार compatibility तोड़ने वाले changes की वजह से अच्छा उदाहरण नहीं है। इसके विपरीत Go या Java में 10 साल पुराना code भी modern tools के साथ अच्छी तरह काम करता है। Perl इससे भी बेहतर उदाहरण है, जहाँ 30 साल पुराना code भी अब तक ठीक चलता है.

  • मैं IBM mainframe (z/OS) पर काम करता हूँ। backward compatibility बनाए रखने के मामले में IBM सबसे बेहतरीन है। Microsoft (Windows) दूसरे स्थान पर है, और Linux (kernel) ABI तीसरे पर। ज़्यादातर दूसरे systems में यह समस्या आम है, खासकर OSS में, जहाँ compatibility बनाए रखने पर समय खर्च करना लोग नहीं चाहते.

  • Dependencies किसी app को 'गरम खून वाला' बना सकती हैं, लेकिन Docker या containerization इन समस्याओं को कुछ हद तक हल कर सकते हैं। किसी project के लिए library चुनते समय मैं काफ़ी शोध करता हूँ कि वह 'ठंडे खून वाली' library है या नहीं.

  • GitHub पर library खोजते समय बहुत से engineers आख़िरी commit का समय देखते हैं। उनका मानना होता है कि जितना हाल का commit होगा, उतना बेहतर support मिलेगा। लेकिन लंबे समय से स्थिर, अच्छी तरह maintained और bug-free archived project ढूँढना किसी पुराने सामान की दुकान में छुपा हुआ रत्न खोजने जैसा है.

  • मैं अपने side project को maintain कर रहा हूँ। इसे 12-13 साल पहले शुरू किया था और PHP, Laravel, Symfony में rewrite किया। किसी project को लंबे समय तक maintain करना सीखने के लिए यह बहुत मूल्यवान रहा। उदाहरण के लिए, Vagrant से Docker पर जाना, और Vue + Axios + Webpack जैसी चीज़ों से Htmx तक simplify करने के मौके ढूँढे। हाल ही में PHP 8.2 और Symfony 7 में upgrade किया और ChatGPT-आधारित features को integrate किया.

  • पिछले कुछ वर्षों के mobile apps से ऊब चुका हूँ, जिन्हें हर कुछ घंटों में patching की ज़रूरत पड़ती है। लेखक अपने static site generator को 'ठंडे खून वाला' बताते हैं, जो Python 2 पर चलता है, जबकि Python 2 install करना लगातार कठिन होता जा रहा है.

  • 1994-95 में लिखा गया SDK 2017 में कंपनी छोड़ने तक इस्तेमाल होता रहा। यह ANSI C में लिखा गया था, और PHP(5) में लिखा हुआ code भी PHP 8.2 पर ठीक काम करता है। लेकिन ऐसी चीज़ें नीरस लगती हैं और उनमें चर्चा बटोरने वाली चमक कम होती है.

  • लेख में बताए गए बिंदुओं के अलावा, मूल रूप से सुरक्षित threat model होना भी महत्वपूर्ण है। उदाहरण के लिए, पूरा website लगातार attackers, spam bots आदि का सामना करता है, इसलिए वह स्वभाव से ही 'गरम खून वाला' है। इसके विपरीत Tiddlywiki जैसे static pages को web पर डालने की ज़रूरत नहीं होती, और browser एक बहुत स्थिर platform है, इसलिए वे कहीं बेहतर हैं.