प्रोग्रामिंग भाषाओं के बारे में मेरी सोच बदल देने वाले लेख

• प्रोग्रामिंग भाषाओं और compiler के बारे में नज़रिया बुनियादी रूप से बदल देने वाले कई लेख, शोधपत्र और वीडियो का परिचय
• व्यावहारिक GC implementation, optimizer design, register allocation, regular expression engine आदि की समझ को काफ़ी विस्तार देने वाले संसाधन
• Z3, abstract domain, SSA form, E-Graphs जैसे व्यावहारिक algorithms और structures को वास्तविक code examples के साथ आसानी से समझाया गया है
• हर संसाधन जटिल concepts को संक्षिप्त, फिर भी expandable और समझने में आसान रूप में खोलता है

---

प्रोग्रामिंग भाषाओं और compiler के बारे में सोच में बदलाव लाने वाले लेखों का परिचय

• कभी-कभी मुझे प्रोग्रामिंग भाषाओं और compiler से जुड़े विषयों पर ऐसे शोधपत्र, blog posts और वीडियो मिलते हैं जो मेरी सोच पूरी तरह बदल देते हैं
• कुछ लेखों का असर इतना तीव्र रहा कि उन्हें पढ़ने से पहले मैं क्या सोचता था, यह भी याद नहीं रहता
• नीचे ऐसे ही संसाधनों का परिचय है (क्रम महत्वहीन है)

GC, optimizer, abstract domain, register allocation से जुड़े लेख

• Andy Wingo का a simple semi-space collector Cheney/copying/compacting garbage collector की अवधारणा को सिद्धांत से वास्तविक उपयोग तक बहुत अच्छे ढंग से दिखाता है
  • लेख में GC का मुख्य implementation बहुत संक्षिप्त है, विस्तार योग्य है, और आधे दिन में समझा जा सकता है
• CF Bolz-Tereick का Implementing a Toy Optimizer optimizer में instruction rewrite तरीके के बारे में सोच बदल देता है
  • साधारण find-replace की जगह forwarding pointer के इस्तेमाल पर ज़ोर देता है और union-find की अवधारणा से परिचय कराता है
  • पूरी toy optimizer series के हर लेख में कुछ नया और दिलचस्प है
• A Knownbits Abstract Domain for the Toy Optimizer, Correctly लेख एक नए abstract domain और Z3 के उपयोग को साथ-साथ परिचित कराता है
  • यह केवल यह नहीं दिखाता कि Z3 का उपयोग कई numeric operation proofs में कैसे होता है, बल्कि Python code verification engine के रूप में इसके इस्तेमाल के उदाहरण भी देता है
  • यह उस विचार को प्रस्तुत करता है कि अगर Z3 counterexample नहीं ढूँढ़ पाता, तो code की correctness guarantee मानी जा सकती है
• Chris Fallin का Cranelift, Part 3: Correctness in Register Allocation हर input के लिए सही register allocation को सीधे प्रमाणित करने का तरीका समझाता है
  • production environment में या तो सही allocation मिलता है या अर्थपूर्ण crash
  • यह fuzzing technique के ज़रिए state space को explore कर bugs ढूँढ़ने का तरीका भी प्रस्तुत करता है

parsing, interpreter, JIT, abstract structure

• Russ Cox का Regular Expression Matching: the Virtual Machine Approach regular expression engine implementation को लगभग 50 lines के आसानी से पढ़े जा सकने वाले code में दिखाता है
  • इस प्रक्रिया में coroutine, fiber, scheduler आदि के सिद्धांत भी सरल तरीके से समझाए गए हैं
• Andrej Karpathy का micrograd बिना बाहरी libraries के neural network चलाने का बेहद छोटा implementation उदाहरण है, जो machine learning की बुनियादी संरचना और सिद्धांत समझने में मदद करता है
• Fil Pizlo का How I implement SSA form union-find structure को बेहतर बनाने का एक नया तरीका पेश करता है
  • SSA transformation में अतिरिक्त pointers को object के अंदर Identity tag के रूप में manage किया जाता है
  • इसके अलावा Phi/Upsilon form, TBAA-style heap effects जैसी और भी सोचने लायक बातें देता है
