मुश्किल चीज़ों को आसान कैसे बनाया जाए

 (jvns.ca)
4 पॉइंट द्वारा GN⁺ 2023-10-07 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Julia Evans के Strange Loop keynote में यह बताया गया है कि DNS, Bash, HTTP, SQL जैसी चीज़ें, जो “बेसिक” लगती हैं, सीखने में इतना समय क्यों लेती हैं, और सीखने की बाधा को कैसे कम किया जाए
  • Bash की मुश्किल यह है कि इसमें set -e का || condition के अंदर function call में निष्क्रिय हो जाना जैसी छोटी exceptions और pitfalls बहुत हैं, और ज़्यादातर लोग Bash को कभी-कभार ही इस्तेमाल करते हैं, इसलिए चीज़ें ठीक-ठीक याद रखना मुश्किल होता है
  • HTTP और SQL की सतह भले सरल लगे, लेकिन उसके पीछे ब्राउज़र का 2 करोड़ lines का implementation, बहुत सारे headers और flags, और SQL में लिखने के क्रम व execution क्रम का अंतर छिपा होता है, जिससे सीखने का बोझ बढ़ता है
  • DNS में libraries, cache, और authoritative nameserver के साथ होने वाला communication उपयोगकर्ता को साफ़ दिखाई नहीं देता, और dig का output भी जटिल होता है, इसलिए छिपे हुए व्यवहार को दिखाने वाले tools और demos महत्वपूर्ण हैं
  • अच्छी learning support का मतलब है tools और references साझा करना, बड़ी lists को असल में इस्तेमाल होने वाली छोटी lists तक सीमित करना, कंप्यूटर क्या करता है इसे समयक्रम में समझाना, और failures व bugs के रिकॉर्ड भी साझा करना

“बेसिक” लगने वाली तकनीकों में इतना समय क्यों लगता है

  • Strange Loop keynote Making Hard Things Easy इस बात पर है कि कठिन तकनीकों को सीखना कैसे आसान बनाया जाए
  • शुरुआत DNS से हुई
    • domain name का IP address ढूँढना सुनने में सरल लगता है, लेकिन वक्ता ने कहा कि DNS सीखने के 7 साल बाद भी वेबसाइट सेटअप करते समय उन्हें दिक्कतें हुईं, और कुल मिलाकर इसे समझने में लगभग 10 साल लगे
    • उनके दोस्त भी बार-बार वही समस्याएँ झेलते रहे, और कई लोग इसे ऐसे लेते रहे मानो “यह तो अब तक समझ आ जाना चाहिए था”, यानी जैसे यह उनकी व्यक्तिगत कमी हो
  • वक्ता ने ऐसे विषयों को आसान भाषा में समझाने के लिए Wizard Zines नाम की एक छोटी publishing company शुरू की, और Bash, HTTP, SQL, DNS को उदाहरण बनाया

