2024 में, मैं प्रोग्रामिंग कैसे करता हूँ

 (akkartik.name)
2 पॉइंट द्वारा GN⁺ 2024-08-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • मैंने इस बारे में बात की थी कि लंबे समय तक उपयोग में आने वाले प्रोग्राम कैसे चुने जाएँ और भरोसेमंद infrastructure कैसे बनाया जाए, लेकिन यह भी स्वीकार करता हूँ कि मैं अभी भी यह काम अच्छी तरह नहीं कर पा रहा हूँ
  • पिछले 2 साल से इस्तेमाल कर रहे एक प्रोग्राम के core को मैंने एक महीने तक फिर से लिखा, और इस प्रक्रिया में अपनी पिछली ज़िंदगी में प्रोग्रामिंग के बदलावों पर पीछे मुड़कर देखा

2015

  • abstraction पर संदेह करता था और testing व version control को बहुत महत्व देता था
  • मुझे लगता था कि abstraction का दुरुपयोग और testing/version control की कमी ही समस्याओं की वजह है
  • मैंने Mu1 नाम का एक platform डिज़ाइन किया, जिसमें testing और layers बुनियादी constraints थे

2017

  • Mu1 को मौजूदा Mu के रूप में दोबारा काम करना शुरू किया
  • शुरुआत में testing और layers के सारे नए ideas इस्तेमाल किए, लेकिन धीरे-धीरे उनका इस्तेमाल बंद कर दिया
  • Mu में बहुत सारे tests हैं, लेकिन वे पुराने तरीके के हैं, और layer infrastructure को port नहीं किया गया

2022

  • Freewheeling Apps पर काम शुरू किया
  • शुरुआत testing के बिना की, फिर text editor के core हिस्से के लिए बहुत thorough tests लिखे
  • बाकी हिस्सों की testing करना मुश्किल था, लेकिन वे फिर भी अच्छी तरह काम करते थे

2024

  • एक महीने पहले मैंने सारे tests हटा दिए
  • text editor को इस तरह radical तरीके से दोबारा काम किया, जैसा पहले दूसरे Freewheeling Apps के साथ merge conflicts की चिंता के कारण नहीं कर पाता था
  • version control को लेकर सोचना बंद हो गया
  • testing और versions छोड़कर मैंने एक कहीं बेहतर प्रोग्राम बनाया

sustainable programming पर मेरा मौजूदा एकीकृत दृष्टिकोण

  1. बहुत सारे लोगों के लिए sustainably build करना बहुत कठिन है, इसलिए इसकी कोशिश भी मत करो
  2. ज़्यादातर software कम समय में बहुत सारे लोगों की सेवा करने वाले incentives से संक्रमित है। ऐसे software पर ध्यान दो जिनमें कम logos हों, जिन्हें बनाना आसान हो, जिनकी dependencies कम हों, और जो automatic updates न करते हों
  3. context में छोटे बदलाव भी इस बात को बुनियादी रूप से बदल सकते हैं कि कोई प्रोग्राम उस context में कितना फिट बैठता है
  4. नए प्रोग्राम किसी न किसी रूप में अज्ञात दुनिया की ओर बढ़ते हैं। अक्सर किसी भी दिशा में हमें ठीक-ठीक नहीं पता होता कि हम क्या कर रहे हैं
  5. types, abstraction, testing, versions, state machines, immutability, formal analysis आदि ऐसे tools हैं जिन्हें अपरिचित terrain में इस्तेमाल किया जा सकता है
  6. अनिवार्य रूप से हम इनमें से कुछ tools का ज़रूरत से ज़्यादा इस्तेमाल करेंगे। इनका आदर्श उपयोग हमारी सोच से कहीं कम है। अति-उपयोग technical debt है
  7. जब context की समझ स्थिर हो जाए, तो प्रोग्राम के बड़े हिस्से को फेंककर शुरुआत से फिर करना मूल्यवान हो सकता है
  8. दोबारा लिखने से पहले, आपको प्रोग्राम से जो कुछ भी चाहिए और जिन सभी scenarios को प्रोग्राम को संभालना है, उन्हें एक साथ दिमाग में रखना होगा
  9. सब कुछ एक ही बार में बनाओ
  • testing और version control इस विकास की अंतिम अवस्था तक पहुँचने में बाधा बनते हैं
  • testing चिंताओं को भुला देती है और version control आपको अतीत से बाँधे रखता है

