3 पॉइंट द्वारा GN⁺ 8 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • LLM और vibe coding के दौर में भी कोडिंग सिर्फ नौकरी पाने की स्किल से बढ़कर गणित, सीखने के तरीके और रचनात्मक अभिव्यक्ति सीखने का माध्यम बनी हुई है
  • “learn to code” का वह माहौल, जहाँ इसे तेज़ी से सामाजिक-आर्थिक उन्नति के नारे की तरह इस्तेमाल किया जाता था, अब कमजोर पड़ा है, और JavaScript की कुछ पंक्तियों से छह अंकों वाली सैलरी की गारंटी नहीं मिलती
  • LOGO और Mathland जैसे उदाहरणों की तरह, कोडिंग निर्देश रटने के बजाय खोज के जरिए गणित समझने में मदद करती है, और साथ ही debugging, संरचना और logic का अभ्यास कराती है
  • प्रोग्रामिंग लेखन की कल्पनाशीलता, गणित की सटीकता और गेम जैसी तुरंत मिलने वाली feedback को जोड़ती है, ताकि आप अपनी इच्छित चीज़ को उस भाषा में ढाल सकें जिसे कंप्यूटर चला सके
  • LLM अंग्रेज़ी और कोड दोनों को अच्छी तरह संभाल सकते हैं, फिर भी जैसे humanities का मूल्य खत्म नहीं हुआ, वैसे ही सार्वभौमिक code literacy की ज़रूरत भी बनी हुई है

नौकरी की गारंटी से आगे कोडिंग का मूल्य

  • Val Town के संस्थापक Steve Krouse, जो कोड लिखने और deploy करने के लिए एक “Silicon Valley startup” चलाते हैं, फिर भी कहते हैं कि हर किसी को कोडिंग सीखनी चाहिए
  • Making Sense with Sam Harris #481 में यह बात सामने आती है कि Silicon Valley में “learn to code” जैसा वाक्य कई महीनों से सुनाई नहीं दिया था
  • एक समय “learn to code” को गरीबी से जल्दी बाहर निकलने के रास्ते की तरह बार-बार दोहराया जाता था, लेकिन JavaScript की दो लाइनें जोड़कर लिख लेने से छह अंकों वाली सैलरी अपने-आप नहीं मिलती
  • कोडिंग, गणित, साहित्य, विज्ञान और humanities की तरह, सिर्फ पेशेवर उपयोगिता के लिए नहीं बल्कि शैक्षिक कारणों से भी सीखने लायक है

गणित सीखने और सोच को प्रशिक्षित करने का माध्यम

  • कोडिंग गणित सीखने का एक शक्तिशाली माध्यम हो सकती है
    • Steve Krouse को एक after-school programming program के जरिए गणित पसंद आने लगा, और वे उम्मीद से कहीं बेहतर गणित सीख पाए
    • Seymour Papert चाहते थे कि बच्चे निर्देशों से नहीं बल्कि खोज के जरिए, जैसे वे भाषा सीखते हैं, वैसे ही गणित सीखें
    • Papert का “Mathland” दरअसल LOGO programming language था, जिसमें स्क्रीन पर एक कछुए को कमांड देकर चित्र बनवाए जाते थे
    • Steve Krouse ने एक LOGO version भी बनाया, जिसे ऑनलाइन आज़माया जा सकता है
  • प्रोग्रामिंग सीखने की प्रक्रिया में debugging, संरचना और logic जैसी meta-skills भी विकसित होती हैं, और यह एहसास भी पैदा होता है कि ऐसा कुछ नहीं जिसे सीखा न जा सके

