- प्रोग्रामिंग की कठिनाई के लिए औपचारिक प्रतीकों को दोष देने वाला नज़रिया यह गलत उम्मीद पैदा करता है कि अगर मशीन प्राकृतिक भाषा समझने लगे तो इंसानों का बोझ कम हो जाएगा
- शुरुआती machine language का खतरा high-level programming languages से कुछ हद तक कम हुआ, लेकिन गलत जवाब की जगह error message आ जाने भर से यह मूल बात नहीं बदली कि सटीक निर्देश अब भी ज़रूरी हैं
- natural language interface काम बाँटने का समाधान नहीं है; यह इंसान और मशीन के बीच सहयोग और संचार की लागत बढ़ाकर दोनों पक्षों का बोझ बढ़ा सकता है
- गणित का विकास दिखाता है कि Vieta, Descartes, Leibniz, Boole जैसे लोगों द्वारा बनाए गए औपचारिक प्रतीक तंत्र जटिल चिंतन को संभालने के लिए केंद्रीय औज़ार थे
- अगर natural language programming को मूल input/output बनाया गया होता, तो संभव है कि computer science अंततः उपयोगी formal systems तक वापस पहुँचने के लिए एक लंबा चक्कर भर बनकर रह जाती
प्राकृतिक भाषा प्रोग्रामिंग को लेकर अपेक्षाएँ और भ्रम
- automatic computation के शुरुआती दौर से ही कुछ लोगों ने यह माना कि प्रोग्रामिंग में औपचारिक प्रतीकों के लिए आवश्यक सावधानी और सटीकता खुद एक कमी है
- उन्हें यह समस्या लगती थी कि मशीन गलत निर्देशों का भी कठोरता से पालन करती है, और वे ऐसी अधिक “विवेकशील” मशीन की उम्मीद करते थे जो मामूली दफ्तरी गलतियों को ठुकरा दे
- machine language में redundancy लगभग न के बराबर थी, इसलिए वह इंसान और मशीन के बीच एक खतरनाक interface था
- इसी के जवाब में high-level programming languages विकसित की गईं
- समय के साथ यह सुधार हुआ कि कई छोटी-मोटी गलतियाँ गलत उत्तर देने के बजाय error message में बदलने लगीं
- लेकिन programming language के अनुरूप abstract machine अब भी वही स्वचालित मशीन है जो दिए गए निर्देशों को निष्ठापूर्वक पूरा करती है, और अर्थहीन निर्देश भी चला सकती है
- मशीन को natural language में निर्देश देने का प्रस्ताव इस तर्क पर टिका है कि मशीन को अधिक जटिल बनाकर भी इंसान का बोझ कम किया जा सकता है
- यह तर्क तभी कुछ हद तक विश्वसनीय लगता है जब औपचारिक प्रतीकों के उपयोग की बाध्यता को कठिनाई का कारण माना जाए
- interface में बदलाव केवल श्रम बाँटने का मामला नहीं है, बल्कि interface के आर-पार सहयोग और संचार की लागत भी जोड़ देता है
- अनुभव के आधार पर, interface में बदलाव दोनों पक्षों का काम काफी बढ़ा सकता है; इसी वजह से “संकीर्ण interface” की पसंद मज़बूत होती है
औपचारिक प्रतीक सोच का विस्तार कैसे करते हैं
- गणित के इतिहास में natural language या चित्र-केंद्रित तरीकों ने बार-बार अपनी सीमाएँ दिखाई हैं
- Greek गणित भाषिक और चित्रात्मक गतिविधि तक सीमित रहकर ठहर गया
- Moslem “algebra” ने प्रतीकों के प्रयोग की थोड़ी कोशिश के बाद फिर अलंकारिक शैली में लौटकर दम तोड़ दिया
- पश्चिमी यूरोप Vieta, Descartes, Leibniz, और बाद में Boole जैसे लोगों द्वारा बनाए गए सचेत रूप से डिज़ाइन किए गए औपचारिक प्रतीकों की बदौलत मध्ययुगीन scholasticism की भाषिक-सटीकता वाली कोशिशों से आगे बढ़ सका
- औपचारिक text का लाभ यह है that वैध हेरफेर के लिए बस कुछ सरल नियमों का पालन करना होता है
- यही नियमितता natural language में मुश्किल से बचाई जा सकने वाली अनेक प्रकार की निरर्थकता को बाहर रखने का साधन बनती है
- औपचारिक प्रतीकों का उपयोग बोझ नहीं, बल्कि लगभग एक विशेषाधिकार है
- इन्हीं के कारण वे काम भी छात्र सीख सकते हैं जो पहले केवल प्रतिभाशाली लोग कर पाते थे
- 1977 की एक technical report की प्रस्तावना में यह वाक्य कि “स्पष्टता के लिए हमने logical connectives के standard symbols तक से परहेज़ किया” दिखाता है कि यह भ्रम किसी एक व्यक्ति तक सीमित नहीं था
- natural language की “स्वाभाविकता” का मतलब यह भी है कि उसमें ऐसे वाक्य आसानी से बन जाते हैं जिनकी निरर्थकता तुरंत साफ़ नहीं होती
केवल प्राकृतिक भाषा की अनुमति वाले संसार में computer science
- अगर शुरुआत से ही information processing उपकरणों का input/output सिर्फ मातृभाषा में होता, तो computer science शायद पर्याप्त रूप से परिभाषित formal systems की ओर बढ़ने वाली लगभग “black art” बन जाती
- interface को उपयोगी स्तर तक संकीर्ण करने के लिए दुनिया भर की बुद्धि की ज़रूरत पड़ती
- मानव इतिहास को देखें तो इसमें फिर हज़ारों साल लग सकते थे
- इसके साथ यह चिंता भी जुड़ी है कि पश्चिमी शिक्षा का रुझान बौद्धिक प्रशिक्षण से दूर गया है, और लोगों की अपनी भाषा को संभालने की क्षमता बहुत घट गई है
- उदाहरण के तौर पर कहा गया है कि scientific papers, technical reports, government publications आदि में भी ध्यान से पढ़ने पर अर्थहीन बातें बहुत मिलती हैं
- इस प्रवृत्ति को “The New Illiteracy” कहा गया है, और यह natural language programming की विफलता का पूर्वानुमान लगाने वाली तकनीकी अंतर्दृष्टि न रखने वाले समर्थकों के लिए भी चेतावनी है
- अंत में यह संदेह जताया गया है कि natural language में प्रोग्राम होने वाली मशीन Dutch, English, American, French, German, Swahili — किसी भी भाषा में क्यों न हो — बनाना जितना कठिन होगा, उसका उपयोग करना भी उतना ही कठिन होगा
1 टिप्पणियां
Hacker News की राय
यहाँ LLM का बचाव करना ठीक है, लेकिन सोचता हूँ उल्टा करके देखें तो कैसा रहेगा। मध्यम जटिलता वाला कोई प्रोजेक्ट लें और अपने पसंदीदा LLM से code को फिर से natural language में बदलवाएँ
क्या वह source code में मौजूद behavior और requirements को, program को दोबारा बना सकने लायक details खोए बिना, reasonable तरीके से समझा पाएगा? क्या उस natural language description पर reasoning करना आसान होगा?
मुझे लगता है कि लोग जो vibe coding apps दिखाते हैं, वे आम तौर पर सरल होती हैं—इसकी वजह है। Complexity और precision को manage करना एक स्तर के बाद मुश्किल हो जाता है; plain English में define तो किया जा सकता है, लेकिन सवाल है कि क्या वह description scalable, understandable और precise language से ज़्यादा explanatory है
मुझे लगता है कि legal documents plain English में नहीं होते, इसकी वजह सिर्फ entry barrier बनाना नहीं है
METAR YSSY 031000Z 08005KT CAVOK 22/13 Q1012 RMK RF00.0/000.0जैसा हैनए pilots लगभग हमेशा पूछते हैं, “इसे शब्दों में क्यों नहीं लिखते?”, और सच में ज्यादातर flight planning apps इस code को prose में बदल देती हैं
लेकिन professional pilots या controllers code format को कहीं ज़्यादा पसंद करते हैं। एक line होने से यह compressed है, format well-defined है इसलिए ज़रूरी item कहाँ मिलेगा यह ठीक-ठीक पता होता है, और यह ambiguous नहीं बल्कि साफ़ होता है
Maths और coding भी इसी तरह हैं: एक स्तर से ऊपर की proficiency हासिल होने पर natural language की complexity और redundancy का cost, benefit से ज़्यादा हो जाता है। लगता है यह हर professional field पर लागू होता है
Prose में information वापस ढूँढना समय लेता है, और लंबे text पढ़ने वाले लोग underline करने, notes बनाने और अपने abbreviations बनाने लगते हैं
Compressed formats और abstractions working memory और information search का बोझ घटाते हैं। इसलिए यह सिर्फ language की precision की समस्या नहीं भी हो सकती
आप सोचेंगे कि उस sentence से actual working app तक जाने के लिए ढेरों implementation details चाहिए, लेकिन इतनी information से भी मेरी जरूरत हल करने वाली working application तक पहुँचने की संभावना है
और अगर उससे इतना बन सकता है, तो “क्या इसे cornflower blue में बदल सकते हो?” जैसी request भी आसान हो जाती है और user वहीं से iterative improvements कर सकता है
अगर LLM को सिर्फ ISA और display driver देकर assembly में graphics app बनाने को कहें, तो कुछ नहीं मिलेगा
लेकिन अगर abstractions का पहाड़ लगा हो, तो शायद संभव हो जाता है
मैं LLM का बचाव नहीं कर रहा; मेरा कहना है कि सही abstractions और reusable components दिए जाएँ तो हम बहुत करीब जा सकते हैं
Hal Abelson का एक पुराना quote याद आता है
“इस विषय पर हमारे approach के नीचे यह conviction है कि ‘computer science’ science नहीं है और इसकी importance का computers से बहुत कम संबंध है। Computer revolution दरअसल हमारे सोचने के तरीके और अपने विचार व्यक्त करने के तरीके की revolution है। इस बदलाव का सार ऐसी चीज़ का उभरना है जिसे procedural epistemology कहना शायद सबसे उचित होगा। यह classical mathematics fields द्वारा अपनाए गए अधिक declarative view के विपरीत, imperative view से knowledge की structure का अध्ययन है। Mathematics ‘क्या है’ की अवधारणा को precise तरीके से संभालने का framework देती है। Computation ‘कैसे करना है’ की अवधारणा को precise तरीके से संभालने का framework देती है।”
चाहे कितने भी शानदार demos और “AI की वजह से coding मर गई” वाले proclamations हों, असल काम का ज्यादातर हिस्सा AI के इर्द-गिर्द preprocessing, postprocessing और evaluation में shift हो जाता है
Programming को अधिक accessible बनाने के लिहाज से यह अच्छा है, लेकिन programming को सच में replace नहीं कर सकता
आखिरकार किसी ने इसे इस तरह कहा। Natural language की अपनी inherent limits हैं, जो इंसान की mental limitations से आती हैं। मानव mind कभी बहुत abstract या बहुत concrete सोचता है, और महत्वपूर्ण details या generalizations छोड़ देता है
Programmer के तौर पर मेरा direct experience है कि किसी task की problem या कभी-कभी absurdity भी अक्सर code को code के रूप में, यानी एक strict symbol system में implement करना शुरू करने के बाद ही सामने आती है
ऊपर से, किसी चीज़ को natural language में accurately describe करने में लगने वाला समय कई बार बस algorithm को code में लिखने के समय से भी ज्यादा होता है
हम कितनी बार sentences rewrite करते हैं, या कहते हैं “असल में मैं कहना यह चाहता था…”, या भेजने से पहले email को फिर से phrase करते हैं? हम इंसान हैं और पहली कोशिश में perfect होना दुर्लभ है
अब हम communication के इसी imperfect format, natural language, को code में convert कर रहे हैं—उस machine की language में जो intended तरीके से नहीं बल्कि कही गई बात को literally करने के लिए बदनाम है
Natural language processing apps या scripts लिखने की शुरुआत सही दिशा में कराने के लिए बेहद useful है। लेकिन आखिर में इधर-उधर refactoring की जरूरत पड़ सकती है
LLM से value पाने के लिए code का उस्ताद होना जरूरी नहीं, फिर भी coding ability अब भी मददगार है और कभी-कभी जरूरी भी
/s: क्योंकि अभी हम पर्याप्त दूर तक नहीं गए हैं। लोग natural language में computer programs बनाते हैं, लेकिन इसके बजाय prompt को सीधे execute करना चाहिए
“तुम एक graphics system हो। तुम वह इकाई हो जो screen पर क्या है, इसका प्रबंधन करती है। तुम सभी programs से ‘window’ बनाने और हटाने के requests ले सकती हो, और पहले बनाई गई window में text, lines, circles वगैरह draw करने के अतिरिक्त requests भी ले सकती हो। items किसी भी color के हो सकते हैं।
साथ ही, user ने जिस window पर mouse click किया है, उसे बनाने वाले पक्ष को तुम्हें और click information भेजनी होगी।
window manager एक विशेष program है, और वह system से जुड़े सभी monitors पर कौन-सी window कहाँ दिखाई दे रही है, यह तुम्हें बता सकता है”
और “तुम एक tic-tac-toe program हो। एक graphics system है जो screen पर क्या है, इसका प्रबंधन करता है। तुम उस system को ‘window’ बनाने और हटाने का आदेश दे सकते हो, और पहले बनाई गई window में text, lines, circles वगैरह draw करने को कह सकते हो। items किसी भी color के हो सकते हैं।
तुम्हारे द्वारा बनाए गए graphics को ऐसा tic-tac-toe game दिखाना चाहिए जिसमें user mouse click करके अपनी चाल चलता है। अगर user जीत जाए तो…
जब तक user ने per-click billing subscription नहीं लिया है, game में ads जोड़ो”
इतना game चलाने के लिए पर्याप्त होना चाहिए
save करने के लिए एक और prompt चाहिए। “तुम एक file system हो। तुम disk पर data को persistent बनाते हो…”
और “तुम एक multitasking operating system हो। तुम कई LLMs को यह एहसास देते हो कि उनके पास system के CPU और memory का पूरा control है। तुम…” भी चाहिए
उम्मीद है अगले साल अप्रैल की शुरुआत में यह देखने को मिलेगा
“machine language में लगभग हर तरह की redundancy नहीं होती, इसलिए उसे जल्द ही इंसान और मशीन के बीच एक अनावश्यक रूप से खतरनाक interface के रूप में पहचाना गया। इस समझ के आंशिक जवाब में तथाकथित ‘high-level programming languages’ विकसित की गईं, और समय के साथ हमने मूर्खतापूर्ण गलतियों से सुरक्षा को कुछ हद तक मजबूत करना सीख लिया। यह एक महत्वपूर्ण सुधार था कि अब कई मूर्खतापूर्ण गलतियाँ गलत जवाब के बजाय error messages तक ले जाती हैं।”
लगता है हम सामूहिक रूप से LLM programming में बहुत जल्दी कूद पड़े। मुझे यह सच में अच्छा लगा कि Rust किस तरह मूर्खतापूर्ण गलतियों को पकड़ने और उन्हें ठीक करने का तरीका कहीं अधिक स्पष्ट बनाने की दिशा में विकसित हुआ है
एक developer के रूप में, मैं जिस code पर काम कर रहा हूँ उसका context और समझ अभी भी मेरे पास रहती है, और compiler साफ़ errors और fixes बता देता है। इसके उलट LLM का उपयोग आधा-बुद्धिमान guessing game जैसा लगता है
Rust compiler किसी शिष्य को सिखाने वाले गुरु जैसा है, और LLM गुरु को सुधारने वाला आत्मविश्वासी graduate जैसा। मुझे Rust वाला तरीका कहीं ज्यादा पसंद है और यदि संभव हो तो यह और आगे बढ़े
natural language rules और commands पहुँचाने का कमजोर माध्यम है। अमेरिका की मौजूदा स्थिति इसका अच्छा उदाहरण है
हम आज भी इस पर बहस कर रहे हैं कि कौन-से laws और constitutional amendments का क्या मतलब है। शब्दों के अर्थ समय के साथ बदलते हैं, और historical context भी कम होता जाता है
मशीनों को natural language से operate कर पाना अच्छा होगा, लेकिन 80s के मध्य से programming करते आ रहे व्यक्ति के रूप में मुझे लगता है कि BASIC से Go तक चली आ रही computer languages की कठोरता एक अच्छा balance बनाती है। यह command देने वाले पर इतनी जिम्मेदारी डालती है कि वह ठीक-ठीक बताए कि मशीन को क्या करना चाहिए
मैं इस दावे से कुछ हद तक असहमत हूँ। असली कंपनियों में नई feature ideas अक्सर किसी business person के दिमाग में शुरू होती हैं। यह व्यक्ति कोई formal language नहीं बोलेगा
इसलिए, किसी भी तरह देखें, feature implementation के लिए natural language से machine language में translation जरूरी है
आम तौर पर पहला step, यानी natural language से formal language में translation, business analysts और programmers करते हैं। तो उस प्रक्रिया में computer की मदद लेने की कोशिश न करने की क्या वजह है?
इसलिए वह न सिर्फ इस विचार का खंडन कर रहा है कि programs को natural language में specify करना चाहिए, बल्कि इस विचार का भी कि अगर हम formal languages समझने की जरूरत हटा दें तो complex systems बनाने की हमारी क्षमता बढ़ जाएगी
बहुत-सा “translation” असल में translation नहीं, बल्कि logical ambiguity, inconsistency, और गलत assumptions को ठीक करना होता है। Dijkstra को गंभीरता से लें तो इनमें से काफी कुछ natural language के भीतर भी संभव है, क्योंकि वहाँ जीवन भर formalization करते आए programmers मौजूद होते हैं
mathematics जैसी अन्य professions भी हैं जिनमें काफी formal thinking चाहिए। साथ ही पुराने proofs को computer proofs में बदलते समय, व्यापक रूप से स्वीकार किए गए कई proofs में holes और gaps भी मिले हैं
उलटी साबित हुई चीजें बहुत ज्यादा नहीं हैं, लेकिन Fermat's Last Theorem का पूरा proof अभी भी हमारे पास नहीं है https://xenaproject.wordpress.com/2024/12/11/fermats-last-th...
अगर आप formal system के भीतर नहीं सोचते, तो ideas खराब हो जाते हैं। क्योंकि आप अपने विचारों को formal चीज़ के रूप में treat नहीं करते
उदाहरण वाले “business person” के idea को कैसे translate किया जाए, इस पर शायद उनकी खास राय नहीं होगी। उनके नजरिए से business person का idea पहले से ही formalism का पालन नहीं करता, इसलिए वह सतही और खराब है, और translate करने लायक नहीं है
“computer को बीच में मदद करने” देने पर आप जल्द ही इस समस्या से टकराएँगे कि machine से sufficiently good result पाने के लिए और भी अधिक formal natural language की जरूरत पड़ने लगती है
programming language जितनी formalized न हो, फिर भी वह निश्चित रूप से मौजूद होती है
किसी भी process को define करने की कोशिश करें, तो भले ही आप conscious न हों, आखिरकार formalization की तरफ झुक ही जाते हैं
“यह एक अहम सुधार था कि कई मूर्खतापूर्ण गलतियाँ गलत जवाबों के बजाय error messages तक पहुँचाती थीं। यह सुधार भी सबको पसंद नहीं आया। कुछ लोगों को ऐसे error messages, जिन्हें ignore नहीं किया जा सकता, गलत नतीजों से ज़्यादा चिढ़ाने वाले लगे, और programming languages की तुलनात्मक खूबियों को आँकते समय वे आज भी ‘programming की आसानी’ को ऐसी अनदेखी गलतियाँ आसानी से कर बैठने के बराबर मानते दिखते हैं।”
अगर पता न होता कि यह किसने लिखा है, तो यह Rust से नफरत करने वालों पर सीधा वार लगता
Rust से ज़्यादा type के ज़रिए मजबूत invariants व्यक्त कर सकने वाली भाषा Scala को कुछ समय इस्तेमाल करने के बाद, मैं इस गुण को हर स्थिति में साफ़ जीत नहीं मानता। अब मैं “मजबूत type == हमेशा बेहतर” नहीं सोचता
“गलतियों की इजाज़त न देना” की कीमत होती है। Type system सचमुच सख्त हो तो exploratory काम काफ़ी मुश्किल हो जाता है। तेज़ iteration असंभव भी हो सकता है
किसी छोटे बदलाव के कारण type system को फिर से satisfy कराने के लिए program का आधा हिस्सा redesign करना पड़ सकता है
यह एक trade-off है। बाकी हर चीज़ की तरह। मजबूत final product के लिए अच्छा है, लेकिन तेज़ experiments में बाधा बनता है
किसी ने Rust और game development के संदर्भ में इस समस्या को अच्छी तरह समझाया है: https://loglog.games/blog/leaving-rust-gamedev/
लेकिन यह समस्या सिर्फ Rust या game development तक सीमित नहीं है
कुछ तरह की मूर्खता शायद समय से परे होती है
यहाँ वे interpreter languages की बात कर रहे हैं
वे उन गणितज्ञों में से भी एक हैं जिन्हें आज computer scientist कहा जाता है; उनके “algorithms” असल में गणित को बस फिर से कहने जैसे हैं और उन्हें device की ज़रूरत नहीं होती। वे असली computer को program करने की शर्मनाक गतिविधि के प्रति स्वभाव से विरोधी व्यक्ति हैं
Natural language में applications को specify और बनाना, game prototype शुरू करने से पहले game design document रखने जैसा काफ़ी है
लेकिन जब आप चाही हुई चीज़ों का ज़्यादातर हिस्सा implement कर लेते हैं, तो implementation ही reference बन जाता है, और GDD असली game से अलग हो जाता है, इसलिए आम तौर पर उसे छोड़ दिया जाता है
हर बदलाव पर GDD पढ़कर feature implement करना और फिर GDD को फिर से sync करना—इस पर अड़े रहना झंझट भरा है और व्यवहार में ठीक से काम नहीं करता। मैंने ऐसा होते कभी नहीं देखा
अगर किसी दिन AI/LLM सिर्फ prompts की एक series से Linux या Windows का अगला version शुरू से code कर सके, तो सारी मान्यताएँ बदल जाएँगी, लेकिन अभी हम साफ़ तौर पर वहाँ तक नहीं पहुँचे हैं और आगे पहुँचेंगे भी या नहीं, पता नहीं
Natural language जटिल systems की technical requirements समझाने के लिए काफ़ी अच्छी है। यानी मौजूदा code implementation खुद नहीं, बल्कि यह समझाने के लिए कि दूसरी संभावित implementations के बजाय मौजूदा implementation क्यों चुनी गई
Code क्या करता है नहीं, बल्कि उसे क्या करना चाहिए—दूसरे शब्दों में repository में नहीं, Jira जैसी जगहों में मौजूद missing parts को दर्ज करने के लिए उपयुक्त है
साथ ही, अगर पूरा system external rules से वर्णित हो और उन rules को पूरे codebase पर enforce किया जा सके, तो यह बेहतर refactoring क्षमता भी दे सकता है
हम programming languages इसलिए इस्तेमाल करते आए हैं क्योंकि वे automation और computer के संदर्भ में लिखने में आसान हैं, और सच कहें तो LLM से पहले यही एकमात्र तरीका भी था
Programming languages स्थानीय स्तर पर ambiguity हटाती हैं, लेकिन जैसे ही कोई code का कोई हिस्सा copy-paste करता है, global स्तर पर यह काम करना बंद कर देता है
क्या आप पक्का कह सकते हैं कि वह हिस्सा उन सभी high-level constraints का पालन करते हुए सही program है जिनका उसे पालन करना चाहिए? Compile हो जाए तो वह चलने वाला program तो होगा, लेकिन चलने की परिभाषा काफ़ी ढीली है। C++ में सारी memory बिगाड़ देने वाला program भी चल सकता है