Arthur Whitney का C कोड पढ़ते हुए ज़्यादा समझदार बनना (2024)

• Arthur Whitney द्वारा बनाए गए 50-लाइन के K भाषा इंटरप्रिटर C कोड का विश्लेषण करते हुए, उनकी अनोखी coding style को समझने का एक लेखा-जोखा
• इस कोड में macro-आधारित संक्षिप्त syntax, non-standard C extensions, implicit arguments का उपयोग जैसी कई प्रयोगधर्मी संरचनाएँ शामिल हैं, जो सामान्य C कोड से अलग हैं
• लेखक ने हर macro और function का अर्थ खुद समझते हुए, APL परिवार की भाषाओं के दर्शन और code density के फायदे-नुकसान की पड़ताल की
• कोड की खूबियों में कम लंबाई और ऊँची संरचनात्मक क्षमता, और कमियों में non-standard syntax और readability में गिरावट को रेखांकित किया गया
• निष्कर्षतः, इस कोड को “संक्षेप में लिखने की कला” से अधिक समस्या को पूरी तरह समझ लेने के बाद कोड लिखने वाली सोच का उदाहरण माना गया

---

Arthur Whitney और उनका कोड

• Arthur Whitney एक computer scientist हैं जिन्होंने A, K, Q भाषाएँ और kdb, Shakti database डिज़ाइन किए
  • kdb वित्तीय क्षेत्र में इस्तेमाल होने वाला अत्यंत तेज़ time-series database है, और Shakti उससे भी तेज़ संस्करण है, जिसे 1 ट्रिलियन पंक्तियों के स्तर के dataset संभालने के लिए डिज़ाइन किया गया है
• उनकी भाषाएँ APL से गहरे प्रभावित array-आधारित भाषाएँ हैं, जो संक्षिप्तता और गणितीय अभिव्यक्ति-शक्ति को महत्व देती हैं
• लेख का फ़ोकस वित्तीय अनुप्रयोग नहीं, बल्कि Whitney द्वारा लिखे गए C कोड की विशिष्ट शैली का विश्लेषण है

50-लाइन वाले K इंटरप्रिटर की संरचना

• सार्वजनिक ksimple repository में Whitney द्वारा कुछ ही दिनों में लिखा गया लगभग 50-लाइन का C इंटरप्रिटर शामिल है
• कोड का केंद्र a.h और a.c इन दो फ़ाइलों में है, और इसकी विशेषताएँ हैं macro के जरिए function definition को छोटा करना और pointer को integer की तरह इस्तेमाल करने वाली संरचना
• typedef char*s,c; वाक्यांश के जरिए s को string pointer और c को character type के रूप में परिभाषित किया गया है
• s Q=(s)128; pointer को integer की तरह इस्तेमाल करने का उदाहरण है, और पूरे कोड में Q error state को दर्शाने वाले special value के रूप में उपयोग होता है
• ({e;}) रूप की statement expression और ?: operator जैसे कई GCC extension syntax इस्तेमाल किए गए हैं

प्रमुख macro और function का अर्थ

• #define _(e...) ({e;}) : कई statements को एक expression में बाँधने वाला macro
• #define i(n,e) : loop का संक्षिप्त रूप, for loop को एक लाइन में व्यक्त करता है
• #define Q(e) आदि error handling macro हैं, और Qr, Qd, Qz क्रमशः rank, domain, not-yet-implemented error लौटाते हैं
• _s, _i, f, F macro function declaration को सरल बनाते हैं, और implicit रूप से arguments x, a का उपयोग करते हैं
• ax, ix, nx आदि data type जाँच और indexing macro हैं, जहाँ ax यह जाँचता है कि “x atom है या नहीं”
• f(w,write(1,ax?&x:x,ax?1:strlen(x));x) एक output function है, जिसमें atom होने पर character और vector होने पर string के रूप में output दिया जाता है

इंटरप्रिटर कैसे काम करता है

• m(x) function memory allocation और length information वाले pointer का निर्माण करता है, और vector की अधिकतम लंबाई 255 bytes है
• g(a,v) macro atom/vector operation को एकीकृत ढंग से संभालता है, और not, sub, At, _A जैसी functions इसी के आधार पर परिभाषित हैं
• G(f,o) macro binary operator function को अपने-आप जनरेट करता है, और <, ==, +, *, &, | जैसे operations को support करता है
• cat, rev, cnt, Tak आदि vector manipulation functions हैं, और rev उल्टे क्रम का index बनाने के लिए ind function का उपयोग करता है
• e() function एक recursive evaluator है, जो string को दाएँ से बाएँ पढ़ते हुए single-character variable, digit, operator को handle करता है
• main() input लेकर e() से evaluate करने के बाद परिणाम output करने वाले REPL loop के रूप में काम करता है

कोड शैली का मूल्यांकन

• फायदे
  • composable macro से बने संक्षिप्त primitive operations का सेट
  • छोटी code length की वजह से बिना scroll किए पूरे logic को एक नज़र में समझ पाना
  • high-density expression के जरिए कोड की तार्किक संरचना को संकुचित करना
