भाषा डिज़ाइन करना बंद करें, उसकी जगह लाइब्रेरी लिखें

• प्रोग्रामिंग उत्पादकता का मूल भाषा से अधिक समृद्ध लाइब्रेरी ecosystem में है
• Ruby on Rails जैसे भाषा की उन्नत सुविधाओं का उपयोग करने वाले framework गैर-विशेषज्ञों को भी उच्च उत्पादकता देते हैं
• लेकिन भाषा की संरचनात्मक सीमाओं के कारण Rails स्तर का framework Java या C में लागू करना कठिन है
• भाषा डिज़ाइन सीधे यह तय करती है कि किस रूप और जटिलता की लाइब्रेरी लिखी जा सकती है, और यही भाषा विकास का मूल उद्देश्य है
• Stanza भाषा इस दृष्टिकोण से दिखाती है कि शक्तिशाली और उपयोग में आसान लाइब्रेरी बनाना संभव करने के लिए भाषा डिज़ाइन कितना महत्वपूर्ण है

---

प्रोग्रामिंग भाषाओं और लाइब्रेरी का संबंध

• अधिकांश प्रोग्रामिंग भाषाओं में variables, arrays, loops, functions जैसे समान बुनियादी तत्व होते हैं
  • कुछ भाषाएँ first-class functions या coroutines जैसी उन्नत सुविधाएँ देती हैं, लेकिन गैर-विशेषज्ञ आमतौर पर उनका अच्छा उपयोग नहीं करते
• कई डेवलपर्स के लिए उत्पादकता बढ़ाने वाला कारक भाषा नहीं बल्कि लाइब्रेरी है
  • उदाहरण के लिए, Ruby on Rails डेटाबेस-आधारित web applications को आसानी से बनाने देता है
  • Rails की वजह से Ruby भाषा से अधिक framework के प्रति पसंद बनती है

Ruby on Rails और भाषा सुविधाओं की परस्पर क्रिया

• Rails, Ruby की metaprogramming, runtime evaluation, first-class functions, garbage collection जैसी कई सुविधाओं का उपयोग करता है
  • उदाहरण: ActiveRecords metaprogramming का उपयोग करता है, और template system runtime evaluation का
  • event handling, callback के रूप में first-class functions पास करके लागू की जाती है
• Java या C में ये सुविधाएँ पर्याप्त नहीं हैं, इसलिए Rails स्तर का framework लागू करना संभव नहीं
  • Java की metaprogramming, ActiveRecords लागू करने जितनी शक्तिशाली नहीं है
• इसलिए Rails, Ruby भाषा की संरचना की वजह से संभव है, और भाषा डिज़ाइन लाइब्रेरी की संभावनाएँ तय करती है

भाषा डिज़ाइन लाइब्रेरी के रूप को तय करती है

• C भाषा केवल function declarations और calls के जरिए पुन: उपयोग का समर्थन करती है, इसलिए अधिकतर C libraries functions के संग्रह के रूप में होती हैं
• Ruby, first-class functions का समर्थन करती है, इसलिए “button click होने पर चलने वाला action” को संक्षेप में व्यक्त किया जा सकता है
  • जबकि Java में handler class परिभाषित करनी पड़ती है, जिससे कोड जटिल हो जाता है
• भाषा की अभिव्यक्त क्षमता सीधे लाइब्रेरी की संरचना और उपयोगिता को निर्धारित करती है

इंटरैक्टिव software और विस्तार योग्य frameworks का उदय

• 1970 के दशक की batch computing में function-केंद्रित libraries पर्याप्त थीं
• आधुनिक इंटरैक्टिव software में extensible libraries की आवश्यकता होती है
  • GUI या event-based systems में “user click करने पर मेरा code चलाओ” जैसी संरचना चाहिए
• Java और C++ inheritance और method overriding के जरिए विस्तार का समर्थन करते हैं, और यही संरचना आगे frameworks में विकसित हुई

Stanza डिज़ाइन की पृष्ठभूमि और भाषा की सीमाएँ

• Stanza के डिज़ाइन की प्रेरणा Java में उपयोग में आसान game programming library लिखने की कठिनाई से शुरू हुई
  • Java में concurrency को state machine के रूप में व्यक्त करना पड़ता था
  • Scheme, continuation का समर्थन करता है, इसलिए अधिक सहज implementation संभव है