Bash: याद रखना मुश्किल exceptions tools को संभालनी चाहिए

  • Bash एक programming language है, लेकिन वक्ता के अनुसार यह उन भाषाओं में से है जिनमें अजीब behavior काफ़ी ज़्यादा है
  • उदाहरण script में अगर mv ./*.txt /tmmpp fail हो जाए, तब भी Bash default रूप से रुकता नहीं और echo "success!" चला देता है
    • set -e इस्तेमाल करने पर fail होने पर script रुक सकती है
    • लेकिन अगर function को f || echo "failed!" की तरह || condition के अंदर call किया जाए, तो function के अंदर set -e globally निष्क्रिय हो जाता है और फिर से success print हो सकता है
    • यह Bash bug नहीं, बल्कि documented behavior है
  • Bash के कठिन होने का एक कारण यह भी है कि बहुत से लोग Bash scripts हर 6 महीने में एक बार जैसी कम frequency पर लिखते हैं और फिर उन्हें दोबारा नहीं देखते
    • अगर कोई system कम इस्तेमाल हो, लेकिन उसमें बहुत सारा trivia और pitfalls भरा हो, तो उसे सही तरह से इस्तेमाल करना मुश्किल हो जाता है
  • “Bash कोई नहीं चला सकता” जैसी प्रतिक्रिया पूरी तरह सही नहीं है
    • बहुत से लोग Bash इस्तेमाल करते हैं, और भले पूरी तरह perfect न हों, काम अक्सर हो ही जाता है
    • लक्ष्य यह है कि जो व्यक्ति भारी-भरकम pitfalls के ढेर के सामने खड़ा है, उसे “ज़्यादातर सही तरीके से इस्तेमाल कर सकने” की स्थिति तक पहुँचाया जाए
  • ShellCheck ऐसा tool है जो Bash की वे pitfalls याद रखता है जिन्हें इंसान के लिए याद रखना मुश्किल है, और warning देता है
    • shellcheck -o all bad-again.sh SC2310 warning दिखाता है कि || condition में call किया गया function set -e को निष्क्रिय कर देता है
    • यह check -o all के साथ ही दिखाई देता है
    • ऐसे tools trivia को कंप्यूटर के ज़िम्मे देकर cognitive load कम करते हैं

असफलता की कहानियाँ “best practices” से ज़्यादा मददगार होती हैं

  • भले आप tool खुद न बनाएँ, लेकिन जो उपयोगी tools आप पहले से इस्तेमाल कर रहे हैं उन्हें दोस्तों या सहकर्मियों को बताना महत्वपूर्ण है
    • वक्ता ने भी कहा कि उन्हें ShellCheck के बारे में बहुत देर से पता चला, और इस बात पर खीझ हुई कि तब तक वे सब कुछ दिमाग़ में याद रखने की कोशिश करते रहे जबकि उसकी ज़रूरत नहीं थी
  • pitfalls और failure stories साझा करना लगभग community service जैसा है
    • Bash में set -e के निष्क्रिय होने का उदाहरण उन्होंने कुछ हफ्ते पहले अपने दोस्त Jesse से सुना था
    • जब आप दूसरे लोगों की असफलताओं के बारे में जानते हैं, तो वही समस्या खुद झेले बिना भी उससे बच सकते हैं
  • “किसी को Bash इस्तेमाल नहीं करना चाहिए” जैसी कठोर राय से ज़्यादा उपयोगी यह है कि Bash ने असल में कौन सी समस्या पैदा की
    • एक ही कहानी सुनकर कोई व्यक्ति ShellCheck का इस्तेमाल करते हुए simple Bash scripts रखना तय कर सकता है
    • कोई दूसरा तय कर सकता है कि वह Bash बिल्कुल नहीं इस्तेमाल करना चाहता
    • एक ही उदाहरण पर अलग-अलग प्रतिक्रियाएँ होना ठीक है

HTTP: इसे समझने के लिए 2 करोड़ lines वाले browser को मानकर चलना पड़ता है

  • HTTP response state code, headers और body जैसी सरल संरचना वाला लग सकता है
  • लेकिन “header क्यों सेट करना पड़ता है?” जैसे सवाल जल्दी ही browser behavior तक पहुँच जाते हैं
    • Firefox लगभग 2 करोड़ lines के code से बना है
    • browser 1990s से विकसित होते आए हैं, और उनका security model भी web पर होने वाले attacks और बदलावों के साथ लगातार बदलता रहा है
  • यह समझने के लिए कि कोई विषय कठिन क्यों है, यह देखना ज़रूरी हो सकता है कि उसके पीछे बहुत बड़ा codebase है या नहीं
    • इसमें सिर्फ HTTP नहीं बल्कि CSS, JS जैसी चीज़ें भी शामिल हैं, लेकिन modern browser की complexity HTTP की learning barrier समझाने में मदद करती है
  • बड़ी lists को छोटी lists में बदलना चाहिए ताकि चीज़ें समझना आसान हो
    • HTTP request headers की list 43 से ज़्यादा items की है, और unofficial headers भी हैं
    • वक्ता ने HTTP request headers comic में उन 15 headers पर बात की है जिन्हें वे जानती हैं और इस्तेमाल करती हैं
    • “सबसे महत्वपूर्ण headers” कोई objective list नहीं, बल्कि अपनी जानकारी और usage पर आधारित subjective list है
    • उदाहरण के लिए, इतना जानना कि Accept-Encoding को gzip पर सेट करने से compressed response मिल सकता है, आमतौर पर काफ़ी होता है
  • command-line tools को भी इसी तरह अपनाया जा सकता है
    • grep के man page में बहुत सारे flags हैं, लेकिन वक्ता ने 20 साल grep इस्तेमाल करने के बाद भी सब नहीं सीखे
    • अगर कोई अनुभवी व्यक्ति कहे “मैं इस system में सिर्फ 7 चीज़ें जानता हूँ, और वे ये हैं”, तो यह शुरुआती लोगों के लिए मददगार होता है
    • कोई दूसरा अनुभवी व्यक्ति अलग 7 चीज़ें जानता हो सकता है

Reference वही साझा करें जो आप वास्तव में इस्तेमाल करते हैं

  • जो जानकारी इंसानी दिमाग़ में नहीं समा सकती, उसके लिए अच्छे references ज़रूरी हैं
  • वक्ता ने कहा कि CSS को 20 साल तक बीच-बीच में सीखने के बावजूद उन्हें CSS-Tricks का पता हाल के लगभग 2 सालों में ही चला, और अगर पहले पता होता तो मदद मिलती
    • CSS-Tricks में acquisition के बाद अप्रैल से नए लेख आना बंद दिखते हैं, लेकिन पुराने लेख अब भी उपयोगी माने गए
  • HTTP के लिए वे Mozilla Developer Network का बहुत इस्तेमाल करती हैं
  • HTTP के official references के रूप में 2022 में लिखे गए RFC 9110, 9111, 9112, 9113, 9114 हैं
    • इनमें Connection header के exact behavior जैसी details देखी जा सकती हैं
    • वक्ता का मुख्य reference आमतौर पर MDN है, लेकिन वे यह भी मानती हैं कि official RFCs अच्छी तरह व्यवस्थित हैं
  • references साझा करते समय यह अलग करना ज़रूरी है कि आप कुछ सिर्फ इसलिए साझा कर रहे हैं क्योंकि वह प्रभावशाली दिखता है, या इसलिए क्योंकि आप सच में उसे काम में लेते हैं
    • भले आप असल में w3schools जैसे “कम cool” reference का इस्तेमाल करते हों, यह ईमानदारी से बताना ज़्यादा महत्वपूर्ण है

SQL: कंप्यूटर क्या करता है, यह समयक्रम में बताइए

  • SQL में query लिखने का क्रम और उसकी conceptual execution का क्रम अलग होता है, इसलिए नए सीखने वालों को भ्रम हो सकता है
  • वक्ता का SQL mental model इस क्रम पर आधारित है
    • FROM
    • WHERE
    • GROUP BY
    • HAVING
    • SELECT
    • ORDER BY
    • LIMIT
  • वास्तविक databases में optimization की वजह से चीज़ें और जटिल होती हैं, लेकिन यह time-order model ज़्यादातर स्थितियों में उपयोगी है
    • यह query में लिखे क्रम से लगभग मिलता-जुलता है, बस SELECT पाँचवें स्थान पर आता है
  • “कंप्यूटर पहले वास्तव में क्या करता है?” यह सवाल दूसरे विषयों पर भी लागू किया जा सकता है
    • CORS में browser और server के बीच होने वाले पूरे communication को समयक्रम में लिखकर समझा जा सकता है
    • वक्ता ने CORS comic को इस तरीके का उदाहरण बताया
  • समयक्रम में समझाना सरल दिखता है, लेकिन असल में कठिन काम है, इसलिए यह collaboration में उपयोगी होता है
    • Behind Hello World on Linux Linux में “hello world” चलने पर क्या होता है, इस पर है
    • वक्ता ने 10 साल पहले भी ऐसा ही एक लेख लिखा था, लेकिन 2023 वाला लेख लगभग 6 गुना लंबा था
    • उनकी राय में Linux ज़्यादा complex नहीं हुआ, बल्कि 2013 में उन्हें समयक्रम में होने वाली चीज़ें कम समझ में आती थीं
  • टीम के भीतर भी अगर API endpoint पर request आने के बाद क्या होता है, इसकी timeline साथ मिलकर बनाई जाए, तो हर व्यक्ति अपनी जानकारी जोड़ सकता है

DNS: छिपे हुए systems को दिखाना ज़रूरी है ताकि intuition बने

  • DNS एक ऐसा ढांचा है जिसमें browser, DNS requests भेजने वाली library functions, cache, और authoritative nameserver साथ काम करते हैं
  • समस्या यह है कि इनमें से बहुत कुछ उपयोगकर्ता से छिपा हुआ रहता है
    • कौन सा library code DNS request भेज रहा है, यह जानना आसान नहीं है
    • cache के अंदर stored data को आसानी से inspect नहीं किया जा सकता और उपयोगकर्ता उस पर नियंत्रण भी नहीं रखता
    • cache और authoritative nameserver के बीच का communication भी दिखाई नहीं देता
  • वक्ता ने अपनी दोस्त Marie के साथ Mess With DNS नाम का एक छोटा DNS server बनाया
    • उपयोगकर्ता domain में DNS records बना सकता है
    • resolver से request आने पर कौन सा message आया, यह दिखाया जाता है
    • Strange Loop demo में strangeloop नाम के लिए orange.jvns.ca की ओर इशारा करने वाला CNAME record बनाया गया था, और browser द्वारा इस्तेमाल किया जा रहा Canadian DNS resolver A और AAAA records माँग रहा था, यह देखा गया
  • छिपी हुई चीज़ों को दिखाने का एक और उदाहरण float.exposed है
    • इसमें 32-bit floating-point number में significand और exponent बदलकर अगला floating-point number और spacing का बदलाव देखा जा सकता है
  • DNS के कठिन होने का एक और कारण यह है कि यह एक विशाल distributed system है
    • वक्ता ने कहा कि इसमें “50 लाख से ज़्यादा computers शामिल हो सकते हैं”, जिनमें से अधिकांश पर उपयोगकर्ता का नियंत्रण नहीं होता और कुछ उम्मीद के मुताबिक काम भी नहीं करते

जब dig output जैसा tool खुद learning barrier बन जाए

  • DNS tools का output भी भ्रम बढ़ा सकता है
  • dig में +norecurse flag होता है
    • इससे resolver से कहा जा सकता है कि वह सिर्फ वही result लौटाए जो उसके cache में पहले से मौजूद है
    • dig +norecurse jvns.ca का इस्तेमाल यह देखने के लिए किया जा सकता है कि resolver ने उस domain को पिछले 5 मिनट में cache किया है या नहीं
  • dig का output शुरुआती उपयोगकर्ताओं को यह महसूस करा सकता है कि DNS वास्तव में उससे भी ज़्यादा जटिल है
    • वक्ता के अनुसार यह ज़्यादा उस अपेक्षाकृत मनमाने output format का नतीजा है जो 1990s में तय हुआ और लंबे समय तक बना रहा
  • “eraser eyes” का मतलब है जटिल output में से सिर्फ वही हिस्सा देखना जो वास्तव में ज़रूरी है, और बाकी को जैसे मिटा देना
    • उदाहरण में सिर्फ SERVFAIL response code पर ध्यान दिया गया
    • वक्ता की समझ के अनुसार इस संदर्भ में SERVFAIL का मतलब लगभग “cache में नहीं है” जैसा है
  • जब tools का demo दें, तो यह बताना सीखने में मदद करता है कि output या UI में क्या देखना है और क्या नज़रअंदाज़ करना है
    • dig का output भले खुरदुरा हो, लेकिन उसके फ़ायदे हैं: बहुत functionality, +norecurse support, हर जगह उपलब्धता, और लंबे समय से न बदलने की स्थिरता

चीज़ों को साथ मिलकर आसान बनाने की भूमिकाएँ

  • तकनीक को आसान बनाना ऐसा काम है जो blog के बिना भी अपने आसपास के लोगों के साथ किया जा सकता है
  • वक्ता ने जिन तरीकों का सार बताया, वे ये हैं
    • उपयोगी tools साझा करना
    • वे references साझा करना जिन्हें आप सच में इस्तेमाल करते हैं
    • कंप्यूटर में होने वाली चीज़ों को समयक्रम में बताना
    • बड़ी lists को उन छोटी lists तक सीमित करना जिन्हें आप वास्तव में इस्तेमाल करते हैं
    • छिपे हुए behavior को दिखाना
    • उलझाने वाले tools का demo देना और बताना कि किस हिस्से पर ध्यान देना है
  • मदद करने वाले लोगों के प्रकार भी अलग-अलग हो सकते हैं
    • “शिकायती पुराने user” बताते हैं कि पहले क्या गलत हुआ था, जिससे दूसरों की परेशानी कम होती है
    • “शोर मचाने वाले beginner” पूछते हैं “यह कैसे काम करता है?”, जिससे दूसरे लोगों को भी राहत मिलती है
    • जब कोई senior developer सार्वजनिक रूप से अपनी अनजान बात पूछता है, तो वे लोग भी साथ सीख सकते हैं जो इस डर से चुप रहते हैं कि कहीं उन्हें अज्ञानी न समझ लिया जाए
    • “bug record करने वाले” लिखते हैं कि क्या हुआ था ताकि वही bug फिर न दोहराया जाए
    • “tool बनाने वाले” बार-बार समझाने की जगह code लिखकर समस्या को स्थायी रूप से आसान बना देते हैं
    • “आज क्या सीखा साझा करने वाले” नए tools, झेले गए bugs, और libraries की नई features साझा करते हैं
    • “700 tabs खोलकर रखने वाले” अक्सर पहले से जानते हैं कि जानकारी कहाँ मिलेगी
    • “सवालों का जवाब देने वाले” और “बाद में खोजने लायक लिखकर रखने वाले” लोग भी ज़रूरी हैं
  • जो चीज़ें बेसिक लगती हैं, उन्हें कठिन पाना सिर्फ किसी एक व्यक्ति की समस्या नहीं है
    • बहुत से लोग उन्हीं कारणों से उन्हीं जगहों पर अटकते हैं
    • अगर मुश्किल की वजह समझ में आ जाए, तो उसे कंप्यूटर program के bug की तरह बेहतर तरीके से ठीक किया जा सकता है
  • मुश्किल पैदा करने वाले कारणों में विशाल trivia और pitfalls, 2 करोड़ lines का code, छिपे हुए systems, और ऐसे उलझाऊ tool outputs शामिल हैं जिन्हें अभी बेहतर नहीं बनाया गया
  • वक्ता ने कहा कि Git कठिन क्यों है, यह वे अब भी पूरी तरह नहीं समझ पाई हैं, लेकिन यह ऐसा विषय है जिस पर वे आगे भी सोचती और समझने की कोशिश करती रहना चाहती हैं

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

1 टिप्पणियां

 
GN⁺ 2023-10-07
Hacker News की राय

  • सबसे ज़्यादा असर करने वाली बात थी: जो आम तौर पर छिपा रहता है, उसे दिखाओ
    ऐसे tools लगभग तुरंत ही स्थिति को ज़्यादा साफ़ कर देते हैं। वेब ब्राउज़र के developer tools के बारे में सोचें; उन “अंधेरे दिनों” में जब ये नहीं थे, क्या हो रहा है यह देख नहीं पाते थे और अंदाज़ा लगाना पड़ता था—वह बहुत खराब था
    Wireshark जैसे tools, जो accessible network packets के bytes दिखाते हैं और उनकी structure भी parse करते हैं, सिर्फ network debugging के लिए ही नहीं बल्कि network concepts सिखाने के लिए भी बहुत उपयोगी हैं, क्योंकि वे कुछ भी छिपाते नहीं
    इसी वजह से open source software भी पसंद है। bug की वजह समझने, documentation से छूटे knowledge gaps भरने, या programming concepts और सीखने के लिए source देख सकते हैं, इसलिए कुछ भी छिपा नहीं रहता

    • game development में ऐसा tool renderDoc है। जब पहली बार इसके होने के बारे में पता चला तो सच में हैरानी हुई
    • Wireshark शानदार है, लेकिन network द्वारा ले जाए गए हर byte को नहीं दिखाता
      उदाहरण के लिए, Ethernet preamble कभी नहीं दिखाता, Ethernet frame checksum कभी-कभी ही दिखाता है, और Ethernet protocol का अनिवार्य हिस्सा inter-frame gap भी कभी नहीं दिखाता
      यह काफ़ी करीब पहुँचता है, लेकिन दिखाता है कि कहीं न कहीं हमेशा और details छिपी रहती हैं
    • सपना यह है कि runtime पर हर चीज़ को visualize किया जा सके। अगर ऐसा हो सके, तो मुझे लगता है पूरी computing बहुत सरल और कहीं कम जटिल हो जाएगी
      हम पहले से ही अपने दिमाग में visualize करते हैं, और computing की कोई भी explanation अंततः diagram में बदल जाती है। लेकिन coding करते समय diagrams बिल्कुल नहीं होते
      बस सारे code को dynamically instrument करके GUI को messages भेजने होंगे
    • “जो आम तौर पर छिपा रहता है, उसे दिखाओ” और “ऐसे tools लगभग तुरंत स्थिति साफ़ कर देते हैं” के उलट, आजकल के DevOps tools तो लगता है उल्टा और भी ज़्यादा चीज़ें छिपा रहे हैं
      जिन experts के पास वह knowledge था और जो उसे सिखा सकते थे, वे भी अब organizations के अंदर नहीं, बल्कि उन्हीं tool companies में इकट्ठा हो गए हैं
    • Emacs के लिए Magit में मुझे यही बात पसंद है। UI वाकई समझदार और smooth है, शायद मेरे इस्तेमाल किए Git frontends में सबसे अच्छा, लेकिन UI से interaction का तरीका ऐसे flags और options toggle करने जैसा है जो अंदर के असली Git command-line arguments पर map होते हैं
      इसलिए command line पर स्वाभाविक रूप से जाने पर भी आप तुरंत familiar होकर सीधे इस्तेमाल कर सकते हैं

  • Julia tech industry के सबसे पसंद आने वाले लोगों में से एक लगती हैं
    उनके लेख पढ़ते समय हर बार बचपन में छोटे-छोटे experiments से reality के secrets खोलना शुरू करने वाली उत्साहित भावना फिर जाग जाती है। सच में बहुत प्यारी लगती हैं

    • गहरी technical knowledge और बेहतरीन शिक्षण व communication skills दोनों साथ रखने वाले लोग दुर्लभ हैं। एक और नाम जो याद आता है वह Andrej Karpathy है
      खुशी की बात है कि हाल में ऐसे profile में fit होने वाले और लोग मिल रहे हैं
    • एक पल के लिए लगा कि Julia language की बात हो रही है :)
    • पूरी तरह सहमत। आम तौर पर “omg awesomesauce” टाइप बहुत ज़्यादा excited blog posts या tutorials मुझे पसंद नहीं आते, और मैं Landau&Lifschitz style की सूखी, high signal-to-noise ratio वाली, concise और खूबसूरत writing को कहीं ज़्यादा पसंद करता हूँ
      लेकिन Julia के सारे लेख वही ऊपर वाली उत्साहित feeling दिलाते हैं
    • सामने मिलने पर भी सच में बहुत प्यारी थीं। मैंने अपनी How DNS Works किताब पर उनसे signature लिया

  • “जब कोई junior कहता है ‘यह मुश्किल है’, तो experienced व्यक्ति कहता है ‘हाँ, bash usable नहीं है। किसी को भी यह ठीक से नहीं आता’” — मुझे नहीं लगता इसे शाब्दिक रूप से लेना चाहिए
    इसका मतलब कुछ ऐसा है: “हमने जो bash code लिखा है, उसकी समझ या untested situations में उसके expected तरीके से चलने का confidence बहुत मजबूत नहीं है”
    मतलब, अगर ज़रा भी कुछ unusual हुआ तो कुछ fail होगा, और bash के बारे में नई सीखी किसी बात से आप सिहर उठेंगे या पास की चीज़ों को इतना ज़ोर से मारेंगे कि वे damaged हो जाएँ—ऐसी कुछ उम्मीद रहती है
    Bash एक complex language है, और ज़्यादातर programmers की रोज़ इस्तेमाल होने वाली अन्य languages से बिल्कुल अलग है। अधिकतर companies में कहीं production में थोड़ा-बहुत bash होता है, लेकिन अक्सर ऐसा कोई व्यक्ति नहीं होता जिसने उसे इतना अधिक इस्तेमाल किया हो कि वह उसे अच्छी तरह जानता हो
    build tools, CI tools और cloud orchestration tools का shell scripting की ज़रूरत घटाने की दिशा में evolve करना कोई संयोग नहीं लगता

    • bash जैसे tool की complexity मुझे evolution की कमी से आती लगती है
      एक thought experiment के तौर पर, क्या bash में बेहतर assignment statement नहीं जोड़ा जा सकता? उदाहरण के लिए set --goodass जैसे mode में अगर a = string1 + '.' + string2 जैसा लिखा जा सके, तो shell quoting handling का बड़ा हिस्सा काटा जा सकता है
      make जैसे tools को भी फायदा होगा। अगर make पर 6 महीने लगाकर usable variables, paths और filenames manipulate करने के साफ़ तरीके, और अधिक उपयोगी targets बनाए जाएँ, तो यह 6 महीने तक complex Makefile बनाने से बेहतर हो सकता है
    • समस्या यह है कि junior उस implicit meaning को समझेगा या intended meaning से ज़्यादा literal ले लेगा
      खासकर “अधिकतर programmers के लिए bash उनकी रोज़मर्रा की किसी भी language से अलग है” वाली समझ beginner ज़रूरी नहीं कि infer कर पाए। क्योंकि “uncommon” और “बेहद cryptic” के बीच का फर्क जानने के लिए experience चाहिए

  • संबंधित बात यह है कि ज़्यादातर software over-engineered है
    मुझे लगता है इसका एक कारण industry का centralization भी है। कुछ tools को control करने वाले कुछ लोगों के फायदे के लिए सभी को उन्हीं tools की ओर धकेला जाता है, और नतीजे में कई tools “हर चीज़ का tool” बन जाते हैं, जो अपने actual use cases से कहीं ज़्यादा cover करने लगते हैं
    companies चाहती हैं कि developers सभी वही tools जानें। इससे वे projects और companies के बीच आसानी से replaceable रहते हैं, और industry में उनकी bargaining power कमज़ोर होती है
    इसलिए software में सिर्फ एक mainstream धारा बचती है और alternative approaches jobs के बिना बाहर धकेल दी जाती हैं। industry स्वाभाविक रूप से distributed होना चाहती है, फिर भी ऐसा नहीं हो पा रहा
    सकारात्मक रूप से देखें तो कभी न कभी कहीं बेहतर non-mainstream approaches उभरेंगी और mainstream approach को काटेंगी। technology mathematics नहीं है और science से भी अलग है; यह एक ही problem को कई तरीकों से हल करने वाली कई branches को आराम से support कर सकती है

    • सहमत हूँ। कुछ मायनों में web development शुरुआती ASP.NET या Rails के दौर से पीछे गया हुआ भी लगता है
      तब browser wars ने हमें busy रखा था, लेकिन अब browsers काफ़ी हद तक compatible हैं, फिर भी हमने web apps के लिए frontend complexity का ढेर बना लिया है, जिसकी अक्सर ज़रूरत नहीं होती
      DNS, IP, HTTPS जैसी चीज़ें fundamental technologies हैं जिनमें backward compatibility और political factors जुड़े हैं, इसलिए यह unavoidable है
      फिर भी मुझे लगता है कि इन्हें अच्छी तरह सीखना frameworks सीखने से बेहतर investment है। और बोलूँ तो बात innovation tokens तक पहुँच जाएगी

  • मुश्किल चीज़ों को आसान बनाने के लिए सही abstraction ढूँढनी पड़ती है। कठिन विषय का कुछ हिस्सा और अक्सर इस्तेमाल होने वाली details ही दिमाग में रखी जाती हैं, बाकी ज़रूरत पड़ने पर खोज लिया जाता है
    समस्या यह है कि लोग किसी बड़े topic के लिए cognitive compression तब तक बनाने की ज़हमत नहीं उठाते जब तक सच में ज़रूरत न पड़ जाए। वे पहले से ही दूसरे बड़े cognitive burden ढो रहे होते हैं, इसलिए नया burden जोड़ने का विरोध करते हैं
    अगर किसी topic X को अच्छी तरह जानने वाले किसी और व्यक्ति पर निर्भर रहा जा सकता है, तो लोग बस वही करते हैं, और X को पर्याप्त रूप से समझने की कोशिश नहीं करते। X को अच्छी तरह जानने वाले व्यक्ति के लिए मदद की requests कम करने का सबसे अच्छा तरीका यह है कि वह दूसरों को X की न्यूनतम समझ हासिल करने में मदद करे
    set -e टूटा हुआ है, हर चीज़ को quotes में लपेटने की ज़रूरत भी टूटी हुई है, और globbing ऐसी feature होनी चाहिए जिसे explicit रूप से माँगा जाए। command line पर यह झंझट भरा होगा, लेकिन scripts में बात अलग है; अभी अगर globally globbing बंद कर दें, तो जहाँ चाहिए वहाँ globbing करना मुश्किल हो जाता है
    ऐसे खराब defaults सिर्फ Bash में नहीं, बल्कि Ksh और Bourne shell lineage के shells में आम तौर पर हैं
    SQL में भी बहुत से लोग clauses का order बदलना चाहते हैं। ऐसा न कर पाने की कोई वजह नहीं है, और मौजूदा SQL parser को दूसरे order में clauses allow करने के लिए यह शायद अपेक्षाकृत छोटा बदलाव होगा
    हालांकि निजी तौर पर मुझे यह cognitive समस्या नहीं होती, शायद इसलिए कि मैं जानता हूँ कि पहले table source देखना है

    • set -e का टूटा होना, हर चीज़ को quotes में लपेटना पड़ना, और globbing का explicit होना—इन तीनों pitfalls को OSH ठीक कर देता है, जबकि वह existing shell scripts भी चला सकता है
      script के सबसे ऊपर shopt --set ysh:upgrade जोड़ दें, तो ये तीनों समस्याएँ गायब हो जाती हैं
      अगर आप project में मदद करना चाहते हैं, तो tarball डाउनलोड करके इस दावे को verify करें और एक blog post लिखें
      details https://www.oilshell.org/release/latest/doc/error-handling.h... और https://www.oilshell.org/release/latest/doc/simple-word-eval... में हैं
      documentation comprehensive है, लेकिन ज़्यादातर लोग इतनी detail नहीं चाहते; इसलिए कोई test करके संक्षेप में लिख दे, तो मदद मिलेगी
      कुछ समय तक Oils को actively push न करने की वजह इसका Python dependency होना था, लेकिन अब यह pure C++ है और इस हफ्ते तक कुछ compute-heavy benchmarks में bash से आगे निकल रहा है
      I/O-heavy scripts की speed हमेशा वैसी ही रही है, जैसे ज़्यादातर shell scripts में होती है। documentation में Oil को अभी YSH में बदलना बाकी है, इसलिए कुछ समय तक confusion रह सकता है: https://www.oilshell.org/blog/2023/03/rename.html
    • बेहतर shells मौजूद होने के बावजूद ऐसे प्राचीन shells इस्तेमाल करते रहना ही समस्या है। users को set -e जैसी गुप्त जानकारी याद करने में समय बर्बाद नहीं करना चाहिए। फिर भी अब search engines तो हैं
    • SQL clause order को ठीक करने का एक थोड़ा radical तरीका यह हो सकता है कि project introduce किया जाए, जो select की तरह काम करे लेकिन सही जगह पर रखा जा सके
    • explanation में गैर-ज़रूरी details आ जाएँ तो बहुत confusion होता है। Chekhov की बंदूक की तरह आप उसे लगातार plot में fit करने की कोशिश करते हैं, लेकिन वह fit नहीं होती
      मेरी superpower मेरी भयानक memory है। इसलिए अगर मुझे याद रखना है, तो समझना ज़रूरी है—यानी cognitive compression चाहिए। मैं सामान्य लोगों की तरह बस सीख नहीं सकता
    • SQL की परत हटाकर निचली layer तक access मिलना चाहिए

  • आज की सीख: && या || सूची में चलाए गए commands में से आख़िरी && या || के बाद वाले command को छोड़कर, अगर कोई command fail हो भी जाए तो shell exit नहीं होता
    संदर्भ: https://www.gnu.org/software/bash/manual/bash.html#index-set

    • “failure” shell की चिंता से ऊँचे स्तर की अवधारणा है। failure condition और response पूरी तरह programmer के विवेक पर निर्भर हैं, वे shell में assumptions के तौर पर built-in नहीं हैं
      /bin/false सिर्फ़ 1 return करता है। क्या वह failure है? नहीं। उसे ऐसा ही behave करने के लिए design किया गया है और वह सचमुच उसी उद्देश्य वाला tool है
      मैंने सैकड़ों shell scripts लिखी हैं, और उनमें से कई commands अपना काम करने के लिए—जैसे यह जांचना कि string किसी खास pattern से match करती है या नहीं—बिल्कुल सामान्य रूप से non-zero value return करती हैं
      program किसी भी स्थिति में अपनी पसंद का exit code return कर सकता है, और convention के अनुसार success 0 है, failure non-zero value है। लेकिन shell language को सिर्फ़ इस बात से मतलब है कि 0 “true” और non-zero value “false” के रूप में evaluate होती है
      अगर कोई भी program हर बार non-zero value return करे और shell exit हो जाए, तो if statements और loops असंभव हो जाएंगे और यह बहुत असुविधाजनक होगा
      अगर किसी script के लिए किसी खास program का return code महत्वपूर्ण है, तो उसे explicitly check और handle करना चाहिए। जैसा कि link में है, ऐसे options हैं जिनसे internal command के non-zero value return करने पर shell exit हो जाता है, और कई beginner/intermediate shell script लेखक dogmatically कहते हैं कि हर script में उनका उपयोग करना चाहिए
      लेकिन complex scripts में मुझे लगता है कि इसके कई edge cases कुछ hacky और संभालने में मुश्किल हैं। अगर हर बार ऐसे options की ज़रूरत पड़ती है, तो शायद Makefile इस्तेमाल करना बेहतर हो
    • क्योंकि && और || अक्सर conditionals की तरह इस्तेमाल होते हैं
      [ -e README ] && cat README README file न होने पर error से बचाता है, और [ -e README ] || echo "You should write a README!" उल्टा काम करता है
      ज़्यादा subtle issue यह है कि set -e मान लेने पर भी pipelines में अगर आख़िरी command fail नहीं होता, तो shell exit नहीं होता
      grep foo README | sort README न होने पर भी fail नहीं होगा, जब तक कि set -o pipefail भी इस्तेमाल न किया जाए
    • मैं इसे shell language design की सबसे बड़ी खामियों में से एक मानता हूं। क्योंकि function अपने arguments से स्वतंत्र होकर, जिस context में call किया गया है उसके आधार पर अलग परिणाम दे सकता है
      यहां तक कि function के अंदर explicitly set -e set करने पर भी यह override हो जाता है
      मैंने पहले एक example दिया था: https://news.ycombinator.com/item?id=22213830
    • shell में सीखने के लिए बहुत-सा vision knowledge बाकी है। किसी point पर कंधे उचकाकर यह स्वीकार करना पड़ता है कि जल्दी result पाने के लिए तो यह ठीक tool है, लेकिन robust programs लिखने के लिए उपयुक्त नहीं

  • यह लेख उन चीज़ों का अच्छा वर्णन करता है जो दिखने में मुश्किल नहीं लगनी चाहिए, लेकिन असल में उनमें बहुत complexity होती है
    हालांकि SQL वाला हिस्सा रहस्य खोलने के बजाय conceptual failure को और आगे बढ़ाता हुआ लगता है
    query की logic declarative होती है और output define करती है। execution order या procedural nature वाली चीज़ query plan है। इसे पहले सीखना चाहिए
    फिर dependent subqueries जैसे ambiguous areas सीखे जा सकते हैं। अगर आप देख सकें कि not exists और anti-join equivalent हैं, तो आप समझ और reason कर सकते हैं
    लिखी हुई query को procedurally समझने जैसी analogy सिर्फ़ problem को पीछे धकेलती है, और जब आप किसी अधिक complex चीज़ में अटकते हैं तो उस well-intentioned lie को खोलने का तरीका नहीं बचता

    • SQL वाला हिस्सा query को समझने में मदद करने वाले mental model की बात कर रहा था, और यह भी कहा गया था कि वास्तविक database शायद उसे इस तरह process नहीं करता
    • Postgres पर हाल का related episode है, लेकिन कई मामलों में इसे दूसरे databases तक भी extend करके सोचा जा सकता है: https://www.se-radio.net/2023/09/se-radio-583-lukas-fittl-on...

  • शानदार presentation था। यह बात सही है कि Bash “traps” और trivia से भरा है और सब कुछ याद रखना मुश्किल है, लेकिन मुझे लगता है कि कुछ trivia याद रखना भी अच्छा है
    उदाहरण के लिए, मैं अक्सर find command arguments का order भूल जाता था, और जब ऐसे machine के सामने होता था जहां internet तुरंत available नहीं होता, तो syntax याद करने में समय गंवा देता था
    इसलिए मैंने सबसे आम command-line tools और उनके कुछ traps सीखने और याद करने का फैसला किया, और Anki तथा कुछ mnemonics इस्तेमाल किए। मुझे लगता है investment पर return काफ़ी worthwhile था

    • Anki, DNS जैसी मुश्किल चीज़ें समझने में मेरी lifeline है
      वास्तव में, jvns.ca की book recommendation देखकर मैंने Michael W. Lucas की Networking for System Administrators पढ़ी, और technical knowledge तथा अच्छी-खासी system administrator wisdom को Anki cards में निकाला
      अब transport layer problems debug करते समय मुझे तुरंत याद रहता है कि netcat और tcpdump जैसे tools कैसे इस्तेमाल करने हैं, इसलिए यह मेरे पढ़े हुए books में investment पर सबसे ज़्यादा return देने वाली किताबों में से एक हो सकती है
    • मैं उन commands की file maintain करता हूं जिन्हें मैं अक्सर इस्तेमाल नहीं करता। जैसे ffmpeg से volume बढ़ाने या convert से image में border जोड़ने वाली commands
      मैंने last run command को इस file में add करने का shortcut और इस file में search करने का shortcut भी बनाया है
    • man pages तुरंत इस्तेमाल किए जा सकते हैं
      bash man page बहुत बड़ा और complex है, लेकिन comprehensive है। अगर आप main sections और text के visual shape से familiar हैं, तो जल्दी-जल्दी scroll करके ज़रूरी exact information ढूंढ सकते हैं, और यह काफ़ी उपयोगी रहा है
      कई बार यह तरीका internet search engine इस्तेमाल करने से भी तेज़ होता है
    • internet पर निर्भर हुए बिना और खराब design को याद किए बिना काम चलाने के लिए, ज़्यादा general documentation/cheatsheets में invest करना बेहतर हो सकता है
      जैसे पुराने man pages को text editor-friendly format में convert करना, या tldr, Dash जैसे बेहतर tools इस्तेमाल करना। क्योंकि ऐसा सिर्फ़ find के साथ नहीं है
    • Bash इस्तेमाल करना बंद करके उसकी जगह TypeScript इस्तेमाल करनी चाहिए। Bash भयानक है

  • पता नहीं क्यों, मैं इस लेख को नापसंद करना चाहता था। शायद jvns HN पर बहुत ज़्यादा दिख रही थीं, या मेरा मूड खराब था
    लेकिन यह सच में बहुत अच्छा लेख है, और 20 साल के development experience वाले व्यक्ति के तौर पर मुझे लगता है कि programming पर meta-level चर्चा में यह काफी हद तक सच के करीब है
    चयनात्मक दृष्टि वाली बात dig और man pages दोनों पर सचमुच लागू होती है। अनगिनत बार ऐसा हुआ है कि man खोलते ही अंतहीन config options और command-line flags देखकर मैं overwhelm हो गया
    man में मेरी tip Vim-style search feature / इस्तेमाल करने की है। जैसे, अगर grep में हर match का line number print करने का तरीका ढूंढना हो और याद न हो, तो man grep खोलें, फिर /line टाइप करें और Enter दबाकर man page में “line” के occurrences search करें। अगला match बस / से मिलता है
    Strange Loop के खत्म होने की खबर भी थोड़ी दुखद है। मुझे इसके बारे में पिछले साल के आसपास ही पता चला था, लेकिन कई talks असाधारण रूप से high quality लगती थीं

    • हाल में अपलोड हुई Alex Miller की talk देखना अच्छा रहेगा: https://www.youtube.com/watch?v=suv76aL0NrA
      इसके खत्म होने का दुख है, लेकिन यह काफी convincing तरीके से दिखाती है कि कभी-कभी किसी चीज़ का खत्म होना भी अच्छा होता है। पूरी talk देखने पर समझ आएगा
    • https://cheat.sh एक life saver है
      और मैंने https://github.com/kristopolous/mansnip भी बनाया है
    • अगले match के लिए n भी दबा सकते हैं

  • bash पर दिए गए नजरिए से मैं कड़े तौर पर असहमत हूं। सबसे अच्छा समाधान bash के ऊपर tools चढ़ाना या उसकी quirks याद करना नहीं, बल्कि bash का इस्तेमाल न करना है
    pitfalls से बचने का यही एकमात्र तरीका है

    • मुझे अब तक bash का कोई सही replacement नहीं मिला है। खासकर scripts में तो और भी नहीं
      सबसे आम विकल्प हैं 1) Oil shell [0] जैसा नया shell इस्तेमाल करना, या 2) Python, JavaScript, PHP जैसी programming language इस्तेमाल करना
      नए shell की समस्या यह है कि जहां-जहां script चलानी हो, वहां वह shell install करना पड़ेगा। इसके उलट bash हर जगह मौजूद है। अगर script सिर्फ आप अकेले maintain नहीं कर रहे, तो आप दूसरों से भी वह shell सीखकर maintain करने की अपेक्षा कर रहे होते हैं
      दूसरी programming languages की समस्या यह है कि bash जिस काम में अच्छा है—commands को जोड़ना और command input/output व files संभालना—उसकी usability असाधारण रूप से अच्छी है
      किसी दूसरी language में वही करने की कोशिश करें तो अचानक सब बहुत ज्यादा complex हो जाता है, या कम-से-कम ज्यादा verbose
      इसलिए मैं अब भी bash इस्तेमाल करता हूं, लेकिन यह मानते हुए कि इसकी ताकत दूसरे commands चलाने और I/O संभालने में है। ऐसी चीज़ों से असंबंधित complex logic हो तो उसे दूसरी language में भेज देता हूं। कभी-कभी इसका मतलब bash से पूरी तरह बचना नहीं, बल्कि bash से Python script call करना भर होता है
      अगर कोई दूसरा approach आपके लिए बेहतर रहा हो तो share करें
      [0] https://www.oilshell.org
    • यह सही point है। bash बहुत ज्यादा complex tool है, और उसे कम complex बनाने के लिए उसके ऊपर एक और tool लिखना अजीब है
      उस नए tool के पास bash ने जिन दशकों की debugging झेली है, वह भी नहीं होगी। समस्या खुद bash में है
      हम usability को कम आंकते हैं और “cleverness” को ज्यादा महत्व देते हैं
      इसका classic उदाहरण Git है। यह बेहद clever tool है, लेकिन usability भयानक है। फिर भी इसे Linus ने बनाया है और Linus clever हैं, तो लगता है समस्या हममें ही है
      हमें वही मिलता है जिसे हम value करते हैं। हमें usability को ज्यादा value देना चाहिए
    • मैं shellcheck का बड़ा fan हूं और bash को सच में गहराई से इस्तेमाल कर चुका हूं, लेकिन कोई linter या bash के ऊपर बना tool इसे ठीक नहीं कर सकता
      सबसे अच्छा उपाय बस इससे दूर रहना है। सच में रुकना होगा। macho बनने की कोशिश नहीं करनी चाहिए
      language का पूरा model बुनियादी तौर पर टूटा हुआ है। string-centric types, global mode switches, basic comparison operators के लिए single-letter flags, जगह-जगह errors को default रूप से ignore करने वाला behavior, और खासकर functions तक
      ऐसी एक quirk भी किसी language को reject करने के लिए काफी होती, लेकिन bash में ये सब हैं और उससे भी ज्यादा
    • bash इसलिए अजीब है क्योंकि यह general-purpose language नहीं है। लेख में जिन चीज़ों का जिक्र है, उनके भी अपने अच्छे कारण हैं। जैसे set -x का || और && के expected behavior को तोड़ सकना
      आखिर ऐसी कौन-सी language है जिसमें function के false return करने पर clash हो जाए? कुछ languages exceptions throw करती हैं, लेकिन “false” तो return करने लायक valid value नहीं है क्या
      Makefile में भी यही चीज़ दिखती है। लोग समझते नहीं कि वे क्या कर रहे हैं, और build systems के बारे में गहराई से कभी सोचा नहीं होता, इसलिए वे उम्मीद करते हैं कि यह किसी खास तरीके से behave करे
      उदाहरण के लिए Make की recursive assignment लगभग सभी को फंसा देती है
      FLAGS=-b, COMPILE=compile $(FLAGS), $(info compile command=$(COMPILE)), FLAGS=-a, myfile:, echo $(COMPILE) $? -o $@ में पहली info output compile -b दिखाती है, लेकिन actual execution compile -a -o myfile होता है
      लेकिन अगर दूसरी programming languages से match कराने के लिए सभी assignments को immediately evaluated बना दें, तो आप एक बहुत useful tool छीन लेंगे। ऐसे tools को जितना ज्यादा समझते हैं, उतना बेहतर पता चलता है कि उन्हें कहां इस्तेमाल करना है और कितनी मेहनत लगानी है
    • कहना जितना आसान है, करना उतना नहीं; और bash को पूरी तरह हटाना समय और effort के हिसाब से हमेशा worth it न भी हो सकता है
      फिर भी broadly सहमत हूं। थोड़ा भी complex कुछ हो तो उसे कम quirky language में लिखी script को सौंपने की कोशिश करता हूं
      ऐसे में bash में बचने वाले आखिरी 5% में गलतियों से बचाने वाले tools बहुत उपयोगी होते हैं