समझ में आने वाले सॉफ़्टवेयर की ओर

 (gracefulliberty.com)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • प्रोग्रामिंग को पढ़ना·टेस्ट करना·मेंटेन करना कठिन है, और प्रोजेक्ट की समझ कुछ ही लोगों तक सिमट जाती है; इसलिए LLM से code writing को automate करने के बजाय ऐसी abstraction की ज़रूरत है जो code की आवश्यकता वाली सीमा को ही कम कर दे
  • LLM डेवलपर्स और non-developers दोनों तक फैल चुके हैं, लेकिन पर्यावरणीय नुकसान, चुराए गए code पर आधारित होना, असंगत परिणाम, और dependency पैदा करने जैसी समस्याएँ अब भी बड़ी हैं
  • शुरुआत का बिंदु यह है कि पहले code लिखकर बाद में documents जोड़ने की प्रथा को उलट दिया जाए, और document-first लिखने वाली literate programming की ओर बढ़ा जाए, जहाँ code बाद में आए
  • GUI-आधारित visual programming और deterministic natural language programming code को कई अभिव्यक्तियों में से सिर्फ़ एक बना सकते हैं, लेकिन visual environments में screen reader integration जैसी accessibility design अनिवार्य है
  • Eve और Inform जैसे पहले के प्रयास, और Entangled·ReTangled जैसे tools यह दिखाते हैं कि शुरुआती और विशेषज्ञ—दोनों के लिए समझ में आने वाले तरीके से software बनाना संभव हो सकता है

LLM लक्ष्य मॉडल नहीं है

  • LLM industrial software development में एक महत्वपूर्ण tool बन चुके हैं, और अनुभवी विशेषज्ञ भी testing, debugging, और code writing में LLM agents का उपयोग करते हैं
  • non-developers भी LLM की मदद से personal scripts से लेकर scientific data processing tools तक बना रहे हैं
    • प्रोग्रामिंग में शुरुआत कहाँ से करें यह स्पष्ट नहीं होता, और जो लोग किसी खास language की syntax और library details नहीं सीखना चाहते, उनके लिए इसकी accessibility कम है
  • LLM का फैलाव इस बात का संकेत कम है कि LLM प्रोग्रामिंग में बहुत अच्छे हैं, और ज़्यादा इस बात का कि प्रोग्रामिंग खुद जटिल और अप्रिय काम बन चुकी है
    • software stacks आपस में टकराते हैं, boilerplate अंतहीन है, और libraries झंझट भरी हैं
    • औसत software developer का काम दिलचस्प code बनाने के बजाय libraries को जोड़ने तक सिमट जाता है
  • LLM में अब भी बड़ी समस्याएँ बाकी हैं
    • ये पर्यावरण के लिए विनाशकारी हैं
    • ये मूल रूप से चुराए गए code पर आधारित हैं
    • ये असंगत code generate करते हैं
    • ये dependency पैदा करते हैं
  • मौजूदा programming paradigm भी अपर्याप्त है, लेकिन LLM के लिए भी एक बेहतर विकल्प चाहिए

Automation के बजाय abstraction

  • LLM को छोड़ देने का मतलब यह नहीं कि automation, higher-level abstraction, और human-friendly interfaces भी छोड़ दिए जाएँ
  • लक्ष्य सिर्फ़ code writing को आसान बनाना नहीं, बल्कि code के नीचे मौजूद software stack को संभालते हुए code लिखने की ज़रूरत को ही कम करना है
  • अगर किसी abstraction layer को बार-बार automate करने का मन हो, तो उसे automate करने के बजाय abstract करके हटाना ज़्यादा उचित दिशा है
  • प्रोग्रामिंग में LLM का व्यापक उपयोग यह दिखाता है कि लोग code writing process को automate करना चाहते हैं, और यह इस बात का संकेत है कि code writing की ज़रूरत को ही abstract किया जाना चाहिए
  • इंसानों को computer की तरह सोचने पर मजबूर करने के बजाय, ऐसी नई abstraction layer चाहिए जो इंसानों के स्वाभाविक सोचने के तरीक़े के ज़्यादा करीब हो

