Coding, Programming नहीं है

• Leslie Lamport LaTeX के शुरुआती डेवलपर्स में से एक हैं और distributed systems क्षेत्र के अग्रणी हैं. 2013 में Turing Award विजेता
• उन्होंने SCaLE 22x keynote में abstraction के महत्व पर ज़ोर देते हुए कहा कि ज़्यादातर programmers coding और language में उलझे रहते हैं, लेकिन coding से पहले abstract thinking और design ही असली कुंजी है

प्रस्तुति का सार

• आप उम्मीद कर सकते हैं कि मैं concurrency के बारे में बात करूँगा, लेकिन इस पर कहने के लिए मेरे पास कुछ नया नहीं है
• लेकिन "concurrent program लिखने" पर मिली समझ सामान्य रूप से पूरे programming पर भी लागू होती है
• यह प्रस्तुति कुल मिलाकर programming के बारे में है

algorithm vs. program

• algorithm: भाषा-स्वतंत्र abstract idea. Program की तुलना में ज़्यादा abstract और higher-level concept
• program: किसी algorithm को एक specific language में implement किया गया ठोस रूप. Programming language, algorithm को व्यक्त करने के लिए ज़रूरत से ज़्यादा जटिल होती है
• algorithm execute नहीं होता, और आमतौर पर छोटा और सरल होता है
• खासकर concurrency से जुड़े code में पहले सही algorithm को define करना और फिर उसे implement करना ज़रूरी है

array के maximum value के उदाहरण से abstraction

• साधारण समस्या में भी "क्या करना है(What)" को स्पष्ट रूप से define करना चाहिए
• उदाहरण: "integer array का maximum value लौटाना" → "ऐसी सबसे छोटी संख्या लौटाना जो सभी elements से बड़ी या बराबर हो"
• empty array को कैसे handle करना है, यह भी पहले से define करना चाहिए (जैसे -∞ का उपयोग)
• ऐसी स्पष्ट definition के ज़रिये ज़्यादा सरल और मज़बूत algorithm(How) निकाला जा सकता है

program execution, state का flow है

• program execution सिर्फ commands का क्रम नहीं, बल्कि state की निरंतर श्रृंखला है
• हर state transition code के किसी हिस्से के execution को दर्शाता है
• यह नज़रिया algorithm की correctness साबित करने में महत्वपूर्ण है (जैसे invariant का उपयोग)

जटिल systems के लिए tool: TLA+

• abstraction को सटीक रूप से व्यक्त करने के लिए एक precise language की ज़रूरत होती है
• TLA+ इसी उद्देश्य के लिए बनाया गया tool है
• Amazon Web Services ने TLA+ की मदद से गंभीर design flaws को पहले ही पकड़ लिया
• Rosetta spacecraft के OS Virtuoso को भी TLA+ के आधार पर design किया गया था, और उसका code संक्षिप्त व स्थिर था

अधूरी specification में भी abstraction की भूमिका

• उदाहरण: pretty printer में alignment का मानदंड subjective हो सकता है
• फिर भी abstract rules का एक set तय कर लेना debugging और maintenance के लिए महत्वपूर्ण है

writing और thinking का संबंध

• विचारों को लिखने से सोच स्पष्ट होती है
• abstraction सिर्फ दिमाग में करने की चीज़ नहीं, उसे लिखकर व्यक्त करना ज़्यादा असरदार होता है
• Lamport ने कहा कि उनकी mathematical training ने abstraction की क्षमता विकसित की
• mathematicians programmers को abstraction सिखा सकते हैं

libraries और bugs पर नज़रिया

• प्रस्तुति के दूसरे भाग "Programs में bugs क्यों होने चाहिए" में complexity की समस्या पर चर्चा हुई
• आधुनिक software कई libraries पर निर्भर करता है, लेकिन इनके लिए सटीक language-independent description की कमी होती है
• इसी वजह से integration के दौरान अनपेक्षित bugs पैदा होते हैं
• उदाहरण: अपनी TLA+ course site पर JavaScript debugging का अनुभव
• state-based नज़रिया इस तरह की complexity को समझने में उपयोगी है

Q&A में उठे विषय

• AI का abstraction पर प्रभाव
• open source और academia के बीच disconnect
• developers का formal definition की अनदेखी करना
• अब भी सबसे महत्वपूर्ण बात है "coding से पहले सोचना"