रचनात्मक गतिविधि के रूप में प्रोग्रामिंग

  • कोडिंग वह गतिविधि है जहाँ लेखन की रचनात्मकता, गणित की सटीकता और video game जैसी तत्काल feedback loop मिलती है
    • यह आपको अपनी मनचाही चीज़ को ऐसी सटीक भाषा में ढालने पर मजबूर करती है जिसे कंप्यूटर वास्तव में कर सके
    • इसे इस तरह भी समझाया गया है कि अजनबी syntax सीखने के बाद आप अपनी कल्पना की चीज़ें कंप्यूटर से सचमुच बनवाते हैं, इसलिए यह किसी मंत्रोच्चार जैसा लगता है
  • LLM अंग्रेज़ी और कोड दोनों अच्छी तरह लिख सकते हैं, लेकिन जैसे humanities की प्रासंगिकता खत्म नहीं होती, वैसे ही कोड भी अब भी महत्वपूर्ण है
  • कानूनी दस्तावेज़ों की तरह, कोड कभी-कभी जटिल और उबाऊ विवरणों से भरा लग सकता है, लेकिन यही दुनिया के चलने की बुनियाद है, और सुंदर ढंग से लिखी गई कोड की एक पंक्ति दुनिया बदल सकती है
  • प्रोग्रामिंग एक आनंददायक गतिविधि है, और LLM के दौर में भी सार्वभौमिक code literacy या “वास्तविक कंप्यूटर क्रांति” का सपना जारी है

