This. Python already has most of what made Common Lisp special in the Beating the Averages era. But using it to its full potential isn't "Pythonic", and it gets worse if everyone insists on statically typing everything.
answers (not by me):
[digikar]
Like, wait until Python 3.10 for match, Python 3.13 for GIL-free mode, and perhaps, Python 4 for interactive debugging and saner autoreloads?
[arthurno1]
I am aware what Python can do. Are you aware what you can do with Lisp?
Come back when they have a compiler exposed at runtime, or a just a compiler to machine code to start with :), a multi-threaded runtime, when you can catch and handle exceptions without unwinding the stack, and restarting the program, when you can stop the evaluation on demand and inspect, and manipulate the parsed code without special objects and API and when Python has a simple uniform syntax that makes both parsing and evaluating the code as simple as it is in Lisp.
I don't think it was clear back in time, and probably still isn't, but I think it is mathematically provable that as more features Python, or for that matter Perl, C++, Java etc, gets, the syntactic complexity of the language will grow exponentially, unlike Lisp in which it does not grow exponentially, if at all.
That might sound a bit unorthodox or unfamiliar, but I can try to clarify. In Python, the syntax is complex: "x = 5 + y" is structurally different from "if x: print(y)". The evaluator must natively understand every single one of those distinct structural shapes, assign, if, binary-operation etc. The syntax domain dictating the structure of the internal representation is permanently baked into the evaluator. When you add a new a new syntax feature (like the match/case statement added in Python 3.10), the AST requires new structural nodes. Consequently, the evaluator's source code (CPython) must be explicitly rewritten to understand and execute those new shapes.
In Lisp, the evaluator only needs to understand one shape: the list. (+ 5 y) and (if x (print y)) share the same form, and so does every other Lisp construct: (operator operand1 operand2 .... operandN). If you want to invent a completely new language feature, a custom pattern matching algorithm, as an example, you don't need to update the evaluator or add new object types to the language itself.
A lot of it is due to the 'quote' operator, i.e. you can turn off the evalution, and can request a code in parsed but not evaluated form (the list) and use a macro to translate your custom list structure into the primitive lists the evaluator already knows.
I am perhaps not the best person to explain it, but I suggest this talk. Have patience and see it in the entirety, I think it really falls in place at the end. Probably the best talk, or at least one of the best talks, in computer science I have yet seen.
https://old.reddit.com/r/lisp/comments/1v9bydf/hylang_for_job_rescue/
That's all but that isn't even half the list.
Top comments (0)