• लेकिन Scheme static type checking का समर्थन नहीं करता, इसलिए debugging की दक्षता कम होती है
  • वर्तमान में अधिकांश भाषाएँ type system को library के रूप में extend नहीं कर सकतीं
• Stanza, optional type system, garbage collection, multimethod-based object system प्रदान करता है
  • लेकिन नया user-defined object system फिर से लिखना संभव नहीं है

भाषा का उद्देश्य और शोध की दिशा

• सामान्य-उद्देश्य प्रोग्रामिंग भाषा का उद्देश्य शक्तिशाली और उपयोग में आसान libraries के निर्माण का समर्थन करना है
  • भाषा जितनी शक्तिशाली होगी, library का उपयोग उतना ही संक्षिप्त होगा
• जब code अच्छी तरह डिज़ाइन की गई library का उपयोग करता है, तो उसमें सहकर्मी को निर्देश देने वाले वाक्य जैसी स्वाभाविकता होती है
• Racket, Shen, meta object protocol पर शोध आदि विस्तार योग्य type और object systems की खोज कर रहे हैं
• अंततः भाषाओं का अंतर इस बात से तय होता है कि “कौन-सी libraries इस्तेमाल की जा सकती हैं, और कौन-सी नहीं”
• सुंदर libraries के पीछे दशकों का भाषा अनुसंधान और डिज़ाइन प्रयास मौजूद होता है

[GN⁺]

Hacker News की टिप्पणियाँ

• सबसे अच्छा उदाहरण Prolog है। इसे अक्सर logic programming की प्रतिनिधि भाषा कहा जाता है, लेकिन असल में यह कई algorithms का संग्रह भर है, और इन्हें अलग-अलग भाषाओं की library के रूप में implement किया जा सकता है। मुझे लगता है कि Prolog की syntactic expression को हर भाषा के syntax के अनुसार उपलब्ध करा देना काफी होगा

  • Prolog का मूल एल्गोरिदम नहीं, बल्कि logic rules को declaratively व्यक्त करने का तरीका है। उदाहरण के लिए, अगर “grandparent is the parent of a parent” जैसा नियम define करें, तो उससे grandparent ढूँढा जा सकता है या उल्टा parent relation infer किया जा सकता है। यही bidirectional inference Prolog की खासियत है। बेशक, किसी सामान्य भाषा में ऐसी क्षमता की नकल करने के लिए side effect-रहित code और सीमित DSL की ज़रूरत होगी। PyTorch या TensorFlow की तरह, जो Python से CUDA चलाते हैं, भाषाओं के बीच calls भी संभव हैं, इसलिए language-independent structure भी पूरी तरह संभव लगता है
  • Prolog का syntax First Order Logic का subset है, जहाँ variables को कोई value assign नहीं की जाती, बल्कि वे possible values के set पर तब तक search करते हैं जब तक conditions satisfy न हों। Prolog engine सिर्फ साधारण library call से कहीं ज़्यादा काम करता है — जैसे solution space का compressed representation, parallel execution, automatic pruning वगैरह। इसलिए आम तौर पर Prolog को backend service के रूप में रखा जाता है या code generation के जरिए integrate किया जाता है। Prolog planning, constraint solving, theorem proving, combinatorial testing, pricing modeling जैसे क्षेत्रों में खास तौर पर शक्तिशाली है। इसलिए Prolog को सिर्फ “ऐसी भाषा जिसे library से बदल सकते हैं” कहना मुझे ठीक नहीं लगता
  • इसी तर्क से यह भी कहा जा सकता है कि object-oriented features को closures से emulate किया जा सकता है, इसलिए उन्हें भाषा में होने की ज़रूरत नहीं। लेकिन स्पष्ट syntax से मिलने वाली expressive power का अपना फायदा होता है
  • Prolog जैसी relational programming को library के रूप में implement करने के लिए भाषा में symbols और variables की manipulation के लिए first-class support होना चाहिए। Lisp जैसी भाषाओं में यह कुछ हद तक संभव है, लेकिन सामान्य भाषाओं में usability बहुत गिर जाती है। जब मैंने Bob Harper से इस बारे में बात की, तो उन्होंने कहा, “बस नई भाषा बना लो,” और वह बात काफ़ी convincing लगी
  • मैं Prolog सीखना चाहता हूँ, लेकिन शुरुआती tutorial और advanced examples के बीच का intermediate स्तर का material मिलना मुश्किल है। मैं Sudoku के किसी variant puzzle को Prolog से हल करने की कोशिश कर रहा हूँ, लेकिन मौजूदा examples इतने optimized हैं कि generalized relational definitions सीखना कठिन हो जाता है। खास तौर पर यह जानना चाहता हूँ कि ऐसी स्थिति को कैसे model करें जहाँ कुछ rules गलत भी हो सकते हों। संदर्भ के लिए, मैं SWI-Prolog का Sudoku उदाहरण देख रहा हूँ

