"A Programmer's Guide to Common Lisp" पढ़ना
Common Lisp के उत्साही लोग इस पर विचार करते हैं कि भाषा को कैसे सीखा जाए और उसमें उत्पादक तरीके से कैसे काम किया जाए, line-oriented REPL की तुलना IPython जैसे टूल्स से करते हुए Emacs+SLIME, Vim+VLIME, या यहाँ तक कि Jupyter-आधारित setups जैसे editor-integrated environments की सिफारिश करते हैं। बातचीत का बड़ा हिस्सा Lisp के explicit scoping और binding constructs (जैसे `let` बनाम `let*`) पर केंद्रित है, जिन्हें कुछ लोग reasoning और metaprogramming के लिए शक्तिशाली मानते हैं, जबकि अन्य उन्हें ऐतिहासिक बोझ मानते हैं जो adoption को कठिन बनाता है। tooling और language design के साथ-साथ, प्रतिभागी पुराने Lisp और programming books तथा Medley जैसे classic Lisp machine environments की भी सराहना करते हैं, जिन्हें symbolic computation को समझने के लिए अनोखे रूप से coherent और self-contained तरीकों के रूप में देखा जाता है.
Common Lisp REPL और Iterative Workflow
- कई टिप्पणीकारों को CL REPL, विशेषकर multiline snippets और history editing के मामले में, IPython की तुलना में awkward लगते हैं।
- अनुभवी उपयोगकर्ता कहते हैं कि “सही” तरीका bare terminal REPL में टाइप करना नहीं, बल्कि editor-integrated REPL (“listener”) का उपयोग करना है।
- Emacs+SLIME या Vim+Slimv/Vlime में आप code को buffer में लिखते हैं और keybindings के ज़रिए expressions, regions, या forms को REPL में भेजते हैं। इससे multiline evaluation और line-based history पर निर्भर हुए बिना आसान re‑evaluation मिलती है।
- CL REPL expression-based होते हैं, line-based नहीं; कई sequential expressions के लिए आप उन्हें
prognयाletमें wrap कर सकते हैं ताकि वह एक single form बन जाए जिसे edit करके फिर से run किया जा सके। - कुछ implementations या add-ons (readline के साथ CLISP, rlwrap, linedit, CL के लिए Jupyter kernels) अधिक IPython-जैसी line history देते हैं, लेकिन ज़्यादातर ध्यान editor integration पर ही रहता है।
Variable Binding, Scope, और let vs let*
- एक लंबा subthread इस बात पर बहस करता है कि CL “declare variable anywhere” syntax जैसे
var x = yके बजायlet/let*जैसे forms क्यों उपयोग करता है। - समर्थकों का तर्क है कि explicit scoping एक feature है: bindings स्थानीय होती हैं, reasoning आसान होती है, और macros तथा metaprogramming के लिए अधिक अनुकूल होती हैं।
letlambda parameter binding के समानांतर है;let*sequential dependencies को व्यक्त करता है। - आलोचकों को यह distinction confusing और C‑style भाषाओं या Schemes की तुलना में non-idiomatic लगता है, जहाँ blocks के भीतर
defineकी अनुमति होती है; उनका कहना है कि इससे अतिरिक्त nesting बनती है और readability प्रभावित होती है। - अन्य लोग नोट करते हैं कि कई non-C भाषाओं में भी historically scopes के top पर declarations आवश्यक थीं; “अब ज़्यादातर भाषाएँ क्या करती हैं” वाली दलीलों पर सवाल उठाए जाते हैं।
- विभिन्न macros (
nest, block-like macros जोvarको nestedlets में rewrite करते हैं, TXR Lisp constructs) को core language बदले बिना alternative syntactic styles पाने के तरीकों के रूप में उल्लेख किया गया है। - ऐतिहासिक संदर्भ:
letबाद में lambda पर sugar के रूप में आया;let*और भी बाद में आया, और naming काफी हद तक legacy है, न कि कोई ताज़ा redesign।
Books, Documentation Style, और Lisp सीखना
- टिप्पणीकार पुराने technical books (Lisp और AWK texts सहित) की self-contained, linearly organized शैली और लगातार web lookup पर निर्भर न होने के लिए प्रशंसा करते हैं।
- कई लोग पुराने manuals और language books को उनके perspective, style, और “snapshot in time” feel के लिए पढ़ना पसंद करते हैं।
- Lisp सीखने के लिए जिन paths का उल्लेख किया गया है उनमें beginner-friendly intros और AI-focused Common Lisp books शामिल हैं।
- कुछ लोग पुराने, stable platforms (DOS, early Windows, classic Lisp systems) की तुलना modern, web-only, fragmented documentation से करते हैं, जिसे linear रूप से navigate करना कठिन है।
Lisp Machines, Medley, और संबंधित Systems
- कुछ लोगों को Medley/Interlisp एक self-contained Lisp-machine-style environment के रूप में पसंद है, हालांकि अन्य modern CL implementations के साथ Emacs या commercial IDEs को प्राथमिकता देते हैं।
- Mathematica को कुछ हद तक Lisp-like feel और एक विशाल built-in library वाला बताया गया है, लेकिन उसके goals और implementation Lisp-machine systems से अलग हैं।