छोटी भाषाएँ प्रोग्रामिंग का भविष्य हैं

"Little Language" क्या है?

• 'छोटी भाषाएँ' वे भाषाएँ हैं जिन्हें किसी खास समस्या को हल करने के उद्देश्य से बनाया जाता है
  → SQL, RegEx, Dhall,..
  → इन्हें DSL भी कहा जाता है

छोटी भाषाओं की ज़रूरत क्यों है?

• जैसे-जैसे applications बहुत जटिल हुए हैं, source code भी बड़ा हुआ है, लेकिन उसे समझना भी कठिन हो गया है
• नए कर्मचारियों की onboarding कठिन हो जाती है, dependencies की समझ की कमी से errors आते हैं, और code changes को manage करना लगातार मुश्किल होता जाता है
• पिछले 10 सालों में codebase 100~500 गुना तक बड़े हुए हैं
  • Linux kernel 1992 में 10,000 lines से शुरू हुआ था, लेकिन 20 साल बाद 30 million lines का हो गया
• ऐसा सिर्फ इसलिए नहीं है कि "features बढ़ गए हैं"। ऐसा इसलिए भी है क्योंकि software बनाने का हमारा तरीका बदल गया है
  • software बनाना pyramid बनाने जैसा है; आख़िरी पत्थर रखने के लिए नीचे और ज़्यादा पत्थरों की ज़रूरत होती है

इस trend से कैसे निपटें

• क्या एक modern OS बनाने के लिए सचमुच millions of lines of code ज़रूरी हैं?
• Alan Kay ने 2006 के STEPS program में इस धारणा को चुनौती दी

• हमारा मानना है कि जिस समस्या को हमें हल करना है उसके अनुसार एक 'language' बनाना समस्या-समाधान को आसान बनाता है, और solution को अधिक समझने योग्य और साथ ही छोटा बनाता है

• STEPS में Nile नाम की एक भाषा बनाई गई, और 44,000-line Cairo renderer जैसी functionality को लगभग 300 lines of code में लागू किया गया

high-level languages क्यों काम नहीं करेंगी?

• क्या बस एक और higher-level general-purpose language बना देना काफ़ी नहीं है?
• व्यक्तिगत रूप से मुझे लगता है कि general-purpose languages की expressiveness पर हम diminishing returns तक पहुँच चुके हैं
• अगर भाषा और भी higher-level हो तो वह कैसी दिखेगी? Python को उदाहरण लें, तो वह पहले ही इतनी high-level हो चुकी है कि pseudo-code जैसी लगती है
• general-purpose language की समस्या यह है कि आपको अपनी समस्या को पहले algorithm में translate करना पड़ता है, और फिर उस algorithm को target language में व्यक्त करना पड़ता है
  • 1986 में Jon Bentley की Programming Pearls में Donald Knuth और Doug McIlroy को बुलाकर word frequency गिनने वाला program लिखने को कहा गया था; Don ने WEB नामक Pascal के एक variant में जटिल data structures के साथ 10 pages में उसे लिखा
  • इसके जवाब में Doug ने 6-line Unix pipe syntax में tr, sort, uniq, sort, sed आदि का उपयोग करके उसे बना दिया

कम ही ज़्यादा है Less is More

• ऊपर दिया गया Unix command छोटी भाषाओं की एक और विशेषता दिखाता है
  "कम शक्तिशाली language और अधिक शक्तिशाली runtime"
• Gonzalez ने "The end of history for programming" में इस trend की बात की है
  • user-space की समस्याओं को runtime की समस्या की ओर push करना
    • program को शुद्ध गणितीय expression जैसा बनाना, और runtime की complexity को बहुत बढ़ा देना
• regular expressions और SQL क्रमशः text search और database work के अलावा कुछ और व्यक्त नहीं कर सकते
• यह C जैसी भाषा के विपरीत है, जहाँ runtime नहीं होता और लगभग सब कुछ व्यक्त किया जा सकता है
• छोटी भाषाएँ C की शक्ति-स्पेक्ट्रम के दूसरे छोर पर खड़ी होती हैं
  • वे सिर्फ computer architecture को abstract नहीं करतीं, बल्कि किस तरह के programs व्यक्त किए जा सकते हैं उसे सीमित भी करती हैं, इसलिए design के हिसाब से Turing-incomplete होती हैं
  • यह बहुत सीमित लग सकता है, लेकिन optimization और static analysis के लिए यह संभावनाओं का एक नया आयाम खोलता है

static analysis

• कम शक्तिशाली languages पर reasoning करना आसान होता है, और वे general-purpose languages की तुलना में अधिक मज़बूत guarantees दे सकती हैं
• उदाहरण के लिए, Dhall configuration files बनाने के लिए एक "Total Functional Programming Language" है
  • यानी infinite loop के जोखिम को हटाने के लिए, Dhall programs के बारे में यह "guarantee" की जाती है कि वे "(1) crash नहीं होंगे, और (2) सीमित समय में समाप्त होंगे"
  • (1) exceptions न फेंकने से हासिल किया जाता है। जो operations fail हो सकते हैं वे Optional result लौटाते हैं (जिसमें value हो भी सकती है और नहीं भी)
  • (2) recursive definitions की अनुमति न देकर हासिल किया जाता है
• दूसरी functional languages में recursion loop लागू करने का बुनियादी तरीका है, लेकिन Dhall में built-in fold function पर निर्भर रहना पड़ता है
• सामान्य loop constructs का न होना यह दर्शाता है कि Dhall Turing-complete नहीं है। लेकिन यह general-purpose language नहीं है, इसलिए इसकी ज़रूरत भी नहीं
• जब language छोटी होती है, तब reasoning बहुत आसान हो जाती है
  • उदाहरण के लिए, यह जाँचना कठिन है कि Python program के कोई side effects नहीं हैं, लेकिन SQL में सिर्फ यह देखना काफ़ी है कि query SELECT से शुरू होती है या नहीं
