Lisp की राह: Lisp क्यों?

 (scotto.me)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Lisp का असली सार parentheses वाली syntax से ज़्यादा भाषा को समस्या के हिसाब से extend करने की सोच में है; इसकी असली ताकत समझने के लिए REPL, packages, symbols, conditions और restarts तक सीखने पड़ते हैं
  • code और data दोनों के list के रूप में व्यक्त होने वाली homoiconicity की वजह से macros, evaluation से पहले code को data की तरह संभालकर नए control structures और syntax abstractions बना सकते हैं
  • Common Lisp में मौजूद नहीं while को भी defmacro से जोड़ा जा सकता है, लेकिन अगर उसे function से imitate करें तो arguments तुरंत evaluate हो जाते हैं और body code नहीं बल्कि value बन जाता है
  • Lisp development, चल रहे process में code को लगातार evaluate करने वाले REPL-driven development जैसा है, जहां functions, macros और variables को redefine करते हुए program को बिना रोके evolve किया जा सकता है
  • जब language extensibility और live system मिलते हैं, तो internal DSL को users के सामने expose करने वाला extendable software बनाया जा सकता है; AutoLISP और Emacs इसके प्रमुख उदाहरण हैं

Lisp जिस अलग programming sensibility की मांग करता है

  • Lisp को पहली बार देखने वाले programmers को ढेर सारे parentheses वाली syntax, अनोखी indentation, और format के पहले argument के रूप में standard output specify करने का तरीका अपरिचित लगता है
  • Lisp सीखने के लिए सिर्फ code पढ़ना नहीं, बल्कि packages और symbols, project creation, libraries import करना, REPL, conditions और restarts तक संभालना पड़ता है
  • बड़ा बदलाव algorithms को compose करने के तरीके में दिखता है
    • Lisp ऐसी चीज़ें संभव बनाता है जो दूसरी languages में करना मुश्किल होता है, और algorithms का shape भी बदल देता है
    • flow यह बनता है कि पहले समस्या के हिसाब से language को बढ़ाया जाए, फिर उसी language में program लिखा जाए
  • Blub paradox वह concept है जो समझाता है कि केवल कम शक्तिशाली languages इस्तेमाल कर चुके programmers के लिए Lisp की strengths पहचानना क्यों मुश्किल होता है

Extendable language

  • Lisp खुद को extend कर सकता है, और Lisp experts इसे programmable programming language कहते हैं
  • इसका मुख्य tool macro है
    • यह C, Rust, Swift के macros की तरह सिर्फ repeated code हटाने तक सीमित नहीं रहता
    • Lisp macros ऐसे नए components बना सकते हैं जो language का हिस्सा बन जाते हैं
  • Common Lisp में built-in while operator नहीं है, लेकिन defmacro से इसे खुद जोड़ा जा सकता है