जहाँ document पहले आता है, ऐसी programming

  • समझ में आने वाले software की पहली सीढ़ी documentation है
    • अगर आप चाहते हैं कि दूसरे लोग software को समझें, तो आपको software को समझाना होगा
  • आम तरीका यह है कि पहले code लिखा जाता है और बाद में doc-comments या usage examples जोड़े जाते हैं
  • प्रस्तावित तरीका यह है कि क्रम को उलट दिया जाए: पहले document लिखे जाएँ, फिर code जोड़ा जाए
    • पहले इंसानों को समझाया जाए कि program क्या करता है, फिर computer को बताया जाए कि उसे क्या करना है
    • यह अवधारणा literate programming के नाम से जानी जाती है
  • इस तरीके में किसी और का code सीधे पढ़कर उसकी मंशा का अनुमान लगाने के बजाय, पहले document पढ़कर मंशा समझी जाती है और फिर code देखा जाता है
  • Entangled इस approach का एक अच्छा implementation है
    • यह एक bidirectional tangler है, जो documents से code निकालकर उन्हें उपयुक्त source code files में रखता है
    • document के भीतर के code blocks को edit किया जा सकता है, और सामान्य code files में किए गए edits भी document के code blocks तक वापस पहुँचते हैं
    • testing, refactoring, code formatting जैसे मौजूदा tools को किसी खास literate programming support के बिना भी पहले की तरह इस्तेमाल किया जा सकता है
    • tangler build system पर बहुत कम overhead जोड़ता है, और compiler की तुलना में तो यह और भी छोटा है
  • यह approach code की जटिलता को खुद समाप्त नहीं करती, लेकिन दूसरे लोगों के code को समझने के क्षेत्र में LLM की जगह ले सकती है

Code हटाना: GUI और कई अभिव्यक्तियाँ

  • code एक पुराने युग की अवधारणा है, और इसका उपयोग इसलिए होता आया क्योंकि computer के साथ interaction terminal के माध्यम से करना पड़ता था
  • जबकि computing पिछले 40 सालों में बदल चुकी है, यह मानने की ज़िद का कोई कारण नहीं कि computer से संवाद केवल अस्पष्ट symbols और keywords की 1-dimensional strings के ज़रिए ही होना चाहिए
  • GUI अक्सर text-based interfaces की तुलना में जटिल concepts को संभालना आसान बनाते हैं, और नए users के लिए ज़्यादा accessible होते हैं
  • IDE सिर्फ़ code को सुविधाजनक ढंग से edit करने की जगह से आगे बढ़कर, software development के साथ interaction का नया तरीका बन सकता है
    • कुछ IDE पहले से ऐसी सुविधाएँ देते हैं
    • इससे आगे visual programming इतनी सामान्य और सरल हो सकती है कि कोई भी बिना code सीखे अपनी मनचाही चीज़ बना सके
  • code को पूरी तरह छोड़ना ज़रूरी नहीं है
    • GUI representation, इंसानों द्वारा editable कई representations में से सिर्फ़ एक हो सकती है
    • जैसे कुछ लोग text-based operating system interfaces को पसंद करते हैं, वैसे ही कुछ लोग code-based software editing को पसंद करते रह सकते हैं
    • लेकिन code का default या एकमात्र विकल्प होना ज़रूरी नहीं है
  • visual programming को अधिक accessible बनाया जा सकता है, लेकिन visual-centered environments दृष्टिबाधित लोगों के बहिष्कार तक ले जा सकते हैं
    • मज़बूत screen reader integration की ज़रूरत है
    • ऐसे वैकल्पिक representations भी चाहिए जिन्हें auditory या tactile रूप से समृद्ध ढंग से समझा जा सके

Natural language को deterministic abstraction बनाना

  • यह कहने के विपरीत कि LLM abstraction layer को एक स्तर ऊपर उठाते हैं, LLM abstraction नहीं बल्कि automation layer के ज़्यादा करीब हैं
  • abstraction layer को predictable और reliable होना चाहिए, और high-level intent को lower level पर सटीक और consistent ढंग से व्यक्त करना चाहिए
  • LLM prompts की probabilistic व्याख्या करके intent का अनुमान लगाते हैं, इसलिए वे unpredictably व्यवहार करते हैं
    • वे काम के परिणाम का random approximation करने की प्रक्रिया को automate करते हैं
    • abstraction कहा जाए तो यह बहुत अधिक lossy abstraction के क़रीब है
  • natural language processing (NLP) में प्रगति natural language से machine language तक जाने वाली predictable pipeline बनाने की संभावना देती है
  • लक्ष्य यह है कि input LLM prompt जैसा हो, लेकिन हर बार program predictable और robust बने
    • दूसरों के काम को चुराए गए code के औसत की तरह distill करने के बजाय, उसे definitions के माध्यम से सीधे बनाया जाए
  • यह approach documents और code को और मज़बूती से जोड़ सकती है
    • literate programming में code वाले हिस्से को natural language से बदल दिया जाए, तो सिर्फ़ document बच सकता है
    • इंसानों को program के काम करने का तरीका समझाने वाला लेखन, एक साथ machine से संवाद करने वाला लेखन भी बन सकता है
  • यह natural language programming deterministic होनी चाहिए
    • NLP का उपयोग transformer models की generative क्षमता के बिना भी grammar से meaning parse करने में किया जा सकता है
    • parsed grammar को अन्य programming languages की तरह सीधे intermediate representation में बदला जा सकता है, जिसे platform requirements के अनुसार compile किया जाए
  • यह Inform जैसा है, लेकिन उससे अधिक उच्च-स्तरीय syntax recognition और व्यापक definition network से जुड़ी हुई रूपरेखा की कल्पना करता है
  • deterministic quality की वजह से prompts विश्वसनीय और consistent रूप से code बनते हैं; यही LLM से मूल रूप से अलग एक वास्तविक abstraction layer है