• 10 साल पहले मैं Scala का बड़ा प्रशंसक था। type system के अंदर DSL बनाने वाली “Scalable Language” की अवधारणा बहुत आकर्षक लगती थी। लेकिन जब community ने इसे JVM पर Haskell की तरह इस्तेमाल करना शुरू किया, तो मेरी दिलचस्पी कम हो गई। आजकल मुझे WASM और Graal जैसी तकनीकों से उम्मीद है कि वे भाषा चुनने में ज़्यादा flexibility देंगी। कई बार JS ही काफी होता है, लेकिन ज़रूरत पड़ने पर Rust जैसी low-level language इस्तेमाल कर पाने का विकल्प होना अच्छा है

  • मुझे भी लगता है कि Scala की सबसे बड़ी समस्या DSL का overuse है। सिर्फ भाषा ही नहीं, test frameworks वगैरह में भी ऐसा लगता है जैसे एक और भाषा सीखनी पड़ रही हो। बेशक, Hadoop MapReduce को एक लाइन में व्यक्त कर पाना प्रभावशाली था, लेकिन ज़्यादातर कामों के लिए यह ज़रूरत से ज़्यादा है। ऊपर से Scala developers अक्सर “boring code” लिखना पसंद नहीं करते। स्टाइल मारने की कोशिश में maintainability का नरक छोड़कर चले जाने वाले कई मामले देखे हैं
  • पूरी Scala community Haskell-झुकाव वाली नहीं है। बस कुछ type wizards ऐसा रुझान दिखाते हैं। Scala को सिर्फ “better Java” की तरह भी इस्तेमाल करें, तब भी यह शानदार है। functional programming के फायदे बिना ज़्यादा बोझ के मिल जाते हैं
  • Haskell का इस्तेमाल मूल रूप से DSL बनाने वाली भाषा के रूप में भी खूब होता है। Meta का Haxl और music DSL TidalCycles इसके अच्छे उदाहरण हैं। लेकिन higher-kinded types पर आधारित libraries में performance गिरावट बहुत होती है, और वे बेवजह जटिल भी हो जाती हैं
  • क्या आपने Clojure(Script) इस्तेमाल किया है? Lisp परिवार की भाषा होने के कारण इसमें समस्या के मुताबिक भाषा को बढ़ाने वाला bottom-up programming संभव है। Paul Graham की On Lisp में भी इस approach पर ज़ोर दिया गया है। यह related talk भी recommend करूँगा: Bottom Up vs Top Down Design in Clojure
  • मैंने हाल ही में Scala सीखना शुरू किया है, और functional programming के लिहाज़ से यह मुझे सच में बहुत पसंद आ रही है। DSL बनाने के अलावा भी यह कई तरह से इस्तेमाल करने लायक़ general-purpose लगती है। क्या आपको Scala में कोई कमी महसूस होती है?

• अच्छा होगा अगर typed scripting language से bash को replace किया जा सके। मैंने Elixir में एक आसान JSON parser script लिखकर देखा, और अनुभव काफ़ी अच्छा था

  • क्या आपने Nushell इस्तेमाल किया है? जिन कामों के लिए पहले “असली भाषा” चाहिए होती थी, उन्हें यह एक लाइन में निपटा सकता है। उदाहरण के लिए, file list को sort करके JSON में output देने वाली pipeline बहुत आसानी से लिखी जा सकती है
  • सच तो यह है कि shebang के जरिए कई भाषाओं में scripts लिखी जा सकती हैं। उदाहरण के लिए C#, Java, Go — सब संभव हैं। Scriptisto का उपयोग करें तो लगभग किसी भी भाषा में shebang script बनाई जा सकती है
  • OCaml को भी script की तरह इस्तेमाल किया जा सकता है। #!/usr/bin/env ocaml से सीधे चल जाता है। हाँ, single file में external dependencies को अपने-आप install करने की सुविधा नहीं है
  • Go में भी shebang की नकल करने वाला एक trick है। related discussion यहाँ देख सकते हैं
  • रोज़मर्रा की scripting के लिए Python या PowerShell भी अच्छे विकल्प हैं

