It’s not a recognized term, hence the air-quotes. The terms “Lisp 1” and “Lisp 2” do describe concrete implementations of Lisp (1 keeps functions and data in se

It’s not a recognized term, hence the air-quotes. The terms “Lisp 1” and “Lisp 2” do describe concrete implementations of Lisp (1 keeps functions and data in separate namespaces; 2 puts everything in a single namespace). Many consider Lisp-2 an improvement over Lisp-1, in that it eliminates complexity and improves consistency and uniformity of behavior. However, as even some Lispers will admit, Lisp itself is not a good Lisp. Just like the Algols, Lisp 1s & 2s are riddled with special forms (they just hide them better). e.g. You can’t implement your own conditional operator in Lisp that replicates the behavior of Lisp’s built-in `if` operator, because `if` requires that its second and third operands be lazily evaluated, and Lisp itself always evaluates operands eagerly. Thus that special-case lazy evaluation behavior is hardcoded into Lisp’s core for just that operator. However, there’s also a great saying (coined by Pythonistas, not Lispers, ironically) that “Special cases aren't special enough [to break the rules].” And indeed, with just a little bit more thought and effort, all those special cases wired into Lisp’s core can be completely eliminated and replaced with a single general-purpose compositional mechanism that works the same for everything and can be used by anyone. That’s what Schutt’s Kernel does (my own Lisp-inspired kiwi language also solves it, albeit in a different way): it allows procedure writers to control exactly how and when/if each argument to that procedure should be evaluated. In the spirit of Lisp 1s ands Lisp 2s I’d describe Kernel-like languages as “Lisp 3s”, in that a single fundamental change to the core language improves its simplicity, consistency, and uniformity. What’s really significant though is that it vastly improves language plasticity, i.e. the ability to reshape bog-standard Lisp into whatever custom language best expresses the concepts and behaviors specific to your problem space. We talk a lot in software development about managing complexity, and indeed this is important. But the one thing that’s even better than managing complexity well is eliminating it entirely. Lisp culture gets plenty castles-in-the-sky brainfarts of its own, natch, but at least the Lisp philosophy offers the opportunity in a way the Algols never will. It’s the question every Lisp asks, all the way back to McCarthy: How simple can/should computation be? (Answer: A lot simpler than we think!) And then, having arrived at the answer to that, figure how to simplify it even further. Now, if only someone could find a solution to all those Irritating Stupid Parentheses… ;)