• कमियाँ
  • char* को integer की तरह इस्तेमाल करने वाला अर्थहीन type handling
  • ASCII code का सीधा उपयोग, जटिल ternary operator, non-standard syntax आदि के कारण readability में गिरावट
  • implicit arguments और छोटे variable names की वजह से आशय समझना कठिन होना
• तटस्थ पहलू
  • GCC-विशेष syntax (?:, statement expression) दिलचस्प हैं, लेकिन portability घटाते हैं
  • implicit arguments का उपयोग छोटे कोड में उपयोगी हो सकता है, लेकिन बड़े कोड में भ्रम पैदा कर सकता है
  • छोटे नाम आदत पड़ने पर कुशल हो सकते हैं, लेकिन अर्थ पहुँचाने की क्षमता कम रहती है

निष्कर्ष और सीख

• यह कोड सिर्फ “संक्षेप में लिखने का तरीका” नहीं, बल्कि समस्या को पूरी तरह समझ लेने के बाद कोड लिखने वाली सोच को दिखाता है
• Whitney का कोड पहले से पूर्ण हुए गणितीय मॉडल को कोड में उतारने का रूप है, यानी “विचार को कोड में व्यक्त करने” का परिणाम
• लेखक ने इस बात पर आत्मचिंतन किया कि वह आम तौर पर कोड के भीतर ही समस्या हल करने की आदत रखते हैं,
  और आगे कोड लिखने से पहले वैचारिक modeling और सोच को व्यवस्थित करने के महत्व पर ज़ोर दिया
• अंततः, इस प्रयोग को “कोड पढ़ने की क्षमता” को प्रशिक्षित करने और code density तथा विचार की स्पष्टता के संतुलन को परखने के अनुभव के रूप में समेटा गया

आगे के प्रयोगों के विचार

• इंटरप्रिटर विस्तार के अभ्यास के सुझाव:
  • floating-point vector support
  • 255 से अधिक elements को संभालना
  • multiple-digit numbers और variable names
  • array literals और whitespace को ignore करना
  • memory management और error display features जोड़ना
  • अधूरी functions को पूरा करना
• ऐसे विस्तार Whitney-शैली के कोड स्टाइल को बनाए रखते हुए इसे वास्तव में उपयोगी भाषा में विकसित करने के प्रयोग बन सकते हैं

[GN⁺]

Hacker News राय

• इस कोड के macro साझा operations को compress करने के लिए हैं मैंने पहले J Incunabulum पढ़ा था और उसके बाद यह कोड देखा, इसलिए C से परिचित programmers अगर बीच से पढ़ना शुरू करें तो शुरुआती macro definitions उन्हें उलझा सकती हैं क्योंकि macro एक-दूसरे पर आधारित होकर बनते जाते हैं, कोड जल्दी ही abstraction की सीढ़ी चढ़ने लगता है खास तौर पर Iterate macro (i) अच्छा लगा, जो लंबे-चौड़े loop को एक अक्षर में समेट देता है इस तरह का dense code पढ़ना मुश्किल इसलिए होता है क्योंकि कुछ ही दर्जन lines में बहुत सारी abstractions बनाई भी जाती हैं और तुरंत इस्तेमाल भी हो जाती हैं इसलिए इसे एक-एक अक्षर करके धीरे पढ़ना पड़ता है सैकड़ों पतली files वाले बड़े codebase में काम करने के नज़रिये से देखें तो इस तरह की चरम compressibility उलटे ताज़गीभरी लगती है

  • मैंने भी Incunabulum पढ़ते समय ऐसा ही सोचा था, लेकिन variables के नाम emoji में बदलकर देखने पर समझना बहुत आसान हो गया emoji version code image से पता चलता है कि समस्या सिर्फ information density नहीं, बल्कि orthography भी है आधुनिक भाषाएँ identifiers में symbols या emoji इस्तेमाल नहीं करने देतीं, लेकिन अगर यह visual distinction संभव होता तो पढ़ना कहीं आसान होता ज़्यादातर editors syntax highlighting इस्तेमाल करते हैं, लेकिन token-based coloring (हर identifier के लिए अलग रंग) कई बार ज़्यादा उपयोगी होता है Sublime Text का “hashed syntax highlighting” इसका एक उदाहरण है ऐसा करने पर कोड की structure एक नज़र में दिखने लगी
  • लगता है developers उलटे विशाल codebase पसंद करते हैं मुझे ऐसा ढांचा पसंद है जिसमें subdirectory न हों और grep *.[ch] से सीधे खोजा जा सके खासकर Java projects में छोटी files बहुत ज़्यादा होती हैं और उनमें सामग्री भी कम होती है, इसलिए कुछ ढूंढना मुश्किल हो जाता है IDE हो तो शायद आसान हो, लेकिन मैं उसका इस्तेमाल नहीं करता Whitney ने एक interview में कहा था कि वह सारा code एक पेज में रखना चाहते हैं, और उनका “IDE” Windows console और Notepad है