GN⁺ की राय

  • अगर प्रोग्राम बहुत जटिल हो जाए, तो चरण 8 में सब कुछ याद रखना असंभव हो सकता है। यह ज़्यादातर software पर लागू होता है, खासकर वह software जिसे दो या अधिक लोगों ने लिखा हो
  • हर software का चरण 9 तक पहुँचना ज़रूरी नहीं है। बहुत से Freewheeling Apps इतने सरल होते हैं और इतनी धीमी गति से विकसित होते हैं कि शुरुआती design choices चाहे जो भी हों, कुछ ही लोगों द्वारा इस्तेमाल किए जाने पर वे bug-free स्थिति में स्थिर हो सकते हैं
  • चरण 9 तक पहुँचने में data-oriented design स्पष्ट रूप से उपयोगी है। यह कोई ऐसा tool नहीं है जिसे आँख बंद करके लागू किया जा सके, बल्कि immediate data structure choices से आगे बढ़कर इस बड़े चित्र को देखने की एक सोच है कि प्रोग्राम data को कैसे access करता है
  • हो सकता है ये चरण पूरी तरह सही न हों। संभव है कि मैं उन tools को कम आँक रहा हूँ जिनका मेरे पास कम अनुभव है
  • जिज्ञासा है कि इन चरणों से आगे कौन-सा चरण हो सकता है

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

1 टिप्पणियां

 
GN⁺ 2024-08-06
Hacker News राय

  • अगर टेस्ट नहीं हैं, तो समस्या दिखती ही नहीं, इसलिए ऐसा लगता है जैसे समस्या गायब हो गई हो

    • टेस्ट करने पर हमेशा बग मिलते थे
    • टेस्ट हटा देना खुद को धोखा देना है
    • पेज पढ़ने के बाद लगा कि वह mutation/configuration management से थक चुका है
    • पैसे कमाने के लिए बहुत सारे users होने चाहिए

  • टेस्ट और versioning छोड़ने पर उसे बेहतर प्रोग्राम मिले

    • 2024 में source code management का इस्तेमाल न करना समझ से बाहर है
    • कई devices पर काम करना, history देखना, rollback करना, और branches बनाना बहुत उपयोगी है

  • शुरुआत में लगा कि लेखक गलत है, लेकिन इसमें अच्छी अंतर्दृष्टि है

    • यह workflow लेखक के लिए अच्छी तरह काम करता है
    • शायद उसे Git या automated tests से productivity घटने का अनुभव हुआ होगा
    • सरल alternatives भी हैं (जैसे: Dropbox, FTP)
    • लेखक को छोटे programs बनाना पसंद है
    • automated tests उपयोगी हैं, लेकिन लेखक के मामले में उनकी value दिखाई न देती हो सकती है

  • version control और automated tests वास्तविक समस्याएँ हल करते हैं

    • आज के समय में version control के बिना project शुरू करना पागलपन है
    • automated tests best practice हैं
    • लेखक के खास use case में यह तर्कसंगत हो सकता है

  • बड़े programs लिखते/refactor करते समय, लिखना, फेंकना, और फिर से लिखना महत्वपूर्ण है

  • यह लेख उलझाने वाला है

    • समझ नहीं आता कि इसे सबसे पहले upvote क्यों मिला

  • छोटे बदलाव program की suitability को बहुत बदल सकते हैं

    • K9 Mail का उदाहरण है
    • K9 Mail की शुरुआत एक non-traditional UI से हुई थी
    • कई users ने नए UI पर असंतोष जताया
    • छोटे बदलाव ने app की suitability नष्ट कर दी
    • अब भी पुराना version इस्तेमाल कर रहा हूँ

  • अकेले software बनाना और team में बनाना पूरी तरह अलग है

    • tests एक साधन हैं, लक्ष्य नहीं
    • जब आत्मविश्वास होता है, तो tests कम करता हूँ
    • महत्वपूर्ण हिस्सों में integration tests जोड़ता हूँ
    • नए API design के लिए unit tests उपयोगी हैं

  • 2022 में Freewheeling Apps पर काम शुरू किया था

    • tests न होने की वजह से निराशा हुई
    • test suite सिस्टम को आगे बढ़ाने का आत्मविश्वास देता है
    • feature complexity बढ़ने पर testing कठिन हो जाती है
    • 2024 में सभी tests हटा दिए
    • यह दर्शन सिर्फ एक व्यक्ति पर लागू होता है

  • मैं इस बात से सहमत नहीं हूँ कि छोटे बदलाव program की suitability को बहुत बदल सकते हैं

    • short-termism छोटे बदलावों के अनुकूल होने के लिए ही है

  • लेखक पसंद है और Mu project भी पसंद है

    • यह एक आधुनिक Lisp machine है

  • software engineering की जटिलता से अभिभूत हूँ

    • हर विचार को ठुकराना समाधान नहीं है
    • tests लिखने चाहिए, VCS इस्तेमाल करना चाहिए, और abstractions का उपयोग करना चाहिए
    • यह भी समझना चाहिए कि उनका उपयोग क्यों कर रहे हैं, और कारण न हो तो फिर से मूल्यांकन करना चाहिए