निष्कर्ष: programming का सार सोच है

• Lamport का तर्क है कि सिर्फ coding से ज़्यादा abstract thinking और formal specification को प्राथमिकता देनी चाहिए
• शुरुआत में मेहनत ज़्यादा लगती है, लेकिन अंततः इससे ज़्यादा मज़बूत और maintain करने में आसान software बनता है
• coding, programming का सिर्फ एक हिस्सा है, असली programming सटीक algorithm और abstraction से शुरू होती है
• systems की complexity और concurrency बढ़ने वाले इस दौर में abstraction एक अनिवार्य क्षमता है, और programmers को सोचने और abstraction करने का अभ्यास चाहिए

[softer]

मैं भी इस लेख से सहमत हूँ
मेरा भी मानना है कि अमूर्त किए गए state values के आधार पर समस्या को परिभाषित करना, समस्या खोजने में उपयोगी है, और मैं diagram आदि के जरिए state visualization या Unreal Blueprint या workflow की तरह visual और explicit state management tools बनाने की कोशिश कर रहा हूँ

लगता है पहले language को देखना होगा

[felizgeek]

यह लेख मुझे computation theory की मेजर क्लास की याद दिलाता है! जो लोग programming करते हैं, उन्हें इसे पढ़ने/समझने की सलाह दूंगा।

[aer0700]

मुझे जानना है कि TLA क्या है
मुझे इसे खोजकर देखना होगा

[xguru]

मैंने भी जिज्ञासा में इसे खोजकर देखा।
TLA+ - प्रोग्राम और समवर्ती/वितरित सिस्टम्स को मॉडल करने के लिए एक उन्नत भाषा

[GN⁺]

Hacker News राय

• demo scene के 'coders' खुद को इसी नाम से बुलाते हैं और इस पर गर्व महसूस करते हैं, और वे अक्सर बेहतरीन 'programmers' और 'software engineers' भी होते हैं। coder, programmer, software engineer—जो भी नाम इस्तेमाल करें, अहम बात यह है कि कंप्यूटर को वैसा काम कराया जाए जैसा आप चाहते हैं

• लगता है अगले साल की keynote होगी: 'vibing coding नहीं है, programming भी नहीं है...; कभी-कभी थोड़ा काम करने वाले कचरे का पिरामिड'। अच्छा है कि Dijkstra यह देखने के लिए मौजूद नहीं हैं। वे 80 के दशक में ही अपने माता-पिता के लिविंग रूम में नाराज़ हो चुके थे। 'vibe coding' देखकर उनकी क्या प्रतिक्रिया होती, इसकी कल्पना भी नहीं की जा सकती

• Leslie Lamport की SCaLE 22x keynote: पहले सोचो, abstract करो, फिर code करो। Lamport ने programming के लिए एक बुनियादी बदलाव की वकालत की, जिसमें coding से पहले सोच और abstraction पर ज़ोर दिया गया, और यह हर non-trivial code पर लागू होता है

  • abstraction पहले: code लिखने से पहले program का abstract view तय करें। यह high-level design logic को साफ़ करता है और errors को जल्दी पकड़ता है। फ़ोकस किसी खास language पर नहीं, बल्कि ideas पर होता है
  • algorithm != program: algorithm एक abstract concept है, जबकि program उसका concrete implementation है
  • execution as state: program execution को states की एक श्रृंखला के रूप में model किया जाता है, जहाँ हर state का future सिर्फ current state पर निर्भर करता है। यह खासकर concurrency में reasoning को आसान बनाता है
  • invariants का महत्व: invariants वे properties हैं जो execution की हर state में true रहती हैं। इन्हें समझना correctness के लिए ज़रूरी है
  • साफ़ specification का महत्व: कई library programs में clear specification की कमी होती है, जिससे उनका सही इस्तेमाल मुश्किल हो जाता है। खासकर concurrency में functions का स्पष्ट और language-independent description चाहिए
  • लिखना ही सोचना है: writing स्पष्टता के लिए मजबूर करती है और लापरवाह सोच को उजागर करती है। सोच writing को बेहतर बनाती है। यह एक positive cycle है
  • abstraction सीखना: abstraction गणित की core skill है, और programmers को यह क्षमता विकसित करनी चाहिए
  • AI के ज़रिए abstraction? यह सवाल उठता है कि क्या programming में abstract thinking process के लिए AI models का उपयोग किया जा सकता है