• Arthur Whitney के C code को समझने के लिए पहले APL परिवार की भाषाएँ सीखनी चाहिए नहीं तो यह बस अजीब-सी C style लगेगी Whitney असल में C को APL की तरह इस्तेमाल करना चाहते हैं spaces का न होना, एक-अक्षरी names, और one-line functions वाली शैली APL में भी वैसी ही है यह कुछ वैसा है जैसे कोई Pascal programmer #define begin { जैसी चीज़ें लिखे, बस Whitney उससे कहीं ज़्यादा मौलिक हैं

  • APL इस्तेमाल करने वालों की नज़र से भी यह अजीब दिखता है Whitney की बनाई K भाषा में यह शैली मिलती है, लेकिन one-line functions पारंपरिक APL में संभव नहीं थीं macros, ternary operator, और implicit variable names जैसी चीज़ें APL में नहीं हैं APL का मूल स्वभाव immutable array operations है, और Whitney की C style उस दर्शन से अलग है
  • “यह तो ऐसा है जैसे कोई Pascal programmer C में आकर #define begin { करे” वाली बात पर किसी ने मज़ाक में कहा, “अच्छा, Stephen Bourne की तरह?”
  • शुरुआत में यह किसी functional language जैसा लगा, लेकिन जल्द ही C preprocessor के भय की याद आ गई
  • लेख की शुरुआत में पहले से लिखा है कि “Whitney की C, APL से प्रेरित है” यानी यह टिप्पणी बस वही बात दोहरा रही है
  • J सीखना भी ठीक रहेगा APL की तुलना में वह ज़्यादा सुलभ है, क्योंकि उसमें सामान्य keyboard पर टाइप किए जा सकने वाले symbols इस्तेमाल होते हैं

• Shakti को देखते हुए मैंने पाया कि Wikipedia link k.nyc पर redirect होता है, और वहाँ पेज पर सिर्फ ‘k’ एक अक्षर है source देखा तो सचमुच सिर्फ `k

` ही था यह HTML version का Whitney-style minimalism लगा — जो अनावश्यक है उसे हटा दो, और compiler को implicit handling करने दो

• k

• Whitney की coding style पर किसी का भी मत हो, यह blog post बेहतरीन analysis है लेखक ने इसे सिर्फ 8 घंटे में लिखा, यह सोचकर इसकी गहराई और भी प्रभावशाली लगती है original link

• Stephen Bourne की वह कोशिश याद आ गई जिसमें वह C को Algol जैसा बनाना चाहते थे mac.h example और expand.c example में मिलता-जुलता एहसास आता है

• हर क्षेत्र में “best practice” होती है, लेकिन वह सिर्फ औसत मामलों में अच्छी बैठती है कुछ खास परिस्थितियों में उलटी दिशा में जाना बेहतर हो सकता है अंततः collective wisdom को default मानना ठीक है, लेकिन जैसे ही आप खुद सोचना शुरू करते हैं, उसकी सीमाएँ दिखने लगती हैं

  • इसलिए मुझे “best practice” शब्द पसंद नहीं असल में वह बस औसत दर्जे का समझौता है efficiency और performance छोड़कर maintainability और consistency हासिल करने का सौदा
  • अच्छा product बनाना और codebase की readability या learning curve अलग बातें हैं एक चीज़ अच्छी हो तो दूसरी अपने आप अच्छी होगी, ऐसा नहीं है

• अच्छा लगा कि इस code पर आक्रामक हुए बिना संतुलित नज़रिया रखा गया पढ़ने में मज़ा आया, और बाद में फिर पढ़ने का मन है

• सोच रहा था कि क्या यह coding style किसी विशिष्ट paradigm का हिस्सा है असली projects में ऐसा code लगभग कभी नहीं देखा, बस “business card ray tracer” जैसी कुछ अपवाद चीज़ें छोड़कर Whitney की बनाई J भाषा का source code भी इसी तरह की चरम compressed style रखता है

  • हाँ, यह Whitney की अपनी खास coding style है वह अपने array language interpreters में इसे लगातार इस्तेमाल करते हैं, और कुछ ही पन्नों में पूरा implementation समेट देने के लिए जाने जाते हैं इस पर हुई HN चर्चाओं को समेटने वाला meta comment link भी है
  • “मैंने असल में ऐसा code कभी नहीं देखा” पर किसी ने जवाब दिया, “आप भाग्यशाली रहे” यह अब C नहीं रह जाता, बल्कि C के ऊपर बनाई गई एक internal DSL जैसी भाषा बन जाती है C तो बस पहला compile target भर है
  • यह J, K जैसी APL परिवार की भाषाओं के करीब है इनमें non-ASCII symbols होते हैं, और चरम density के साथ एक पेज में बहुत जानकारी समा सकती है एक बार आदत हो जाए तो abstraction layers घटने का फ़ायदा भी मिलता है
  • इसी तरह के approach वाला co-dfns related video भी है यह C नहीं है, लेकिन वैसे ही high-density style में लिखा गया है
  • मज़ाक में इसे “OCC(Obfuscated C Code)” कहा गया

• नीचे दिए गए macro definitions देखें

  #define _(e...) ({e;})
  #define x(a,e...) _(s x=a;e)
  #define $(a,b) if(a)b;else
  #define i(n,e) {int $n=n;int i=0;for(;i