if by limited we mean full ecosystem compatibility with jvm and javascript, then yes, Clojure is limited. Which 40 year old CL codebase is it that i am trying to run?
The decisions behind Clojure worked out well for Rich Hickey and his consultancy but they don't fit the programs that I find myself writing all the time (compilers, assemblers, virtual machines, tight control of code generation and memory operations and so on). I can do all of that - and more - in SBCL and it's a pleasure to use as the I don't have to bend myself to work around language shortcomings. Common Lisp gives me a multitude of programming paradigms and an enormous arsenal of approaches to use. When working in exploratory domains, that I do all the time, nothing else comes close. Here is an example of using SBCL for exploratory lowlevel programming by Paul Khuong [1].
I've written performant and lightweight TCP/IP network stacks in Common Lisp.
Clojure is just too constrained.
As far as old Lisp code goes, it's everywhere - if you care to look -. The lambda papers, McCarthy's original papers, the CMU CL repository (still of practical use today), vast archives of Lisp code from MIT and so on and so forth. Not to mention useful frameworks like Screamer [2] which is close to 30 years old and Maxima [3] which is even older.
> if by limited we mean full ecosystem compatibility with jvm and javascript, then yes, Clojure is limited.
I don't think that was he meant. Probably he meant that Clojure took a bunch of things from Lisp, but there is a lot in Lisp, which is not in Clojure - for example because of the limitations of the JVM eco-system (for example creating an executable image in SBCL of a running Lisp is an easy task, whereas in Clojure it involves a complex & slow machinery like GraalVM) or design limitations imposed by its developers (like a compiler written in Java and no interpreter) - plus it seems not to be an open language design - more or less the language is driven by a single company listening to its community and sometimes not.