(defmacro while (condition &body body)
  `(loop while ,condition do
     (progn ,@body)))
  • यह while macro, जब तक condition true है, body के कई commands execute करता है
    • loop complex repetition लिखने के लिए एक macro है
    • progn कई expressions को क्रम से execute करता है और आखिरी expression का result return करता है
  • नतीजतन (loop while ... do (progn ...)) के बजाय (while ...) form इस्तेमाल किया जा सकता है, जिससे code छोटा हो जाता है और C के while जैसी structure मिलती है

Macros और functions के बीच निर्णायक फर्क

  • उसी behavior को function fake-while के रूप में बनाएं तो यह fail हो जाता है
(defun fake-while (condition body)
  (loop while condition do
    (funcall body)))
  • fake-while call में arguments पहले evaluate होते हैं
    • condition true value t बन जाता है
    • progn के अंदर (print counter) execute होता है और (decf counter) 2 return करता है
    • body code block नहीं, बल्कि value 2 बन जाता है
  • इसके बाद funcall function की उम्मीद करता है, लेकिन उसे 2 मिलता है, इसलिए The value 2 is not of type FUNCTION जैसी type error आती है
  • इसके उलट macro while, condition और body को तुरंत evaluate नहीं करता, बल्कि preserve करता है
    • macroexpand-1 से expanded result देखा जा सकता है
    • compiler को expanded (LOOP WHILE ... DO (PROGN ...)) form का code मिलता है
  • macros, functions से अलग, arguments को पहले से evaluate नहीं करते और उन्हें pure data की तरह handle करते हैं, इसलिए ऐसा transformation संभव होता है

Lists, s-expression, homoiconicity

  • Lisp programs symbolic expression, यानी s-expressions की sequence से बने होते हैं
  • s-expression दो तरह के होते हैं
    • atom: number, string, symbol जैसी data unit
    • list: atoms या दूसरी lists रखने वाला collection
  • Lisp नाम LISt Processing से आया है, और program बनाने वाले commands भी lists के रूप में represent होते हैं
  • Lisp में list मुख्य data structure भी है और code लिखने का तरीका भी
    • code और data दोनों के list के रूप में represent होने की property को homoiconicity कहते हैं
  • वही (+ 1 2) list evaluation के आधार पर अलग तरह से behave करती है
    • (+ 1 2) code के रूप में evaluate होकर 3 return करता है
    • '(+ 1 2) evaluate नहीं होता और data list के रूप में जस का तस return होता है
  • Lisp Polish notation का उपयोग करता है, जिसमें function name list का पहला element होता है और उसके बाद arguments आते हैं
  • code और data की boundary पतली होने के कारण macros source code को transform कर सकते हैं और program लिखने वाले programs बनाए जा सकते हैं

Macros से बनने वाला code abstraction

  • language को extend करने पर किसी खास program domain के लिए अधिक expressive नए components बनाए जा सकते हैं
  • repeated boilerplate को custom macros से replace करके code घटाया जाता है और समय बचता है
  • नए control structures बनाकर resource access और form evaluation को control किया जा सकता है
  • macros code generate करते हैं, performance सुधारते हैं, और complex व error-prone code को छिपाने वाला syntax abstraction देते हैं

Lisp एक live system है

  • Lisp को सिर्फ programming language के बजाय चलते हुए live system की तरह संभाला जाता है
  • आम languages में editor में code लिखकर compile और run करने के बाद observe, test और debug करने का flow ज्यादा होता है
  • Lisp में पहले Lisp process start किया जाता है, फिर REPL से connect करके project को उसी process में load किया जाता है
  • REPL, Read-Eval-Print Loop का संक्षेप है; यह code evaluate करके तुरंत result देखने वाला interactive environment है
    • यह currently running program वाले Lisp process में झांकने वाली window की तरह काम करता है
  • Lisp developers running process के अंदर code लगातार evaluate करते हैं और result सीधे REPL में देखते हैं
    • individual functions की testing
    • database queries
    • variables की inspection
    • debugging जैसे काम भी REPL से किए जा सकते हैं
  • Lisp process को रोकने की जरूरत नहीं होती, वह हफ्तों तक live रह सकता है
  • functions, macros और variables internal memory यानी environment में लगातार define और redefine होते रहते हैं; इस flow को REPL-driven development कहा जाता है

Lisp में hot reloading

  • web frontend में file save या page refresh के जरिए JavaScript code hot reload होने का अनुभव आम है
  • सामान्य hot reloading, file watching, changed modules को recompile करना, WebSocket के जरिए changes inject करना जैसे अलग tools और techniques पर निर्भर होती है
  • हर software stack समान स्तर की hot reloading नहीं देता
    • कुछ backend frameworks को recompilation की जरूरत होती है
    • desktop और mobile development environments में स्थिति मिली-जुली है
    • low-level languages में हर बार full compilation चाहिए होता है
  • Lisp में hot reloading कोई अलग tool नहीं, बल्कि live environment में code evaluate करने पर स्वाभाविक रूप से साथ आता है
    • symbol redefine करने पर functions, data और macros सभी नई definition इस्तेमाल करते हैं
    • रुककर compile करने, tests को अलग से run करने, या special debugger इस्तेमाल करने की जरूरत घट जाती है
  • Lisp programming, program को assemble करने से ज्यादा उसे evolve करने के तरीके जैसी है

Extendable software

  • language extensibility और live system, Lisp में extendable software बनाना आसान करते हैं
  • सामान्य desktop programs plugins या scripting language के जरिए extend होते हैं
    • developers को extension system design और maintain करना पड़ता है
    • users को plugin या extension लिखने के लिए कोई specific API सीखनी पड़ती है
  • Lisp में macros के जरिए behavior को encapsulate और reuse करना आसान बनाते हुए स्वाभाविक रूप से DSL लिखी जाती है
  • software को extendable बनाना हो तो अंदर बनाई गई DSL users को इस्तेमाल करने दें
  • CMS server example में server-side webpage generation के लिए html macro users को expose किया जा सकता है
    • users Lisp variables, dolist loops, format string formatting को उसी तरह साथ में इस्तेमाल कर सकते हैं
    • traditional template languages की तरह {{ user_name }} या {% for %} जैसी अलग syntax सीखने की जरूरत नहीं होती
  • यह DSL Lisp की conditionals, recursion, higher-order functions और REPL step-by-step debugging capability को ज्यों का त्यों inherit करती है
  • math graph software example में equations और drawing के लिए DSL expose करके users को कम code में curves और points draw करने दिया जा सकता है

Real-world examples और Lisp की स्थिति

  • AutoCAD repeated tasks automate करने और complex geometry generate करने के लिए AutoLISP इस्तेमाल करता है
  • Emacs अपने Lisp dialect में बड़े हिस्से तक implemented एक text editor है, जिसने high extensibility हासिल की है
    • PDF reader
    • web browser
    • email client
    • RSS reader
    • terminal multiplexer
    • Git client
    • music player
    • chat client
    • spreadsheet
    • IRC client
    • desktop window manager तक extend हुए examples गिनाए जाते हैं
  • R. M. Stallman ने Lisp को ऐसी language माना है जो powerful और elegant programming language का अर्थ समझाती है
  • Lisp कभी default language की तरह व्यापक रूप से इस्तेमाल होगा, यह उम्मीद पूरी नहीं हुई, और आगे भी इसकी संभावना कम दिखती है
  • फिर भी Lisp 1960s से बचा हुआ है और Fortran के बाद सबसे पुरानी active programming language बन गया है
  • Lisp की value extensibility, interactive environment, REPL जैसे किसी एक feature में नहीं, बल्कि उनके combination में है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News की राय

  • प्रोग्रामिंग लाइट साइड और डार्क साइड के बीच के तनाव पर टिकी है
    लाइट साइड वह है जो प्रोग्रामर को गलतियां करने से रोकती है: goto हटाना, static types जोड़ना, bugs को express करना असंभव बना देना वगैरह
    डार्क साइड वह है जो प्रोग्रामर को शक्ति देती है: macros, operator overloading, self-modifying code, यहां तक कि multi-line regular expressions तक खुलकर allow करती है
    Lisp साफ तौर पर डार्क साइड है, क्योंकि इसमें प्रोग्रामर कुछ भी कर सकता है, फिर भी दिलचस्प बात है कि लाइट साइड वाले प्रोग्रामर भी इसकी इज्जत करते हैं। हो सकता है भाषा की सरलता उसे प्लेटोनिक और लगभग भ्रष्ट न हो सकने वाली दिखाती हो, या फिर Lisp इतना शुद्ध है कि वह programming universe को जन्म देने वाले देवता की तरह दोनों पक्षों को अपने में समेट लेता हो

    • dynamic types और static types की बहस में सुनी हुई बात को बदलकर कहें तो, permissive language अकेले काम करने वाले प्रोग्रामर को ताकत देती है, लेकिन team development के लिए ज्यादा restrictive language चाहिए होती है
      आप हमेशा यह नहीं चुन सकते कि किसके साथ काम करेंगे, और टीम के अंदर skill level भी समान नहीं होता। जब कम अनुभवी साथी गलतियां करते हैं, तो भाषा जितनी ज्यादा permissive होगी, उसका असर उतना बड़ा होगा
      इसलिए code review की जरूरत पड़ती है, लेकिन तब आप अनुभवी प्रोग्रामर को शिक्षक में बदल देते हैं। दूसरे प्रोग्रामर की skill बढ़ाने में लगाया गया समय आंशिक रूप से इसलिए बेकार जाता है क्योंकि प्रोग्रामर कभी भी आ-जा सकते हैं। AI इस व्यवस्था को बदल सकता है
      आखिर में मुख्य बात छोटी और अनुभवी टीम बनाए रखना है, लेकिन company politics की वजह से यह आसान नहीं होता। मसलन bus factor को ध्यान में रखना या release timeline घटाने के लिए और developers जोड़ना अक्सर सामने आता है
    • Lisp में आम तौर पर precise garbage collection होता है, इसलिए इसे लाइट साइड के करीब भी माना जा सकता है। अगर runtime type checking को type safety मानें तो यह काफी type-safe भी है
      high-reliability systems Erlang में भी लिखे जाते हैं, जिसे आंखें थोड़ी सिकोड़कर देखें तो एक और Lisp dialect जैसा माना जा सकता है। LFE नाम का S-expression आधारित version भी है, जो Lisp-style Erlang है
      Erlang की reliability का core असाधारण स्तर की error prevention में नहीं, बल्कि error recovery में है। लाइट/डार्क classification खुद मुझे पसंद है
    • मेरे हिसाब से Lisp की बड़ी खासियत यह है कि mutable variable assignment को छोड़ दें तो यह मूल रूप से declarative है, imperative paradigm नहीं
      static types नहीं हैं और macros अफरा-तफरी मचा सकते हैं, फिर भी declarative और functional सोच की baseline कहीं मजबूत है, जिससे program को ज्यादा साफ तरीके से सोचने और reason करने की शुरुआत बेहतर होती है
    • सोचता हूं Malbolge को किस तरफ रखा जाएगा। Python, Haskell, Idris, Clean, C, K फिर किस तरफ हैं?
      लाइट/डार्क विभाजन बहुत ज्यादा सरलीकरण जैसा लगता है। programming languages का balance बेहद जटिल और दिलचस्प विषय है
      कई भाषाओं के साथ सालों तक प्रयोग करने के बाद लगा कि आखिरकार बात use context, personal preference और goals की है। “अब तक की सबसे अच्छी programming language” जैसी कोई चीज नहीं, और “लाइट साइड programming के लिए best” या “डार्क साइड programming के लिए best” भी नहीं
      कला में painting के लिए भी लाइट/डार्क साइड जैसी चीज नहीं होती। निश्चित रूप से कुछ paintings ज्यादा महान होती हैं, लेकिन ऐसी “best painting” नहीं है जिसे हर व्यक्ति बाकी सभी paintings की तुलना में सबसे सुंदर माने
      https://en.wikipedia.org/wiki/Malbolge
      https://en.wikipedia.org/wiki/Clean_(programming_language)
      https://en.wikipedia.org/wiki/K_(programming_language)
    • लगता है लाइट और डार्क को उलटा मिला दिया गया है। creator सबसे अच्छा जानता है वाली बंदिश और अनुशासन डार्क साइड है, और लोगों को शक्ति सौंपना लाइट साइड है

  • पिछले कुछ महीनों में बेहतरीन नए editors और tools आए हैं, इन्हें miss नहीं करना चाहिए
    Mine एक single-download app है, जो hot reloading और instant debugging समेत interactive और incremental development flow का अनुभव लेने के लिए जरूरी सब कुछ देता है। यह CL और Coalton के लिए है
    https://coalton-lang.github.io/20260424-mine/
    OLIVE VSCode के लिए hand-crafted plugin है, और ICL terminal और browser के लिए नया REPL है, जिसमें advanced features हैं। bonus के तौर पर JSCL-based JupyterLite kernel भी है, जो 100% browser में चलता है
    सब यहां देख सकते हैं: https://lispcookbook.github.io/cl-cookbook/editor-support.ht...

    • mine का source नहीं मिल रहा। कोई link है?

  • लगता है website में syntax highlighting bug है। लेख में शामिल code snippets काले रंग में दिखते हैं, और mouse से select करने पर ही असली text दिखाई देता है
    desktop Chrome और iPad Safari में वही bug दिख रहा है

    • background color बदलते समय हमेशा foreground color भी साथ में set करना चाहिए—यह उसका classic example है। नहीं तो black background पर black text blocks बन जाते हैं। अगर browser dark mode में हो तो शायद ठीक दिखेगा
      workaround यह है कि browser debugger में किसी code element को खोलें और :not(pre) > code style में color: white जोड़ दें
    • comment पढ़ते ही error fix कर दिया
    • MacOS Chrome है क्या? Linux पर Firefox, Chromium, Brave में code blocks सही दिख रहे हैं। शायद ये सब Qt इस्तेमाल करते हैं
    • Firefox और Chrome दोनों में वही चीज दिखती है
    • पहले मुझे लगा कि लेख censor किया गया है

  • Lisp के फायदों की तारीफ़ करने वाले लेख बहुत हैं। मैं ऐसे लेख भी देखना चाहूँगा जो Lisp, उसके ideas, और language ecosystem में उसकी जगह की शांत ढंग से आलोचना करें
    ऐसे लेख या यहाँ reference किए गए PG के लेख आखिरकार “जो जानते हैं, वे जानते हैं” जैसे ही हैं। उसका आकर्षण भी समझता हूँ, और यह लेख जो explicit और implicit दावे कर रहा है उन्हें भी समझता हूँ
    Computer programming पिछले 60 सालों में काफ़ी mature हो चुकी है। मैं ऐसे और लेख देखना चाहूँगा जिनमें ज़्यादा सोच-विचार वाली समीक्षा हो

    • भाषा के रूप में Lisp शानदार है, लेकिन ecosystem सीमित है। इसकी दो कमियाँ हैं। एक यह कि यह बहुत ज़्यादा खुला है, इसलिए talent और discipline न हो तो इंसान मज़ेदार Lisp hacking के rabbit hole में गिरकर असल काम पूरा नहीं कर पाता। दूसरी भाषाओं में भी यह समस्या है, लेकिन मेरे हिसाब से Lisp में यह ज़्यादा है
      दूसरी कमी यह है कि यह काफ़ी सक्षम लोगों का कई-कई साल समय खा जाती है, जबकि नतीजा उस निवेश किए गए समय को justify नहीं करता। Python जैसी चीज़ भी काफ़ी है। मुझे लगता है कि Lisp में लगाया गया ज़्यादातर समय कहीं और लगाया होता तो बेहतर होता
    • “Programming काफ़ी mature हो गई है” वाला वाक्य ऐसा लगता है जैसे Lisp अतीत में कहीं ठहर गई हो
      Clojure, Clojurescript, Clojure-Dart, Fennel, Jade, Jank, Jolt, Coalton अपेक्षाकृत नई भाषाएँ हैं और आज भी विकसित हो रही हैं। अभी जो तुरंत याद आ रही हैं वे ही इतनी हैं, और भी बहुत हैं
      Lisp एक अर्थ में programming language नहीं, बल्कि एक idea है। इसने आज हम जो लगभग हर programming language इस्तेमाल करते हैं, उसे प्रभावित किया है और अब भी कर रही है। किसी idea की “शांत ढंग से” आलोचना करना मुश्किल है, यह group theory की आलोचना करने जैसा है। हाँ, उस idea के किसी खास implementation के फायदे-नुकसान पर चर्चा की जा सकती है
    • Lisp का शाप: https://www.winestockwebdesign.com/Essays/Lisp_Curse.html
    • आज की भाषा के लिए standardized concurrency बुनियादी शर्त है। CL में standardized async/await या concurrency model नहीं है। standard 1995 के बाद update नहीं हुआ, इसलिए आगे भी ऐसा होने की संभावना नहीं है
    • Lisp में जैसे किसी तरह की पकड़ की दिशा जैसी चीज़ है
      कुछ लोगों को यह मानसिक रूप से आकर्षक लगती है। मैं इसे किसी बेहद niche music genre से तुलना करना चाहूँगा। पसंद करने वाले कम होते हैं, लेकिन वे इसे बेहद तीव्रता से पसंद करते हैं। यह programming जगत का Stockhausen जैसा है
      मूल रूप से यह fandom है। हैरान करने लायक लंबे समय से चल रहा fandom, लेकिन यह कभी व्यापक रूप से breakthrough नहीं कर पाया और आगे भी इसकी संभावना कम है। अब इसकी स्थिति और खराब हो गई है। अगर आपके पास LLMs हैं और code खुद में खास दिलचस्पी नहीं है, तो आप उसे Lisp में लिखने को क्यों कहेंगे?

  • मैं Lisp इतने लंबे समय से कर रहा हूँ कि उसकी features की ठीक से कद्र करना बंद हो गया। फिर जब popular और आर्थिक रूप से कम risk वाली भाषाओं में लोगों को खुद ही अपना नुकसान करते हुए shock और horror के साथ देखता हूँ, तो अचानक फिर से Lisp की value महसूस होती है

  • commercial field में domain-specific language anti-pattern है। कोई कम documentation वाली, सिर्फ खुद को समझ आने वाली domain-specific language बनाकर चला जाता है
    बाद में आने वाले programmers को इस अजीब भाषा को decode करने में जूझना पड़ता है। लगभग हमेशा standard language structures और features इस्तेमाल करना बेहतर होता है। code लिखने से ज़्यादा पढ़ा जाता है

    • हर बार जब आप एक function बनाते हैं, आप उस domain के लिए अपनी खुद की language बना रहे होते हैं
      असल विरोध शायद referential transparency की कमी से होता है। निष्पक्ष रूप से कहें तो Lisp सहित कई भाषाओं में यह समस्या है
    • Lisp में बाद में आने वाले programmers बस macro expansion देख सकते हैं। आधुनिक tools से चाहें तो editor के अंदर, उसी source file के replacement text के रूप में, live Lisp environment से जुड़े हुए भी देख सकते हैं
      इसका अच्छा उदाहरण खुद Common Lisp का LOOP macro है। अगर किसी का usage समझना मुश्किल हो तो Lisp से कह सकते हैं कि इसे ज़्यादा verbose non-LOOP primitive calls में expand कर दे, और LOOP को बिल्कुल समझने की ज़रूरत नहीं। असल में LOOP form को expanded code से replace भी किया जा सकता है
      यह ज़्यादातर दूसरी भाषाओं से एक अहम फर्क है, जहाँ domain-specific language code असल में interpreted data structure होता है

  • Lisps में सचमुच powerful और unique चीज़ें हैं, लेकिन काश ऐसे लेख REPL और hot reloading को बार-बार शामिल न करें
    REPL interpreter languages में, बल्कि कुछ compiled languages में भी, बहुत पहले से basic requirement रहा है। hot reloading न तो unique है और न ही खास तौर पर बहुत व्यापक रूप से इस्तेमाल होती है। इसमें state और patches handle करने पड़ते हैं, इसलिए reasoning आसान रखने के लिए सब कुछ reset करना best practice माना जाता है—इसके पीछे वजह है

    • Clojure सीखते समय मैं भी ऐसा ही सोचता था। काफ़ी बाद में समझ आया कि Lisp लोग जब REPL कहते हैं तो आम तौर पर उनका मतलब commands को आसानी से evaluate करने वाले interactive CLI से कम, और program को live session से जोड़ने की क्षमता से ज़्यादा होता है, ताकि running application के context में text editor के अंदर forms को जल्दी evaluate किया जा सके
      इसलिए दूसरी interpreted languages की तुलना में कहीं ज़्यादा interactive development संभव हो जाता है
    • Dart/Flutter में hot reload बहुत व्यापक रूप से इस्तेमाल होती है। reactive-style framework में UI code लिखते समय, और जब UI rendering ऐसी दिखती है जैसे “हर frame पर नया UI शुरू से बनाया जा रहा हो”, तो क्या reload हो रहा है और क्या नहीं, इसका intuition रखना आसान होता है
      बेशक यह perfect नहीं है। लेकिन user experience को iterate करके सुधारते समय जिस तरह के changes किए जाते हैं, उनके लिए यह बहुत अच्छे से काम करता है
    • मोटे तौर पर सहमत हूँ
      हालांकि यह बात highlight करने लायक है कि hot reloading के advanced हिस्सों का बड़ा भाग Common Lisp में पहले ही handle किया जा चुका था। REPL के बारे में भी यही बात है: यह सीधे typing करने की जगह से ज़्यादा, running image और tools के interaction के लिए एक बहुत powerful interface के रूप में इस्तेमाल होता है
      फिर भी, सिर्फ इनके मौजूद होने से आज ये बहुत खास नहीं रह जाते—इससे सहमत हूँ
    • हर Lisp dialect के पास अच्छी तरह विकसित hot patch system नहीं होता। object-oriented systems को इसके लिए सावधानी से design करना पड़ता है
      अगर class definition reload से replace हो गई लेकिन पुराने instances अभी भी मौजूद हैं, तो क्या करेंगे? Common Lisp dialects के पास ऐसे सवालों के उपयोगी जवाब हैं, लेकिन हर मिलने वाली Lisp में ऐसा होना ज़रूरी नहीं
      Bash भी hot reloading support करता है। मैंने ऐसे modules develop किए हैं जो नीचे की तरह source करके inplace update होते हैं
      $ . /path/to/script.sh
    • आम तौर पर hot patch handling की तकलीफ़ codebase structure और hot patch करने की वजह पर बहुत निर्भर करती है। array-structure architecture या runtime logic error fix हो तो कोई बड़ी बात नहीं
      इसकी usefulness सीमित है, लेकिन अगर आप इस perspective से शुरू करें कि इसे बहुत इस्तेमाल करेंगे, तो वे सीमाएँ काफ़ी जल्दी गायब होने लगती हैं

  • निजी तौर पर मैं इस चरण से आगे निकल चुका हूँ। Common Lisp, Forth, Haskell इस्तेमाल कर चुका हूँ, और 『On Lisp』 व 『Let Over Lambda』 को मज़े से पढ़ा है
    अभी मुझे लगता है कि सबसे अच्छी programming language Barry Jay की Triage Calculus है। यह combinatory logic या untyped lambda calculus के क़रीब है
    लेकिन lambda calculus के उलट, Triage Calculus में Lisp के CAR और CDR जैसी built-in quotation और introspection है, इसलिए type checking आसानी से जोड़ी जा सकती है। इसलिए TC में अगर आप सही abstractions बना लें, तो आप अपनी मनचाही कोई भी syntax रख सकते हैं। यह सचमुच ultimate programming language है
    TC दिखाता है कि programming language features और syntax एक तरफ़, और standard library या user code की function/API definitions दूसरी तरफ़—इनके बीच का भेद एक झूठा द्वंद्व है। जब भी आप reuse के इरादे से code लिखते हैं, आप language में कुछ जोड़ रहे होते हैं। यह सब TC के किसी term के रूप में व्यक्त किया जा सकता है
    syntax पर सारी बहसें आदत का मामला हैं। हालांकि TC में मुझे सच में जो syntax feature चाहिए, वह let over lambda abstraction है, क्योंकि combinators को हाथ से क्रम में लगाना थोड़ा झंझट वाला है

  • अच्छी तरह लिखा गया लेख है
    पहले मुझे लगता था कि किसी दिन सब Lisp इस्तेमाल करेंगे, और जब अच्छे tools और libraries आ जाएँगी तो सब कुछ शानदार हो जाएगा। असल में retirement के बाद मेरी योजना भी यही थी कि इस प्रक्रिया को तेज़ करने के लिए Lisp languages के लिए high-quality libraries बनाऊँ
    क्या AI का उभार इस सपने को खत्म कर देगा? क्या हमने फिर से समस्या का हल बस और ज़्यादा उल्टा-सीधा सामान जोड़कर निकाला है? क्या superintelligent AI सबसे बेहतर संभव programming language में code लिखने के बजाय बस ढेर सारा Python code उगलकर तब तक धक्का लगाएगा जब तक काम न चल जाए?
    पता नहीं यह मायने रखता है या नहीं। मैं बस एक ऐसी दुनिया चाहता था जिसमें elegance हो

    • मैं हमेशा सोचता रहा हूँ कि पहला “Interface Builder” कैसा बनता
      “Jean-Marie Hullot ने INRIA में काम करते हुए Macintosh के लिए Lisp में लिखा ‘SOS Interface’ बनाया था, और वही पहला modern ‘interface builder’ था”
      https://denninginstitute.com/itcore/userinterface/GUIHistory...
      सोचता हूँ, अगर यह NeXT में जाकर Objective-C के साथ इस्तेमाल होने के बजाय mainstream Mac product बन गया होता तो क्या होता
      LISP मेरे लिए अच्छा फिट था। university के comparative languages class में LISP assignments पूरे करने वाला मैं अकेला था, और LISP सीखने से TeX इस्तेमाल करने में भी बहुत मदद मिली
      मेरी चाहत बस इतनी है कि एक अच्छा open-source native या cross-platform GUI toolkit हो, और projects को standalone compiled code के रूप में आसानी से deploy करने का तरीका हो
    • language कभी जवाब नहीं होती। Lisp, Visual Basic से बेहतर नहीं है। दोनों Turing complete हैं
      इंसान दोनों में अच्छे ideas व्यक्त कर सकते हैं। language को tool की तरह सोचना बेहतर है। impact drill, साधारण rotary drill से बेहतर नहीं होती। deck बनाते समय impact drill ज़्यादा सही बैठेगी, लेकिन दोनों काम कर सकती हैं

  • मुझे लगा था कि यह लेख https://web.archive.org/web/20120106121645/http://wiki.alu.o... होगा
    comp.lang.lisp को follow करने की याद आ गई। वह एक तरह का drama भी था। programming magic के साथ-साथ बहुत-से मज़बूत व्यक्तित्व और घटनाएँ भी थीं