पिछले प्रयास: Eve और Inform

  • ये विचार नए नहीं हैं, और पहले भी इन्हें लागू करने की कोशिशें हुई हैं
  • Eve एक programming language और IDE था, जो प्रोग्रामिंग को इंसानों के लिए अधिक accessible बनाने की कोशिश करता था
    • यह literate programming approach का उपयोग करता था
    • यह domain-specific data-oriented programming language को software behavior समझाने वाले documents के भीतर embed करता था
    • code, document के अधीन होता है, और पूरा programming environment भी इसी को दर्शाता है
  • Eve ने इस विचार को और आगे बढ़ाकर अपनी language को NLP queries से बदलने की कोशिश भी की
    • वह natural language processing की जटिलता को संभालने के लिए तैयार नहीं था
    • 2016 में अधिक उन्नत NLP उन कंपनियों के लिए आसानी से उपलब्ध नहीं था जो machine learning-केंद्रित नहीं थीं
    • इसने GUI-oriented approach पर भी प्रयोग किया
  • Eve के पूर्व contributor ने भी project की complexity और LLM की सीमाओं को लेकर मिलती-जुलती चिंताएँ उठाई हैं
  • Eve इसलिए समाप्त हो गया क्योंकि वह VC funding वाला एक महत्वाकांक्षी project था जो monetization में असफल रहा, और उसके विचारों को परिणाम तक पहुँचते देखने का मौका नहीं मिला
  • Inform interactive fiction बनाने के लिए एक declarative language है, जो दिखाती है कि ये अवधारणाएँ अधिक व्यापक रूप से लागू हो सकती हैं
  • natural language मूल रूप से एक leaky abstraction हो सकती है, लेकिन औसत व्यक्ति को अपने computer पर सीधे नियंत्रण देने की इसकी क्षमता कहीं अधिक ध्यान पाने लायक है

अगला चरण और प्रस्तावित काम

  • समझ में आने वाला software बनाने के लिए ReTangled नामक project विकसित किया जा रहा है
    • यह Rust में लिखा गया, Entangled-compatible bidirectional tangler है
    • लक्ष्य है literate programming को जितना संभव हो उतना आगे बढ़ाना, और मौजूदा toolchain के साथ उचित स्तर पर गहरा integration करना
    • यह अभी शुरुआती development stage में है और contributions का स्वागत है
  • visual programming, literate programming, और natural language programming—तीनों पर और अधिक पूर्ण लेख लिखने की योजना है
  • community स्तर पर Eve के पदचिह्नों पर चलते हुए, थोड़ा अलग approach अपनाने का प्रस्ताव है
  • लक्ष्य यह है कि शुरुआती users से लेकर experts तक सबके लिए उपयोगी, अच्छी तरह documented और accessible visual या natural language programming environment बनाया जाए
  • शुरुआत का बिंदु software को बेहतर document करना है, और अंतिम लक्ष्य programming की अवधारणा को ही उलट देना है

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

