Common Lisp is all about choices and flexibility. Do you want pattern matching? You can get it but it's not shoved down your throat. Same for STM. Same for immutable data structures. Same for Java interop.
On the other hand, Clojure is lacking fundamental features of Common Lisp that are extremely powerful: conditions & restarts, programmable debugger, programmable reader, programmable compiler through compiler macros, dumping images & native code compilation not to mention advanced code analysis and optimization capabilities.
The JVM allows you to use a ton of libraries, on a very performant platform. CL libraries just aren't anywhere near as feature-complete as in more popular languages, and this matters when you actually need to be productive. I don't have time to reinvent the wheel constantly. This practicality is what motivated Clojure in the first place, and why it is far and away the most popular lisp.
As an example of metalinguistic abstraction, some of the tasks I've successfully deployed Common Lisp at include creating a high-performance network stack that runs on ARMv8 and is based on JIT compilation and an entire assortment of solutions that sit on opposite ends of the highlevel-lowlevel spectrum. Concepts such as tight control over memory, stack allocation and one-to-one mapping with generated instructions were critical. Common Lisp allowed me not only to successfully investigate the domain but also to use the resulting code in production. For these tasks, Clojure would have been a total miss both due to implementation decisions (JVM) and its constraining nature -- in this case, immutability, memory and compilation model -- not allowing me to come up with a 'language' that will let me think the right thoughts.
What’s your definition of popularity when you say that Clojure “is by far and away the most popular lisp”?
https://redmonk.com/sogrady/2018/03/07/language-rankings-1-1...
1. Excellent syntax and library support. It is my first Lisp, but I can't how I programmed without macros and persistent data structures.
2. I hate the stack traces. I've used both Clojure and Clojurescript (mainly cljs), and the stack traces for errors are nearly indecipherable. To be fair I am using React (not Reagent), but I don't find it too much better with other libraries.
3. I hate the build system. It is fractured and there are too many mediocre options. shadow-cljs is the best one I've used, and it works okay not great. I also hate that I can't distribute standalone binaries. I have used pkg, which distributes Node project as binaries, but the binaries are huge (something like 85MB+)
4. The core functional language is excellent, but protocols, types etc. seem much more ad-hoc and not well-designed. I'm used to object oriented (Python) and I find the lack of focus on an object-system a bit unsettling.
I have no clue if Common Lisp fixes these issues or brings new ones.
The real killer superpowers come from extend-type and extend-protocol. You can modify existing java/clojure libraries functionality like magic. The functional equivalent is with-binding if I remember correctly.
Some Clojure libraries use protocols heavily and IMHO not just necessary.
I guess CLOS was well designed.
What Clojure offers is a subset of CLOS.
Stack traces are already the wrong approach. Error handling is first. Stack traces may serve some purpose, but are secondary. Common Lisp was designed for interactive error handling.
An example. Let's say we have a function FAK and it returns the wrong result "0" for 0.
CL-USER 21 > (defun fak (n)
(if (zerop n)
"0"
(* n (fak (1- n)))))
FAK
CL-USER 22 > (fak 10)
Error: In * of (1 "0") arguments should be of type NUMBER.
1 (continue) Return a value to use.
2 Supply a new second argument.
3 (abort) Return to top loop level 0.
Type :b for backtrace or :c <option number> to proceed.
Type :bug-form "<subject>" for a bug report template or :? for other options.
But we also get another REPL, but this time one level down and the original REPL is still there, one level up. This means we can do some computations in the error REPL:
CL-USER 23 : 1 > (fak 0)
"0"
CL-USER 24 : 1 > (fak 1)
Error: In * of (1 "0") arguments should be of type NUMBER.
1 (continue) Return a value to use.
2 Supply a new second argument.
3 (abort) return to debug level 1.
4 Return a value to use.
5 Supply a new second argument.
6 Return to top loop level 0.
Type :b for backtrace or :c <option number> to proceed.
Type :bug-form "<subject>" for a bug report template or :? for other options.
So we decide to go one error level up and explore the problem there further. :c 3 chooses the restart to go to debug level 1.
CL-USER 25 : 2 > :c 3
CL-USER 26 : 1 > :c 1
Supply a form to be evaluated and used: 1
3628800
Sure we can also get a stack trace - but the stacktrace is active in the context of the error - it's now a post-error stack trace - it's an in-error stack trace. Means we can, while we are in the error, see the stack trace and use it: change variables, restart start frames, return from stack frames, set break points to stack frames, ...
Let's say we are in the error again. Let's get a quick backtrace:
CL-USER 58 : 1 > :bq
ERROR <- * <- FAK <- FAK <- FAK <- FAK <- FAK <- FAK <- FAK <- FAK <- FAK <- FAK <- EVAL
<- CAPI::CAPI-TOP-LEVEL-FUNCTION <- CAPI::INTERACTIVE-PANE-TOP-LOOP <- MP::PROCESS-SG-FUNCTION
CL-USER 59 : 1 > :n
Call to *
CL-USER 60 : 1 > :n
Interpreted call to FAK
CL-USER 61 : 1 > :n
Interpreted call to FAK
CL-USER 62 : 1 > :v
Interpreted call to FAK:
N : 2
CL-USER 63 : 1 > :ret 2
3628800
There are lots of ways to work with a stack trace while we are in the error - the display of the stack trace is only a minor feature.
I even have a good example to illustrate this. A while back someone had emailed me because he was trying to implement a terrain generation algorithm called Diamond Square, which I had written a blog post about. It was mostly working, but would crash with an IndexOutOfRangeException at one point. He had tried debugging it and emailed me to see if I could point him in the right direction.
Getting an array out of bounds exception didn't surprise me, because in Diamond Square the algorithm will try to read outside of the bounds of the array by default -- part of implementing the algorithm correctly is detecting that case and making sure to handle it, either by just ignoring that cell or by wrapping it around to the other side of the array. So I assumed he had just forgotten to do this. But then I read his code, and no, he had definitely added a check for `if (x >= array.length)`.
This code was using Unity, so it was written in C#, but the point applies to most languages. Look at the errors given back by C# and Clojure for this problem:
user=> (nth [:a :b :c] x)
IndexOutOfBoundsException clojure.lang.PersistentVector.arrayFor (PersistentVector.java:153)
float[] fs = new float[5];
Console.WriteLine(fs[x]);
Unhandled Exception:
System.IndexOutOfRangeException: Index was outside the bounds of the array.
at MainClass.Main (System.String[] args) [0x00009] in <fdc0f271de194e269b9b6c61b644f47b>:0
[SBCL] CL-USER> (aref #(:a :b :c) *x*)
debugger invoked on a SB-INT:INVALID-ARRAY-INDEX-ERROR in thread
#<THREAD "main thread" RUNNING {10005505B3}>:
Invalid index -1 for (SIMPLE-VECTOR 3), should be a non-negative integer below 3.
If I had been able to get this running in a debugger I probably could have figured it out, sure. But Common Lisp's nice error messages made that unnecessary -- instead of telling me "You tried to access an invalid index" it says "You tried to access X, but I was expecting Y". It's so much nicer, and in a lot of cases (like this one) instantly makes the error completely obvious.
I don't know exactly why Common Lisp's error messages tend to be so much better than most other dynamic languages. Maybe it's a culture of good error writing from the very start. Maybe it's because the language itself makes it easy to provide good messages, thanks to things like CHECK-TYPE, ECASE, ETYPECASE, etc (and their `C` variants, which is a whole extra layer of goodness on top of all that). I don't know. I just know that hitting an error in most languages feels like hitting a brick wall (especially in JVM languages, good god are those stack traces awful) but in Common Lisp it feels like the system is at least trying to do its best to help me.
With (JVM) Clojure, leiningen has to be 90+% of the Clojure projects in the wild. And in that world, the equivalent to a native binary is an uberjar, which is rather easy and pretty much standardized.
The stack traces could be improved though.
Maybe I worded wrongly the first time. I definitely didn't mean to imply that Common Lisp can't do something. That would be as foolish as saying Emacs can't do something ;)
I was just pointing out that we aren't comparing like-with-like once you bring in a totally different ecosystem such as JavaScript's (which is historically neither Common Lisp's nor Clojure's main focus).
Not often. In Common Lisp I don't have to use them.