• Fil Pizlo का Speculation in JavaScriptCore JavaScriptCore के कई तरह के optimizer implementation approaches को विस्तार से कवर करता है
  • इस लेख को हर बार दोबारा पढ़ने पर नई insight मिलती है

compiler design, parser, IR structure, E-Graphs

• Chandler Carruth की Modernizing Compiler Design for Carbon Toolchain प्रस्तुति (लगभग 29 मिनट पर) बेहद तेज़ compile-time goals तय करने और पूरे architecture design की प्रक्रिया समझाती है
  • लगभग 40 मिनट से यह हर layer की संरचना को खोलकर समझाना शुरू करती है
• Allison Kaptur का A Python Interpreter Written in Python CPython के अंदर bytecode interpreter के काम करने के सिद्धांत को आसानी से समझा देता है
• Eli Bendersky का Parsing expressions by precedence climbing पारंपरिक recursive descent parser की तुलना में अधिक आसान और कम implementation burden वाला Precedence Climbing parsing method पेश करता है
• Takashi Kokubun का Ruby JIT Challenge code generation और नए register allocation method (stack folding at compile-time) को दिखाता है
• Abdulaziz Ghuloum का [An Incremental Approach to Compiler Construction (PDF)(https://bernsteinbear.com/assets/img/11-ghuloum.pdf) मौजूदा multi-stage compiler design को एक साथ समझने में मदद करने वाला single-pass implementation approach समझाता है
  • यह हर feature को end-to-end धीरे-धीरे जोड़ने का तरीका अपनाता है
• Fernando Borretti का Lessons from Writing a Compiler compiler implementation strategy को स्पष्ट भाषा में समझाता है
• egg: Fast and extensible equality saturation शोधपत्र optimizer और pass ordering के बारे में सोच को बुनियादी रूप से बदल देता है
  • यह ऐसा सोचने का तरीका देता है जिसमें expression के सभी संभावित versions को compressed hypergraph की तरह बनाया जाता है और फिर सबसे अच्छा version चुना जाता है
• Chris Fallin का Cranelift: Using E-Graphs for Verified, Cooperating Middle-End Optimizations यह सिद्ध करता है कि वास्तविक commercial compilers में भी e-graphs प्रभावी रूप से काम करते हैं
• Phil Zucker का Acyclic Egraphs and Smart Constructors acyclic e-graph structure और smart constructors के उपयोग की पड़ताल करता है
  • शुरुआत में इसे समझना मुश्किल था, लेकिन समय के साथ इसकी समझ गहरी होती गई

AST storage, large-scale parallel dynamic analysis आदि

• Bob Nystrom की यह Reddit comment और Adrian Sampson का Flattening ASTs
  • AST को लगभग bytecode जितना compact रूप में store करने के तरीकों पर बात करते हैं, और
  • यह बड़ी चर्चा की ओर ले जाते हैं कि अगर IR nodes को इस तरह store किया जाए, तो large-scale parallel lock-free analysis भी संभव हो सकता है
  • Cliff Click की buffer allocation speed पर की गई टिप्पणी ने भी इस तरह की सोच को प्रभावित किया

[GN⁺]

Hacker News राय

• मुझे यह पोस्ट बहुत पसंद आई। हाल में मैंने कंप्यूटर साइंस रिसर्च काफी पढ़ी है, लेकिन इसमें जिन चीज़ों का ज़िक्र है उनमें से कुछ से मैं अब तक परिचित नहीं था। मैं कुछ ऐसे पेपर बताना चाहूँगा जो मुझे पसंद हैं लेकिन यहाँ नहीं हैं: Ian Piumarta का “Open, Extensible Object Models” प्रोग्रामर को अधिकतम स्वतंत्रता देने वाली न्यूनतम object-oriented metaobject system पर है; मूल रूप से यह सिर्फ message sending operation को परिभाषित करता है और बाकी सब कुछ runtime पर बदला जा सकता है। यह “Art of the Metaobject Protocol” के एक practical version जैसा लगता है। John Ousterhout का “Scripting: Higher-Level Programming for the 21st Century” system programming languages और scripting languages के द्विभाजन पर बात करता है। हम हमेशा ऐसी perfect multi-paradigm language चाहते हैं जो हर चीज़ को तेज़ और productively कर सके, लेकिन कई बार compiled, fast, complex system language का convenient और flexible interpreted frontend के साथ संयोजन बेहतर होता है। सच कहूँ तो कई बार सिर्फ C और Tcl को साथ इस्तेमाल करना ही काफ़ी होता है। programming languages बनाने वालों के लिए यह अनिवार्य रूप से पढ़ने लायक लेख है। Niklaus Wirth का Project Oberon एक पूरे computer system के implementation का उदाहरण है, जिसमें high-level UI से लेकर kernel, compiler, और RISC जैसी CPU architecture तक सब शामिल है। उन्होंने “lean software” के लिए एक शक्तिशाली अपील की और उसे वास्तव में करके भी दिखाया। आज के dependency hell और excessive abstraction के दौर में यह खो चुकी कारीगरी जैसा लगता है

  • मैं Ousterhout के इस dichotomy और उसके निष्कर्ष से सहमत नहीं हूँ। उनका मूल तर्क यह है कि भाषा या तो system language (C) होती है या script language (Tcl, Python)। system language strongly typed होती है और data structures/algorithms के लिए होती है, जबकि script language untyped होती है और 'glue' के लिए। वह कहते हैं कि scripting languages अपने 'typed न होने' की वजह से ज़्यादा concise होती हैं और तेज़ development संभव बनाती हैं, लेकिन मुझे नहीं लगता कि यह यथार्थवादी व्याख्या है। उदाहरण के तौर पर वह Tcl code और C++/MFC code की तुलना करके कहते हैं कि Tcl बेहतर है, जबकि असल में उनका मतलब सिर्फ यह है कि उसका syntax बेहतर है। यह दावा कि untyped language तेज़ बनाती है, सही नहीं है। फ़र्क सिर्फ इतना है कि आप limitations से कब टकराते हैं। type errors को execution से पहले जाँचना बेहतर है, और हर language में static type analysis संभव है, बस वह complex और कठिन होता है। PL (programming language) designer के रूप में केवल runtime पर type check करना भाषा को आसानी से बनाने के लिए एक वैध निर्णय हो सकता है, लेकिन इसका मतलब यह नहीं कि वह बेहतर विकल्प है

• मुझे यह पोस्ट बहुत पसंद आई। programming languages पर लिखे गए लेखों ने मेरे programming को देखने के तरीके को बदल दिया। मुझे अक्सर TAPL(Types and Programming Languages) का “safety” पर दिया गया उद्धरण याद आता है। safe language वह है जो programmer को खुद अपने पैर पर कुल्हाड़ी मारने से रोके और उसकी abstractions की रक्षा करे। यानी भाषा द्वारा दी गई abstractions और programmer द्वारा बनाई गई higher-level abstractions, दोनों की integrity की गारंटी देने की क्षमता महत्वपूर्ण है। उदाहरण के लिए, अगर array एक abstraction है, तो उसे सिर्फ explicit update पर ही बदला जा सके, और गलती से किसी दूसरी data structure को छू न सके

• दिलचस्प development habits की बात करें तो… APL के लिए मशहूर Aaron Hsu अपने विचार व्यवस्थित करने के लिए fountain pen से calligraphy शैली में code लिखते हैं। मैं भी कुछ वैसा ही करता हूँ: सस्ते ballpoint pen से Python objects के flowchart जैसे चित्र बनाकर अपने विचार साफ़ करता हूँ। एक तरह का सस्ता UML

  • सबसे कठिन समस्याओं पर काम करते समय मैं भी fountain pen ढूँढने लगता हूँ। fountain pen का इस्तेमाल करते ही लगता है जैसे मैं एक अलग सोच की जगह में प्रवेश कर गया हूँ। editing की सीमाएँ अधिक सुसंगत और रैखिक सोच को बढ़ावा देती हैं, लेकिन साथ ही English, code, math, diagrams आदि के बीच स्वतंत्र रूप से आने-जाने की सुविधा रचनात्मकता खोल देती है

  • handwriting और memory improvement के बीच संबंध वास्तव में सिद्ध हुआ है। कंप्यूटर पर लिखना मानो सिर्फ हैंडल पर उँगलियों के निशान छोड़ने जैसा है। काश OCR तकनीक इतनी अच्छी हो जाए कि केवल handwriting से रिकॉर्ड रखना भी पूरी तरह storage और search के लिए पर्याप्त हो

• मैं ज़रूर Rich Hickey के talks, खासकर शुरुआती talks, देखने की सिफ़ारिश करूँगा। मैंने भी ऐसे talks देखकर programming को देखने का अपना नज़रिया पूरी तरह बदल लिया था

  • मेरे लिए Larry Wall की “Programming Perl” के साथ Rich Hickey के talks सबसे प्रभावशाली रहे हैं

  • “Simple made easy” talk पर मज़ाक में यह कहने का मन करता है कि पिछले 10 सालों में हर conference speaker ने इसे quote-quote करके इतना दोहरा दिया है कि अब यह cliché बन चुका है, इसलिए इसे छोड़ दो। निजी तौर पर मुझे “Hammock driven development” ज़्यादा पसंद है, लेकिन इसे कंपनी में recommend करना थोड़ा मुश्किल है

• Abdulaziz के Kuwait लौट जाने के बाद उनके शांत हो जाने का अफ़सोस है। वह 2009 में Maxine VM intern थे और वाकई बहुत अच्छे इंसान थे। वह पेपर सचमुच एक रत्न है

  • मुझे भी अफ़सोस है, लेकिन लगता है कि उन्होंने हाल ही में एक bakery शुरू की है और उनका business अच्छा चल रहा है। उस मायने में देखें तो वह अपना सपना जी रहे हैं

• हाल ही में closure-based interpreters के ज़रिए interpreters को तेज़ करने पर एक अच्छा लेख आया था। मैंने उस technique का इस्तेमाल करके एक साधारण brainfuck interpreter बनाने की कोशिश की, और वह काफ़ी तेज़ निकला। शायद मुझे यह कहीं और काम न आए, लेकिन प्रयोग के तौर पर यह काफ़ी उपयोगी रहा

  • मुझे यह जानने में दिलचस्पी है कि closures की array और function pointer-data के बारी-बारी से रखे गए array में क्या फ़र्क है। दूसरा तरीका ज़्यादातर languages में स्वाभाविक नहीं लगता और C जैसी languages में ही ज़्यादा फिट बैठता है। फिर भी ऐसा लगता है कि static functions और data को एक ही array में साथ रखने से cache friendliness बेहतर हो सकती है

• काश JavaScript या .NET जैसी higher-level languages पर भी ऐसा कुछ लिखा जाए। यह लेखक बेहद बुद्धिमान हैं, लेकिन वे अधिकांश users की तुलना में कहीं ज़्यादा low-level (या high-level?) स्तर पर काम करते हैं

• उनके blog की दूसरी posts भी सचमुच शानदार हैं

• micrograd के बारे में: क्या Github repository के source code के अलावा और भी documentation उपलब्ध है?

  • Andrej Karpathy द्वारा micrograd बनाने की प्रक्रिया पर एक YouTube series है

• यह मैं उनकी बुराई में नहीं कह रहा, क्योंकि मैं उन्हें पसंद करता हूँ, लेकिन यहाँ मौजूद लेख वास्तव में PL (programming languages) के बारे में नहीं हैं; लगभग सभी compiler के बारे में हैं (garbage collector को छोड़कर)। बेशक compiler भी अच्छे लगते हैं, लेकिन वह PL विषय से अलग चीज़ है

  • क्या इसका मतलब programming language implementation नहीं हो सकता?