• programming एक इरादतन प्रक्रिया होनी चाहिए, जिसमें careful design (abstraction) के बाद implementation (coding) आता है, और फ़ोकस clear specifications तथा state sequences और invariants के ज़रिए program behavior को समझने पर होना चाहिए। सोचना हमेशा बेहतर है

• गणित के एक professor concept को अधिक सटीक और machine-readable रूप में बदलने वाली हर क्रिया को coding कहते हैं। इसमें सिर्फ programming language में यह लिखना शामिल नहीं है कि कंप्यूटर क्या करे, बल्कि data को encode करना भी शामिल है। "encode" शब्द इसे और स्पष्ट बनाता है। उन्होंने एक assignment दिया था जिसमें binary tree को natural numbers में बदलने वाली coding scheme परिभाषित करनी थी। coding शब्द इतना अस्पष्ट है कि वे इसका ज़्यादा इस्तेमाल नहीं करते

• Lamport कहते हैं कि "what" और "how" को अलग किया जाना चाहिए। लेकिन यह सवाल है कि ज़्यादातर समस्याओं में program का "what" और "how" कुछ हद तक आपस में घुल-मिल नहीं जाता? उदाहरण के लिए, performance considerations "what" का हिस्सा हैं या "how" का?

• दिलचस्प सार: algorithm program नहीं है, उसे programming language में नहीं लिखा जाना चाहिए, और वह simple होना चाहिए। दूसरी ओर, program को संभावित रूप से बड़े datasets पर तेज़ी से चलना होता है, इसलिए उसे complex होना पड़ता है। यह बात खासकर कई CPU पर चलने वाले concurrent programs के लिए कही गई, क्योंकि उनके execution orders अलग हो सकते हैं

• programming को उस code के रूप में परिभाषित किया गया है जिसके लिए coding से पहले सोच की ज़रूरत हो, और ऐसा code जिसे वे लोग इस्तेमाल करेंगे जो code पढ़ना नहीं चाहते। यह talk काफ़ी समय से दी जा रही है। सबसे छोटे item को खोजने को सरल बनाने वाला उदाहरण John Ousterhout की किताब के "Define Errors Out of Existence" से बिल्कुल मेल खाता है

• यह विडंबना मज़ेदार है कि comment section ज़्यादातर उन लोगों से भरा है जो संदेश समझ नहीं पाए। Leslie Lamport की मूल बात यह है कि abstract thinking की क्षमता विकसित करने से बेहतर programs बनते हैं। गणितीय और तार्किक अर्थ में abstraction आपको सभी अप्रासंगिक details हटाने देता है। AI-guided software development पर भी यही बात लागू होती है

• जैसा कि rigor से जुड़ी किसी भी चीज़ में अपेक्षित है, बहुत से लोगों ने सिर्फ title पढ़कर नकारात्मक प्रतिक्रिया दी। Hacker News का hacker एक skilled programmer हो सकता है जो समस्याएँ हल कर सकता है। अब इसका मतलब "You're a Hack" भी हो सकता है—यानी ऐसा व्यक्ति जो अक्षम हो और low-quality results बनाए

• यह talk और discussion ज़रूरत से ज़्यादा nitpicky है

• अभी ACM में एक अच्छा article है जिसमें कहा गया है कि abstraction क्या है, इस पर सहमति नहीं है, फिर भी यह बहुत उपयोगी है। broadly यह मान्यता है कि अहम बात कहाँ है, लेकिन यह क्या है और क्यों महत्वपूर्ण है, इस पर सहमति नहीं है। इससे बहुत प्रेरणा मिल सकती है, और यह अपने आप में मूल्यवान है

• hacking coding नहीं है, programming भी नहीं है, software development भी नहीं है, और software engineering भी नहीं है। लेकिन अंत में बहुत से लोग इन शब्दों का लगभग एक-दूसरे के बदले इस्तेमाल करते हैं, और व्यक्तिगत परिभाषाओं के फ़र्क पर ज़ोर देना शायद ही समय का उत्पादक उपयोग है