• भाषा और library एक-दूसरे के विरोधी नहीं हैं। कुछ libraries व्यवहार में भाषा की तरह काम करती हैं, और उल्टा कुछ भाषाएँ खास libraries के लिए design की जाती हैं। उदाहरण के लिए Julia performance और usability के बीच संतुलन का अच्छा उदाहरण है। high-performance code सीधे Julia में लिखा जा सकता है, और JIT-स्तर की type-specialized compilation से optimized execution मिलता है। ऊपर से यह simple function call model जैसा दिखता है, लेकिन अंदरूनी तौर पर बहुत sophisticated तरीके से काम करता है

  • सही कहा, आखिरकार मुख्य बात यही थी कि भाषा और library दोनों चाहिए

• Raku को कई sublanguages (slang) को जोड़ने वाली संरचना के रूप में design किया गया है। उदाहरण के लिए regex, PEG, quoting आदि को अलग-अलग mini-languages की तरह संभाला जाता है, और Slangify से अपना DSL आसानी से जोड़ा जा सकता है

  • लेकिन व्यक्तिगत रूप से मुझे ऐसा syntax जिसमें type variable name के बाद आता है पसंद नहीं, इसलिए मैं Raku को नहीं चुनता

• पहले एक senior developer ने कहा था, “अगर resume में Rails दिखे तो मैं तुरंत फेंक देता हूँ।” इससे फिर महसूस हुआ कि लोगों का मूल्यांकन भाषा के आधार पर करना कितना मूर्खतापूर्ण है

  • Rails का उभार और J2EE का पतन एक ही समय पर हुआ, यह यूँ ही नहीं था। Rails ने simple और opinionated backend code दिखाया, और उसके प्रभाव से DropWizard, Javalin, Spring Boot जैसे Java frameworks आए
  • उस senior का tech stack क्या था, यह जानने की उत्सुकता है
  • ऐसे सहकर्मी का कूड़ादान मैं खुद उठाना चाहूँगा। अच्छे Rails developers मिलना मुश्किल है। मेरे पास भी RoR experience है और मुझे यह अब भी पसंद है
  • बेशक, अगर आप Java developers ढूँढ रहे हैं, तो Rails resumes को छाँटना शायद efficient हो सकता है
  • लोगों का मूल्यांकन आखिरकार organization की cultural fit और collaboration style पर निर्भर करता है। filtering का कोई perfect तरीका नहीं है

• भाषा या library आखिरकार मशीन और इंसान, दोनों से संवाद करने का माध्यम हैं। मशीन bits और voltage से संवाद करती है, और इंसान intent और concepts से। इसलिए अगर कोई भाषा या library इंसानों के लिए स्पष्ट और तेज़ अभिव्यक्ति का माध्यम देती है, तो वह भाषा है या library, यह उतना महत्वपूर्ण नहीं। Rails हो या Stanza, अगर वह उद्देश्य के अनुकूल है और टीम उसे आसानी से समझ सकती है, तो वही सही उत्तर है

• मैं मानता हूँ कि “library ही आख़िरकार अंतिम भाषा बन जाती है।” उदाहरण के लिए Ruby on Rails, Ruby पर आधारित एक शानदार web service language है। Ruby और Rails एक-दूसरे के लिए साथ विकसित हुए हैं। अंततः programming भाषाओं के लगातार translation की प्रक्रिया ही है

  • C# और ASP.NET Core भी इसी तरह साथ विकसित हुए हैं। user-friendly syntax और system-level optimization दोनों साथ-साथ हुए

• “भाषा जितनी शक्तिशाली होगी, libraries का उपयोग उतना आसान होगा” — यह बात सही है। पुराने Java में Express जैसा framework बनाना कठिन था

  • मुझे नहीं पता Express क्या है, लेकिन मुझे लगता है कि Java ने library usability की वजह से enterprise language के रूप में अपनी जगह बनाई
  • C# का ASP.NET Core minimal API लगभग Express को ही implement करने जैसा उदाहरण है। यह तभी संभव है जब भाषा और framework साथ विकसित हों
  • Java में भी Javalin जैसा Express-सदृश framework है। समस्या यह है कि community simplicity नहीं चाहती

• अगर C language के लिए web framework चाहिए, तो PHP है न? ;)

  • यह तो library की अवधारणा को कुछ ज़्यादा ही खींच देने वाला मज़ाक लगता है