• Nile के मामले में, STEPS team को एक graphics debugger की ज़रूरत थी इसलिए उन्होंने एक बनाया, और इसे सीधे देखा जा सकता है
  • यह संभव है क्योंकि Nile reasoning के लिए आसान एक छोटी भाषा है

speed की ज़रूरत

• अधिक शक्तिशाली programming languages न सिर्फ bugs की संभावना बढ़ाती हैं, बल्कि performance के लिए भी नुकसानदेह हो सकती हैं
• उदाहरण के लिए, अगर program algorithm के रूप में व्यक्त नहीं किया गया है, तो runtime खुद algorithm चुन सकता है
  • धीमे expressions को तेज़ expressions से बदला जा सकता है (बशर्ते यह साबित किया जा सके कि परिणाम एक ही है)
• उदाहरण के लिए, SQL query यह निर्देश नहीं देती कि query को कैसे execute किया जाए
  • database engine यह स्वतंत्र रूप से तय कर सकता है कि कौन-सा query plan उपयुक्त होगा
    • जैसे index इस्तेमाल करना है, composite index, या पूरी DB table scan करनी है
  • आधुनिक database engines प्रत्येक column में values के distribution की statistics भी इकट्ठा करते हैं, इसलिए वे मौके पर ही statistically optimal query plan चुन सकते हैं
  • अगर query algorithm के रूप में लिखी गई होती, तो यह संभव नहीं होता
• Nile language को इतना concise बनाने वाले "secret sauce" में से एक graphics rendering के लिए Just-in-Time compiler "Jitblt" था
  • STEPS और Cairo team की चर्चाओं से पता चला कि Cairo code का बड़ा हिस्सा pixel compositing operations को manually optimize करने में जाता है
  • सिद्धांततः यह काम compiler को offload किया जा सकता था
  • Cairo team के Dan Amelang ने स्वयं आगे बढ़कर ऐसा compiler बनाया, और वही Jitblt था
  • इसका मतलब यह था कि graphics pipeline की optimization को क्या render करना है उसकी शुद्ध गणितीय description से अलग किया जा सकता है,
    और इसी वजह से Nile हाथ से optimize किए गए original Cairo code जितनी तेज़ी से चल सका

Small languages, Big Potential (छोटी भाषाएँ, बड़ी संभावनाएँ)

• तो फिर STEPS का क्या हुआ? क्या वे ऐसा OS बना पाए जो T-shirt पर छापे जाने लायक code में चलता हो?
• STEPS का अंतिम परिणाम KSWorld था
  • document editor और spreadsheet editor वाला एक पूर्ण OS
  • 17,000 lines of code
  • T-shirt पर समाने के लिए यह code थोड़ा लंबा है, लेकिन मेरे हिसाब से यह एक सफलता है
• KSWorld का निर्माण दिखाता है कि "छोटी भाषाओं" में बड़ी संभावनाएँ हैं
• लेकिन अभी भी कई सवालों के जवाब बाकी हैं
  • ये भाषाएँ आपस में कैसे बात करेंगी?
  • क्या इन्हें किसी common intermediate representation में compile करना चाहिए?
  • या अलग-अलग runtimes समानांतर रूप से मौजूद हों और standard protocols (जैसे Unix pipes, TCP/IP) के ज़रिए communicate करें?
  • या क्या हर भाषा इतनी छोटी हो कि उसे कई host languages में दोबारा implement किया जा सके?
  • या शायद इन सबका संयोजन ही आगे बढ़ने का रास्ता हो?
• जो भी हो, मुझे यक़ीन है कि हमें software बनाने के दूसरे तरीकों के बारे में सोचना होगा
  • शायद "छोटी भाषाएँ" उस कहानी का एक हिस्सा बनें
  • अहम बात यह है कि जब तक हम कुछ बेहतर सोच न लें, तब तक हमें हर चीज़ के ऊपर और ईंटें जोड़ते नहीं रहना चाहिए

[ide127]

"
हम मानते हैं कि जिस समस्या को हल करना है उसके अनुरूप एक 'भाषा' बनाना, समस्या-समाधान को अधिक आसान बनाता है और समाधान को अधिक समझने योग्य होने के साथ-साथ छोटा भी रखता है।
"

इस हिस्से को पढ़कर मुझे लगा कि आखिरकार 'छोटी भाषा' का मतलब कहीं framework के समान ही तो नहीं है। जैसे JavaScript -> React के मामले में, जहाँ अक्सर इस्तेमाल होने वाले functions और design patterns को अनिवार्य करके उन्हें एक तरह के grammar में बदल दिया गया है।

[chicol]

दिलचस्प विषय है।

[kunggom]

ऐसा सोचते हुए मुझे हाल ही में JetBrains का बनाया हुआ MPS(Meta Programming System) नाम का DSL generation tool मिला।
यह मेरी उम्मीद से कहीं पुराना निकला। दिलचस्पी तो हुई, इसलिए इसे थोड़ा और देखना चाहता था, लेकिन यह बात बार-बार टलती रही। अगर किसी ने इसे इस्तेमाल किया है, तो मैं उसका usage review जैसा कुछ सुनना चाहूँगा।

[uglyduck68]

वाह, धन्यवाद

[nicewook]

आभार, मैंने इसे पढ़ा।

[roxie]

Lisp मुस्कुरा रहा है

[xguru]

मुझे यह एक दिलचस्प कहानी लगी, इसलिए साझा कर रहा/रही हूँ।