1 टिप्पणियां

 
GN⁺ 4 시간 전
Lobste.rs टिप्पणियां

  • मुझे यकीन नहीं है कि कोड को छोड़ देना या उसे natural language prose के अधीन कर देना, programming की accessibility समस्या का प्रभावी समाधान है या नहीं
    Programming languages, computer और इंसान की ज़रूरतों के बीच संतुलन बनाने वाला user interface हैं। अच्छी तरह बनाया गया, स्पष्ट formal notation व्यक्ति की समझ और इंसान·मशीन के बीच विचारों के संचार में मदद करने वाला सोचने का औज़ार बन सकता है
    APL परिवार की languages सीखने से मुझ पर बड़ा असर पड़ा, और उन्हें सीखने में समय लगा, लेकिन एक बार सीख लेने के बाद मैं बड़े problems को दिमाग में रखकर ज़्यादा सटीकता से सोचने लगा। K के साथ जटिल IDE के बिना भी, दिमाग, कागज़ और एक साधारण REPL से problems हल किए जा सकते हैं
    अच्छी documentation वाले projects और literate programming मूल्यवान हैं, लेकिन documents को पढ़ने, लिखने और सुधारने में भी समय लगता है। tests की तरह, documentation ज़्यादा होना हमेशा अपने-आप में अच्छा नहीं है; मैं संक्षिप्त और structured explanations, और ऐसे छोटे programs पसंद करता हूं जिन्हें समझाना आसान हो। Code कविता हो सकता है, लेकिन ज़्यादातर कविताएं programs नहीं होतीं

    • मुझे formal programming पसंद है, लेकिन मैं नहीं मानता कि average user को computer की ताकत इस्तेमाल करने के लिए programmer बनना चाहिए
      ज़्यादातर लोग ऐसे internal workings नहीं सीखेंगे, इसलिए मैं entry barrier कम करना चाहता हूं ताकि ज़्यादा लोग भाग ले सकें
      इसलिए मुझे लगता है कि LLM लोकप्रिय हैं। मैं अक्सर non-programmers को अपना काम निपटाने के लिए LLM से code लिखवाते देखता हूं, लेकिन जैसा लेख में कहा गया है, LLM में बड़ी कमियां हैं जिनसे मैं बचना चाहता हूं। लोगों को natural language या सुविधाजनक user interface के जरिए games को modify करने, scripts बनाने और programs को extend करने में सक्षम होना चाहिए
      “code को खत्म कर दें” वाली अभिव्यक्ति शायद थोड़ी ज़्यादा रही हो, लेकिन बहुत से लोग code के बारे में सोचना नहीं चाहते, और उन्हें ऐसा करने की ज़रूरत भी नहीं होनी चाहिए

  • Programmers ने एक तरह से non-programmers को पीछे छोड़ दिया है
    Visual Basic मर चुका है, framework-less PHP भी सक्रिय नहीं दिखता, और Access भी व्यावहारिक रूप से मर चुका है। Notion या Airtable जैसे database-जैसे tools बचे हैं
    Programmers को code लिखना इतना पसंद है कि उनमें से कई लोग simple problems के simple solutions से दूर हो गए हैं
    Python ने एक समय non-programmer दुनिया में धूम मचाई, क्योंकि वह simple दिखता था और Pandas जैसे tools भी इस्तेमाल में आसान लगते थे। दिलचस्प बात यह है कि कई programmers Python या Pandas को खास अच्छा नहीं मानते। उदाहरण के लिए, standard library से आसानी से किए जा सकने वाले काम को Pandas से करने वाला code देखकर काफी झुंझलाहट होती है
    पहले non-programmers भी HTML pages बनाते थे और उनमें रंग और images डालते थे। आजकल किसी programmer से static website बनाने को कहें तो उसके साथ बेहिसाब complexity आ जाती है। कुछ complexity ज़रूरी होती है, लेकिन ज़्यादातर बिल्कुल गैरज़रूरी है। Programmers simple websites बनाने के लिए जो process इस्तेमाल करते हैं, अगर वही non-programmers को दे दी जाए, तो 20 साल पहले HTML edit करने का आनंद लेने वाले लोग भी चीखते हुए भाग जाएंगे
    यह गहरी विडंबना और चिंता की बात है कि आज कुछ चीज़ें उलटे कहीं ज़्यादा कठिन हो गई हैं

    • यह बात बिल्कुल समझ में नहीं आती। आज भी कोई भी HTML लिख सकता है, बल्कि यह पहले से आसान हो गया है
      CSS ज़्यादा powerful हो गया है, browsers कम टूटे-फूटे हैं, और हर चीज़ में मदद करने के लिए personal coding assistant भी है। Pure Python भी वैसा ही है—बस इस्तेमाल करिए। Programming पहले से कहीं आसान हो गई है
      modern technology stack की complexity के आम तौर पर कारण होते हैं, लेकिन उसे कारण बनने के बाद ही इस्तेमाल करना चाहिए, beginners को उसे इस्तेमाल करने की बिल्कुल ज़रूरत नहीं है
      अगर लोग HTML websites या basic programs नहीं बना रहे हैं, तो इसलिए कि वे करना नहीं चाहते। सोचा गया था कि भविष्य में हर कोई basic programming जानेगा, लेकिन असल में पता चला कि लोग बस करना नहीं चाहते। आप यह भी तर्क दे सकते हैं कि car या bicycle की basic maintenance सबको आनी चाहिए, लेकिन लोग मना कर देते हैं। इसका मतलब यह नहीं कि काम कठिन या असंभव है, बल्कि यह कि करने की इच्छा नहीं है
      मुझे लगता है कि आम जनता की computer literacy लगभग विकसित नहीं हुई है, और इसका programming की complexity से संबंध नहीं है। education में तो उलटे computer literacy पीछे जाती दिख रही है, लेकिन इसे complex frontend frameworks की वजह मानना मुश्किल है

  • लेख के बहुत से हिस्सों से मैं सहमत हूं। उदाहरण के लिए, मुझे literate programming पसंद है, लेकिन मुझे नहीं लगता कि programming खुद खराब है
    कुछ programming खराब होती है, और BigTech companies में होने वाली programming अक्सर कुल मिलाकर खराब होती है। लेकिन अपने लिए या अपने प्रिय लोगों के लिए programs लिखना आज भी आनंददायक है
    Entangled के बारे में नहीं जानता था, लेकिन यह अच्छा idea लगता है, और literate programming की सबसे बड़ी पीड़ा—LSP और मौजूदा tools द्वारा पहचान न होना—को address करता है। इसलिए अब तक मैं मुख्यतः NixOS configuration जैसी declarative languages में literate programming इस्तेमाल करता रहा हूं
    bidirectional literate programming हो तो non-declarative languages इस्तेमाल करते समय जीवन आसान हो सकता है। मैं ReTangled को एक बार आज़माने की सोच रहा हूं

    • Programming खराब नहीं है। उस वाक्य तक मैं लेखक से सहमत था, लेकिन “GUI को अपनाएं” आते ही मेरी रुचि कम हो गई
      GUI मुख्यतः इसलिए मौजूद लगते हैं कि executive level और उससे ऊपर के लोग यह मान सकें कि कर्मचारी वही काम कर रहे हैं जिसे वे खुद समझते हैं और कर सकते हैं
      मैंने visual drag-and-drop ETL tool की class ली थी, और मेरे पास बस यही विचार बचा कि पहले system जैसा कुछ फिर से बनाना कठिन होगा और पूरे को version control में रखना भी कठिन होगा। 2010 में उस समय मेरी company द्वारा इस्तेमाल किए जाने वाले visual drag-and-drop cron replacement system के साथ भी कुछ ऐसा ही था
      executives के लिए drag-and-drop आसान है, लेकिन practitioners के लिए errors ढूंढना, versions·backups बनाए रखना और reuse करना कठिन हो जाता है
    • अगर वही feature मुख्य उद्देश्य है, तो ReTangled में stitching काम करने तक Entangled इस्तेमाल करने की सलाह दूंगा
    • किसी ऐसी चीज़ को, जिसे पल-पल इस्तेमाल करना मज़ेदार हो, users को पसंद आने लायक स्तर तक उठाने की प्रक्रिया में सचमुच कठिन हिस्सा होता है
      मज़ेदार prototype को production में चलाने लायक बनाने के लिए error handling, serialization, deserialization, type projection वगैरह काफी लगते हैं। मेरा एक नियम है कि बेहतरीन user experience के साथ लगभग हमेशा गंदी internal structure जुड़ी होती है
      व्यक्तिगत रूप से मुझे इसका ज़्यादातर हिस्सा पसंद नहीं है, और पहले मैंने shortcuts लिए हैं या कभी-कभी वह काम किया ही नहीं है

  • काफ़ी हद तक सहमत। WYSIWYG editors को देखें तो उन्होंने web development को पूरी तरह replace नहीं किया, लेकिन उन लोगों की एक बड़ी niche ज़रूर कम कर दी जिन्हें सिर्फ़ basic website या simple product sales चाहिए थीं।
    software के अभी भी बड़े क्षेत्र हैं जिन्हें अच्छे GUI interface से और सरल बनाया जा सकता है।
    अगर अभी आप code को बस जोड़-तोड़ कर चिपका रहे हैं या LLM को अंधाधुंध चला रहे हैं, तो असल में GUI programming बेहतर हो सकती है। मैं अक्सर जो code इस्तेमाल करता हूँ वह भी कई बार REST server होता है, और ऐसी चीज़ों के लिए कुछ बनाने से रोकने वाली कोई वजह नहीं है।

  • हमारा लक्ष्य एक ही है, और मैं कई सालों से ऐसे tech stack के बारे में सोचता रहा हूँ जो वह सटीक समाधान दे सके जिसे मैं इस्तेमाल करना चाहता हूँ।
    मैंने Curv नाम का एक project public किया है, लेकिन वह मेरे दिमाग़ में मौजूद कहीं ज़्यादा सुंदर system का बस एक छोटा हिस्सा है।
    हज़ारों दूसरे लोग भी इस समस्या से जूझते रहे हैं। समस्या के आकार को देखते हुए team work ज़रूरी लगता है, लेकिन वास्तव में ज़्यादातर छोटे one-person projects ही हैं। जिन लोगों के पास सबसे मज़बूत vision होता है, वे अक्सर team goals के लिए अपने vision से compromise नहीं करना चाहते। इसे कैसे हल किया जाए, मुझे नहीं पता।
    प्रेरणा देने वाले projects में Alan Kay का Dynabook vision, उससे निकला Smalltalk, Alan Kay का बाद का project STEPS Toward the Reinvention of Programming, Bret Victor का काम, और ख़ासकर उनकी अद्भुत उपलब्धि Dynamicland शामिल हैं।
    इस विषय में रुचि रखने वाली community के रूप में Feeling of Computing है, जिसे पहले Future of Coding कहा जाता था। अगर जोड़ने लायक कुछ और हो तो बताइए।

  • “LLM prompt में डालने की तरह निर्देश input करके पूरा program बनाया जाए, लेकिन हर बार वह predictably और robustly काम करे” — यह विचार इस बहुत बड़े assumption पर टिका है कि natural language से deterministic और consistent semantics parse किए जा सकते हैं।
    लेकिन मुझे शुरू से ही नहीं लगता कि यह सच है। यह समस्या अलग है कि अब तक इसे ठीक से काम कराते हुए नहीं देखा गया; मुझे तो यह भी संदिग्ध लगता है कि यह संभव है या नहीं।
    भाषा में context बहुत ज़्यादा होता है। वही वाक्य बारह बार कहें, तो tone, audience, physical location, medium of speech और time of day के हिसाब से हर बार अर्थ में सूक्ष्म अंतर आ जाता है। Traditional natural language processing techniques इस flexibility को बुनियादी तौर पर handle नहीं कर पातीं।
    इसी वजह से LLM मौजूद हैं। शायद मौजूद ही न होने वाले कठोर context rules तय करने की कोशिश करने के बजाय, यह ऐसे model को train करने का तरीका है जो context detection को weights में encode कर सके। यह चौंकाने वाली हद तक प्रभावी साबित हुआ है।
    लोग LLM इस्तेमाल करते हैं, इसकी वजह भी यही है। क्योंकि अब तक बनाए गए किसी भी natural language interface से कहीं बेहतर तरीके से यह context को ध्यान में रखकर expected response बना सकता है। उस नज़रिए से यह सचमुच काम करता है। LLM के बाहर natural language processing ने उसी स्तर की सफलता नहीं दिखाई है।

  • अगर आप समृद्ध visual programming environment में रुचि रखते हैं, तो Glamorous Toolkit संभावित दिशा दिखाने वाला अच्छा उदाहरण है: https://gtoolkit.com/
    मैं इसे अभी finished form नहीं मानता, लेकिन यह पहले से बनी चीज़ों को और आगे ले जाने वाला tool है। LLM-generated code के दौर में image-based environments पर भी बात की जा सकती है।

    • मैंने Glamorous Toolkit की website देखी, लेकिन बिल्कुल समझ नहीं आया कि यह है क्या। क्या आप इसे कुछ वाक्यों में summarize कर सकते हैं?

  • जो चीज़ कम है, वह है आज programmers द्वारा आम तौर पर इस्तेमाल किए जाने वाले primitive elements — यानी functions और modules में व्यवस्थित code lines — से आगे की predictable abstractions।
    ख़ासकर जब जरूरतें simple data transformation नहीं बल्कि complex external systems को model करने की हों, तो केवल उन्हीं elements में उन्हें ढालने पर, human programmer के बनाने पर भी, वह लगातार बढ़ता हुआ mud ball बन जाता है। LLM भी उसी रूप की नकल कर रहे हैं।