1 टिप्पणियां

 
GN⁺ 8 시간 전
Hacker News की राय
  • LLM से पहले भी जो लोग कोडिंग कर सकते थे, उनमें भी कोडिंग कौशल पहले से ही घट रहा है, और लगता है कि अगले 10–20 साल तक ऐसा ही रहेगा
    इसी अवधि में कोडिंग सीखने का प्रतिफल भी बहुत बड़ा नहीं हो सकता
    आखिरकार भविष्य के LLM को ट्रेन करने वाला कोड सिर्फ LLM-जनरेटेड कोड ही होगा, और production codebase की गुणवत्ता इतनी नीचे चली जाएगी कि इंसानों के लिए भी समझना मुश्किल होगा और LLM के लिए भी maintain करना कठिन, और तब दरारें दिखने लगेंगी
    तब कोडिंग फिर से मूल्यवान कौशल बन जाएगी, लेकिन करियर की योजना बनाने के लिहाज से वह समय अनिश्चित है, और market किसी व्यक्ति के टिके रह सकने की अवधि से ज्यादा लंबे समय तक irrational रह सकता है

    • यह Isaac Asimov की Profession जैसा है
      तब भी ऐसे लोगों की जरूरत होगी जो खुद कोड लिखें और craftsmanship को फिर से बहाल करें
      अगर हर कोई generated code पर निर्भर हो जाए, तो वे सिर्फ वही दोहरा पाएंगे जो पहले से ज्ञात है, और केवल वे लोग जिन्होंने सचमुच पढ़ाई करके कठिन रास्ता सीखा है, नए ज्ञान बनाने और नई educational tapes बनाने की creativity और intelligence रखेंगे
    • यह काफी optimistic अनुमान है
      production codebase का इंसानों के लिए समझ से बाहर हो जाना और LLM के लिए maintain करना मुश्किल हो जाना—ये पहले दो चरण तो होंगे, लेकिन उसके बाद कोडिंग का फिर से मूल्यवान होना, यह तीसरा चरण शायद नहीं होगा
      खासकर management अपनी expectations घटा देगा, या ऐसा करने के लिए मजबूर होगा
      बस सोचिए कि “नया और बेहतर version” कितनी बार उन महत्वपूर्ण features को बिना उचित replacement के हटा देता है जिन्हें लोग पहले इस्तेमाल करते थे
      जब codebase unmaintainable हो जाएगा, तो वे बस नया कचरे का ढेर फिर से generate करेंगे, और इधर-उधर random बदलावों को improvement कहेंगे
    • मेरे पास उल्लेख करने लायक आखिरी Fujitsu laptop है और मैं उसका बड़ा fan हूं
      करीब 5 साल पहले जब Fujitsu ने laptop production फिर से शुरू करने की कोशिश की, तो असल तरीका retired Japanese workers को फिर से इकट्ठा करना था
      लगता है युवा पीढ़ी के पास skills नहीं थीं या वे करना नहीं चाहते थे, और कुछ production runs के बाद यह खत्म हो गया
      Panasonic अभी भी enterprise laptops बनाता है, लेकिन वे बहुत महंगे हैं, और यह कहानी इस विषय से सीधे जुड़ी है
    • Claude के साथ productive programmer बनने के लिए अब भी यह समझना जरूरी है कि आप क्या कर रहे हैं
      कोडिंग सीखना अनिवार्य है, और क्या संभव है और क्या आसान है, यह जाने बिना आप यह भी नहीं जान सकते कि कितनी मांग रख सकते हैं
      जो चीज कम महत्वपूर्ण होती जा रही है, वह है धार को लगातार तेज बनाए रखना
      अगर कुछ समय तक कम कोड लिखें तो off-by-one errors या copy/paste mistakes बढ़ जाते हैं, लेकिन LLM की वजह से coding instincts को गरम बनाए रखने का महत्व घट जाता है
      फिर भी अगर मुझे खुद करना नहीं आता, तो Fable होने पर भी मैं अपना काम नहीं कर पाता
    • यह ज्यादा कुछ ऐसा होगा कि “बुजुर्ग developers लगातार code quality में गिरावट को कोसते रहेंगे और पुराने programming दिनों को याद करेंगे”
      इस बीच पहले से कहीं ज्यादा लोग software बनाएंगे और इस्तेमाल करेंगे, और “सब कुछ बर्बाद हो रहा है” वाले लंबे भाषण हास्यास्पद रूप से बढ़ा-चढ़ाकर कहे गए लगेंगे
  • “कोड साहित्य या संगीत जितना ही समृद्ध, सुंदर creative expression का रूप है” यह बात अतिशयोक्ति जैसी लगती है, और संदेह होता है कि लेखक साहित्य और संगीत से कितना परिचित है
    ज्यादातर programming plumbing work के ज्यादा करीब है
    आना, पिछले worker पर बड़बड़ाना, और अपनी विशिष्ट constraints वाले puzzle को हल करना
    LLM coding में अच्छे इसलिए हैं क्योंकि coding में हमें उबाऊ और साधारण code चाहिए होता है

    • ज्यादातर programming फेंक देने लायक कचरे जैसी है, और अगर plumbing के साथ ऐसा व्यवहार होता तो हम सचमुच बहुत गंभीर गंदगी में रह रहे होते
      plumber कभी आकर पिछले व्यक्ति को गाली नहीं देता था; वह कुछ बदलता था या मेरे द्वारा बिगाड़ी गई चीज ठीक करता था
      उसका नतीजा सालों, दशकों तक पूरी तरह काम करता था, भले ही मैं उसे अच्छे से न संभालूं
      चीजों को उबाऊ और साधारण बनाना भी बेहतर शब्द न होने पर कला कहा जा सकता है
      function names को न तो abbreviated code जैसा रखा जा सकता है और न ही ThisIsTheEntryPointOfTheProgram() जैसा; क्या बेहतर है, यह अंतहीन सोच-विचार और बहस का विषय बन जाता है
      हम बार-बार replacement और bloat को स्वाभाविक मान लेते हैं, इसलिए ऐसी “छोटी” चीजों को हल्के में लेते हैं, लेकिन plumbers ऐसा कभी नहीं करते
      वे हर हफ्ते नया pipe material introduce करके अगले trend पर switch नहीं करते, और आम तौर पर ऐसी चीजें बनाते हैं जो इंसानों से ज्यादा टिकती हैं, इसलिए उनका पेशा किसी बिल्कुल अलग ग्रह का लगता है
    • लगता है दोनों एक ही fence के opposite sides पर हैं
      demoscene मजे और creative expression के लिए programming है, और IOCCC भी है
      यह creatively written fiction के बराबर है
      इसके उलट, knowledge base लिखने की तरह सिर्फ नौकरी के तौर पर की जाने वाली writing भी होती है, और वह CRUD और cloud जैसी plumbing-style programming है
    • ज्यादातर programming ऐसी हो सकती है, लेकिन ज्यादातर संगीत और साहित्य भी शायद uninspired junk ही होते हैं
      फिर भी Knuth की किताबों में मिलने वाले जैसे सुंदर algorithms बहुत हैं, और निजी तौर पर वे मुझे किसी भी संगीत से ज्यादा सुंदर लगते हैं
    • मुझे यह बिल्कुल भी अतिशयोक्ति नहीं लगता
      बल्कि यह तर्क दिया जा सकता है कि code अधिक सामान्य होने के कारण साहित्य या संगीत से ज्यादा expressive है
      सभी संभावित video games, demos/intros, generative images, generative music के space के बारे में सोचिए—ये सब code के बिना असंभव हैं
      लगता है आप medium के आम उपयोग और उसकी expressiveness को मिला रहे हैं
      रोजमर्रा की भाषा के कई उपयोग भी दिलचस्प नहीं होते, लेकिन हमें संभावनाओं के पूरे space को देखना चाहिए
    • संगीत या साहित्य जैसी कला का उद्देश्य कला स्वयं होती है
      code craft है और किसी उद्देश्य का साधन है
      यह फिर भी सुंदर, प्रभावशाली और creative हो सकता है, लेकिन यह अलग किस्म की चीज है
      यह मूल्य-निर्णय नहीं है
      कला भी खराब या फीकी हो सकती है, और code भी genius-level परिणाम हो सकता है
      लेकिन lunar lander या handmade watch सुंदर इसलिए होती है क्योंकि वह सचमुच काम करती है, और उसकी तुलना संगीत से करना कठिन है
  • एक पेशेवर programmer के तौर पर, जो अपने मज़ेदार career के आखिरी एक-तिहाई हिस्से में है, अब मैं coding सीखने को “कवि बनकर रोज़ी कमाने” जैसी category में रखता हूँ
    यह सचमुच आनंद देने वाली कला है और कुछ लोग इसकी कद्र भी करते हैं, लेकिन रोज़गार के लिए अलग योजना बनाना बेहतर है
    जो senior लोग पहले से coding जानते हैं, वे अभी तो ठीक-ठाक दिख रहे हैं, लेकिन काम धीरे-धीरे model को junior contributor की तरह संभालने वाला बनता जा रहा है

    • अगर असल में coding नहीं आती, तो वह देखभाल वाला काम भी संभव नहीं है
    • बात गलत नहीं है, शायद
      मुझे बहुत पहले का एक दोस्त याद आता है
      उसने Harvard में early music major किया था, MFA लिया था और बेहद प्रतिभाशाली था
      वह Latin और Greek पढ़-लिख सकता था, medieval notation में संगीत रच और बजा सकता था, और उसने early embroidery पर एक किताब भी लिखी थी
      लेकिन उसे academia में पद नहीं मिला, और ऐसी job भी नहीं मिली जिसे उसके कौशल की ज़रूरत हो
      कुछ साल पहले वह अकेले ही दुनिया से चला गया
      कई programmers की किस्मत भी ऐसी हो सकती है
    • मैं कुछ समय से यही कह रहा था, और आखिरकार field पूरी तरह बदल दी
      लोग इस बात से चिपके रहे कि LLM सच में developers को replace नहीं कर सकता, और यह सच है, लेकिन महत्वपूर्ण नहीं है
      job market को बड़े पैमाने पर हिलाने के लिए बस इतना काफी है कि LLM जो हिस्सा नहीं कर सकता, उसे संभालने के लिए ज़रूरी लोगों की संख्या घट जाए
      मौजूदा developers की efficiency अगर सिर्फ 30% भी बढ़ जाए, तो developers की demand 20% घट सकती है, और इसका demand व salary पर बहुत बड़ा असर पड़ेगा
    • लगता है यह region पर बहुत निर्भर करता है
      पश्चिमी देशों के बाहर, जहां AI को अपनाया नहीं जा रहा है, https://hai.stanford.edu/ai-index/2026-ai-index-report के अनुसार AI ने software demand को बढ़ाया है
    • जानना चाहूँगा कि आप कौन-सा data देख रहे हैं
  • अभी मैं जो करना चाहता हूँ, वह है कुछ बनाना, लेकिन LLM से code लिखवाए बिना
    सलाह लेने के लिए अब भी इसका इस्तेमाल कर रहा हूँ
    मैं Elixir में Dota2 tournament match aggregator बना रहा हूँ; यह tournament streams को लेकर उन्हें chronological order में arrange करता है, ताकि YouTube पर लगातार video series देखने की असुविधा कम हो
    इसे बनाने की वजह यह है कि मुझे programming पसंद है, और मुझे चीज़ें बनाना पसंद है
    LLM मुझे intellectually lazy बनाता है, और उससे बनाई चीज़ में संतुष्टि कम मिलती है
    मैं बनाना चाहता हूँ, और बनाना चाहना मानवीय है

    • इंसान जो भी महसूस करता है—बनाना चाहे या न बनाना चाहे—सब मानवीय है
      कोई व्यक्ति किसी तरह की making पसंद करता है, कोई दूसरा किसी और तरह की, और यह ठीक है
      आखिरकार लगता है कि बहुत लोग भूल जाते हैं कि programming काफी creative activity है
      थोड़ा विवादास्पद ढंग से कहूँ तो, program बनाना अच्छे या बुरे अर्थ में पुल बनाने से ज़्यादा painting करने के करीब है
    • इन दिनों Seneca पढ़ रहा हूँ, और उसके एक letter में यह वाक्य था
      “काम पर ध्यान केंद्रित करने का वही flow अपने-आप में गहरा सुख देता है। काम खत्म होने के बाद finished product से मिलने वाला आनंद वैसा नहीं होता। कलाकार result का आनंद लेता है, लेकिन painting करते समय वह कला का ही आनंद लेता है”
      LLM की समस्या ठीक यही है
      इसने मुझसे programming की कला को उसी क्षण enjoy करने का सुख छीन लिया
    • stratz / opendota से Dota2 matches का aggregation काफी किया है
      data इतना ज़्यादा है कि सच में मज़ेदार है, और इसने निश्चित रूप से मुझे बेहतर programmer बनाया
  • निजी तौर पर, LLM से पहले जो परिचित बहुत अच्छे developer नहीं थे, वे आज भी latest models का इस्तेमाल करके खराब code बना रहे हैं
    अच्छी architecture और सामान्य practices की मजबूत knowledge और समझ अब भी core है
    यह भूलना आसान है कि जिन बुनियादी knowledge और instincts को हम आज obvious मानते हैं, उन्हें कम experience के समय सीखने में बहुत समय और मेहनत लगी थी

    • पूरी तरह सहमत हूँ
      यह phenomenon हमेशा दिखता है
      LLM force multiplier tool हो सकता है, लेकिन जो व्यक्ति सही सवाल नहीं पूछ पाता या subtle differences नहीं समझता, वह खराब code बनाएगा, और वही खराबियाँ amplify होंगी
      मुझे नहीं लगता कि मौजूदा models इससे बच सकते हैं, खासकर यह भी सीमा है कि training data historically इंसानों द्वारा बनाया गया है
  • क्या कोई ऐसे mathematician को जानता है जिसे long division या basic algebra नहीं आता?
    शायद नहीं
    क्योंकि basic math, advanced math सीखने के लिए ज़रूरी है, इसलिए ऐसा व्यक्ति होता ही नहीं
    अगर आप mathematician बनना चाहते हैं, तो calculator basic calculations करता है या नहीं, यह अप्रासंगिक है
    उसी तरह, “5 साल बाद average developer हाथ से code लिखेगा या नहीं” का इस बात से कोई संबंध नहीं कि किसी भी तरीके से complex software design और build करने में mastery हासिल करनी हो, तो coding सीखनी चाहिए या नहीं

    • अभी नहीं, लेकिन पहले research mathematician था
      long division कैसे करते हैं, मुझे बिल्कुल याद नहीं, लेकिन एक समय में मैं इसमें निश्चित रूप से निपुण था
      आजकल mental math भी बहुत खराब है
      फिर भी mathematician बनने के रास्ते में ये चीज़ें essential थीं, बस abstraction level बढ़ने के साथ उनकी relevance खत्म हो गई
    • मेरा नजरिया उल्टा है, लेकिन निष्कर्ष वही है
      mathematicians से मैंने अक्सर यह मज़ाक सुना है कि “जितना advanced जाते हो, उतना math में खराब होते जाते हो”
      ज्यादातर mathematicians को long division problem हल करने के लिए काफी सोचना पड़ेगा, क्योंकि वे उस skill को बहुत पहले पीछे छोड़ चुके हैं
      फिर भी calculator और Python notebooks होने के बावजूद लोग field को आगे बढ़ाने के लिए हर level पर हाथ से math सीखते और करते हैं
      लोग LLM में ऐसे डूब गए हैं जैसे वही भविष्य का सब कुछ हो, लेकिन LLM खुद पूरी तरह अतीत की उपज है
      LLM सोचने वाली machine से ज़्यादा भाषा, और भाषा में व्यक्त knowledge का lossy-compressed JPEG जैसा है
      इसलिए field को विस्तार देने और भविष्य की ओर बढ़ने के लिए हम सिर्फ average की ओर लौटाने वाले algorithm पर निर्भर नहीं रह सकते
  • क्या AI एजेंट जिन coding tasks को मुख्य रूप से replace कर रहे हैं, वे development की बाहरी परत नहीं हैं?
    मेरा मतलब end-user applications, apps, dashboards, business applications जैसी चीज़ों से है
    इस “ऊपरी खोल” में लोग 99% accuracy या फूले हुए code को कुछ हद तक झेल लेते हैं, और vibe coding apps भी दावा कर सकते हैं कि वे “काफी अच्छे” हैं
    फिर भी देखना हो तो देख लें कि AI अपनाने के बाद Microsoft apps कैसी आपदा बन गए हैं
    लेकिन जिन core compilers, frameworks, tools और libraries पर लोगों को सच में निर्भर रहना पड़ता है, वहाँ अब भी LLM से बचा जा रहा है
    कोई भी 99% accurate या bloated code के ऊपर build नहीं करना चाहता, और कोई AI से coded web browser भी इस्तेमाल नहीं करना चाहता
    सचमुच अच्छे building materials बनाने हों तो खुद coding करनी होगी और यह जानना होगा कि आप क्या कर रहे हैं
    ऐसे core areas में coding को चरणबद्ध तरीके से हटाने के करीब पहुँचा कोई उदाहरण कहाँ है?

    • इसे सही तरीके से करने का तरीका है
      बस abstraction को conceptualize और refine करने में बहुत समय लग जाता है
      समस्या यह है कि conceptualization एक खास मानसिक अवस्था मांगती है
      LLM से पहले 10% कठिन सोच और 90% implementation होता था
      implementation एक तरह का reward था, और flow state में ideas को ठोस रूप देना बहुत अच्छा लगता था
      LLM के बाद अक्सर बस इधर-उधर टहलते हुए सोचता रहता हूँ
      अब यह करीब 40% सोच और 60% planning/code review जैसा है
      उसके बाद से मैंने flow state महसूस नहीं किया
      सोचना मज़ेदार है लेकिन थका देता है, और review बस झंझट है
      खासकर जब LLM अजीब failure patterns में फँस जाता है
      पहले खराब code देखकर तुरंत समझ आ जाता था कि लेखक क्या सोच रहा था और वह क्यों काम नहीं कर रहा
      अब code smells कम हैं, लेकिन गलत चुनी गई abstractions ज़्यादा हैं, इसलिए बहुत अधिक सावधान रहना पड़ता है
      सच में थकाऊ
    • इस तरह की बातें इंसानों द्वारा लिखे code को ऐसी quality बाद में दे देती हैं जो उसमें मूल रूप से थी ही नहीं
      “कोई भी 99% accurate या bloated code के ऊपर build नहीं करना चाहता” कहा गया, लेकिन दोस्त, क्या तुमने कभी Windows इस्तेमाल किया है?
    • पता नहीं कौन लोग ऐसी चीज़ें झेलते हैं
      आसपास के दोस्तों और परिवार से पूछूँ तो सभी धीमे और bloated software से नफरत करते हैं
      यह कितना समय और productivity खा जाता है, इसका अंदाज़ा भी नहीं
      LLM आने के बाद बेहतर होने के बजाय और खराब हुआ है
    • दूसरे paragraph वाली चीज़ें coding jobs का छोटा सा हिस्सा ही नहीं हैं?
      अगर programmer के रूप में रोज़ी-रोटी चलाने के लिए सिर्फ ऐसी jobs ही पकड़नी पड़ें, तो programming काफी हद तक sports जैसी हो सकती है
      जैसे basketball को amateur की तरह enjoy कर सकते हैं और high school या college में ज़्यादा गंभीरता से खेल सकते हैं, लेकिन basketball से पेट पालना हो तो NBA में जाने लायक अच्छा होना पड़ता है
    • हालिया Bun controversy क्या कुछ अलग कहानी नहीं दिखाती?
  • मुझे दिए गए तर्क बहुत कमजोर लगते हैं
    उम्मीद जगाने के बजाय उदासी हुई, और अगर बची हुई logic बस इतनी है तो लगता है मामला सच में बहुत desperate होता जा रहा है
    थोड़ा और खोलें तो, अगर coding कला है, तो यह सबसे खराब कला है
    यह Lego जैसी चीज़ के कहीं ज़्यादा करीब है, और meaningful assembly पूरी करने पर मिलने वाली संतुष्टि जैसी है
    शायद लेखक का point भी यही हो सकता है
    यानी pure hobby के रूप में अब भी इसकी value है
    “coding maths में मदद करती है” वाला दावा भी इसी तरह कमजोर है
    algebra में यह निश्चित रूप से मदद करती है, लेकिन कुल मिलाकर coding-style maths मुख्य रूप से coding-style maths में ही ज़्यादा मदद करती है
    यह loops, rules और conditionals वाली अजीब किस्म की maths है, और अगर software शुरुआत से इतना mainstream न होता तो यह भी mainstream नहीं होती
    परत हटाकर देखें तो वह logic किसी ठोस दावे से ज़्यादा circular लगती है

  • coding सीखने का मतलब है problem को समझना, उसे छोटे और manageable टुकड़ों में बाँटना, और फिर उन्हें वापस assemble करना
    इसमें debugging करना और बेहतर metrics की ओर iterate करना भी शामिल है
    ये बेहद valuable skills और mindset हैं जिन्हें दूसरे problem-solving domains में भी transfer किया जा सकता है

    • सही
      LLM से पहले भी यह अच्छी तरह पता था कि जब तक आप program खुद लिखकर न देखें, आप कह नहीं सकते कि आपने सच में समझ लिया है
      इसका कोई shortcut नहीं है
    • अगर आप coding नहीं जानते और सिर्फ prompt करना जानते हैं, तो good solution और bad solution में फर्क करने का कोई तरीका नहीं है
      आपके पास सबसे अच्छा विकल्प बस यही है कि model को आपकी जगह पता लगाने दें
      आप अच्छी API design करना या system को modules में बाँटना भी नहीं जानते
      समस्या यह है कि कई managers अच्छे programmer और vibe coder के बीच फर्क ठीक से नहीं समझ पाते
      vibe coder बहुत सारे PR डालता है
      शायद manager खुद भी vibe-coded PR डाल सकता है
      उन्हें यह विचार पसंद नहीं कि programmer उनसे बेहतर जान सकता है
    • Steve Jobs कहा करते थे कि सभी को programming सीखनी चाहिए
      क्योंकि यह सोचना सिखाती है
      https://youtu.be/BRTOlPdyPYU
  • यह कोई बहुत दमदार तर्क नहीं है
    अगर लोगों को coding सीखने के लिए मनाने का सबसे अच्छा आधार यह है कि यह mathematical notation जैसी है—यानी mathematics का वही हिस्सा जिससे beginners सबसे ज्यादा नफरत करते हैं—या यह कि यह violin की तरह सुंदर है—यानी नए लोगों के लिए बेकार—तो coding सच में गंभीर संकट में है
    मुझे लगता है बेहतर तर्क यह है कि यह computer की तरह सोचने में मदद करती है
    लेकिन अगर आप वही सीखना चाहते हैं, तो coding से पहले मैं कई video games में महारत हासिल करने की सलाह दूंगा
    ज्यादातर लोगों के लिए “coding सीखो” कहना programmers से “assembly language सीखो” कहने जैसा है
    मैं करीब 30 साल से coding कर रहा हूं

    • coding सीखने की सबसे दमदार वजह ठीक वही है जो बहुत सारी किताबें पढ़ने की वजह है
      क्योंकि यह दिमाग को तराशती है
      जो दिमाग basic logic और control flow को आसानी से क्रम में लगा, interpret और समझ सकता है, वह propaganda और influence का बेहतर प्रतिरोध करता है
      यह बहुत पढ़ने जैसा ही फायदा है, लेकिन सोचने के अलग रास्तों पर असर करता है
      आप ज्यादा worldviews से रूबरू होते हैं, हर एक के बारे में ज्यादा critical तरीके से सोचते हैं, और सामान्य critical thinking बढ़ती है
    • “ज्यादातर लोगों के लिए coding सीखना programmers से assembly language सीखने को कहने जैसा है” वाली बात सच में अच्छी लगी
      college course हो तो शायद assembly language सीख सकते हैं, लेकिन उसके अलावा कोई motivation नहीं है
      कोई assembly language पढ़ना नहीं चाहता था, और अब कोई code पढ़ना नहीं चाहता
    • मैंने एक बार math पसंद करने वाले दोस्त से कहा था कि कभी-कभी सोचता हूं, क्या मैं यह सोचे बिना बड़ा हो सकता था कि “मैं math में कमजोर हूं”; शायद वजह यही है
      problem solving अपने आप में मुश्किल नहीं है
      मैंने लोगों को अनजाने में code में “मुश्किल” math के टुकड़े दोबारा invent करते देखा है
      इसलिए मुझे लगने लगा कि शायद math को जानबूझकर डरावना बनाया गया है
    • मुझे लगता है video games को computer की तरह सोचने से जोड़ना बहुत ज्यादा abstract है
      computer के बारे में मैंने जो सबसे उपयोगी चीज सीखी, वह logic gates को हाथ से बनाना था
      किसी और चीज ने मुझे यह समझने में उससे ज्यादा गहराई नहीं दी कि computer कैसे काम करता है
      programming अगला कदम है
      बीच की सारी layers को reasoning से भर सकते हैं, इसलिए उन्हें छोड़ा जा सकता है
      assembly language सीखना जरूरी नहीं है, लेकिन अंदाजा पाने के लिए उसे पढ़कर देखना उपयोगी है
      logic gates से assembly language, programming, games, और अब AI तक जाने वाली layers को समझना networking समझने के लिए OSI model पढ़ने जैसा है
      यह abstraction layers का एक-एक करके चढ़ा हुआ ढांचा है
      programming सीखने लायक इसलिए है क्योंकि उसके ऊपर की हर चीज जिस सबसे ऊंची abstraction layer को share करती है, वह यही है
      programming languages सैकड़ों हों, फिर भी concepts काफी हद तक समान होते हैं, और एक language सीखकर programming समझ लेने पर उसे लगभग हर दूसरी language पर लागू किया जा सकता है
      इसके उलट games दसियों हजार हैं, सैकड़ों categories में बंटे हुए, और अगर बाकी applications भी शामिल करें तो उस स्तर पर variations का पेड़ विस्फोट की तरह फैल जाता है