Clojure vs other Lisps

The intent of my question is not to start a flame war, but rather to determine in what circumstances each language is "the best tool for the job."

I have read several books on Clojure (Programming Clojure, Practical Clojure, The Joy of Clojure, and the Manning Early Access edition of Clojure in Action), and I think it is a fantastic language. I am currently reading Let Over Lambda which mostly deals with Common Lisp macros, and, it too, is a very interesting language.

I am not a Lisp expert (more of a newbie), but this family of languages fascinates me, as does functional programming, in general.

Advantages of Clojure (and disadvantages of "others"):

• Runs on the JVM.

• The JVM is a very stable, high-performance language environment that pretty well meets Sun's dream of "Write once, run [almost] anywhere". I can write code on my Macbook Pro, compile it into an executable JAR file, and then run it on Linux and Microsoft Windows with little additional testing.

• The (Hotspot, and other) JVM supports high-quality garbage collection and very performant just-in-time compilation and optimization. Where just a few years ago, I wrote everything that had to run fast in C, now I do not hesitate to do so in Java.

• Standard, simple, multithreading model. Does Common Lisp have a standard multithreading package?

• Breaks up the monotony of all those parentheses with [], {}, and #{}, although Common Lisp experts will probably tell me that with reader macros, you can add those to CL.

Disadvantages of Clojure:

• Runs on the JVM.
• No tail recursion or continuations. Does Common Lisp support continuations? Scheme requires support for both, I believe.

Advantages of Others (Common Lisp, in particular) (and disadvantages of Clojure):

• User-definable reader macros.

• Other advantages?

Thoughts? Other differences?

My personal list of reasons for preferring Clojure to other Lisps (p.s. I still think all Lisps are great!):

• Runs on the JVM - hence gets automatic access to the fantastic engineering in the JVM itself (advanced garbage collection algorithms, HotSpot JIT optimisation etc.)

• Very good Java interoperability - provides compatibility with the huge range of libraries in the Java/JVM language ecosystem. I have used Clojure as a "glue" language to connect different Java libraries with good effect. As I also develop a lot of Java code it is helpful for me that Clojure integrates well with Java tooling (e.g. I use Maven, Eclipse with Counterclockwise plugin for my Clojure development)

• Nice syntax for vectors [1 2 3], maps {:bob 10, :jane 15} and sets #{"a" "b" "c"} - I consider these pretty essential tools for modern programming (in addition to lists of course!)

• I personally like the use of square brackets for binding forms: e.g. (defn foo [a b] (+ a b)) - I think it makes code a bit clearer to read.

• Emphasis on lazy, functional programming with persistent, immutable data structures - in particular all the core Clojure library is designed to support this by default

• Excellent STM implementation for multi-core concurrency. I believe Clojure has the best concurrency story of any language at the moment (see this video for more elaboration by Rich Hickey himself)

• It's a Lisp-1 (like Scheme), which I personally prefer (I think in a functional language it makes sense to keep functions and data in the same namespace)

An important difference between Clojure and Common Lisp is that Clojure is more prescriptive about functional programming. Clojure's philosophy, idioms, and to some degree language/libraries strongly encourage and sometimes insist that you program in a functional way (no side effects, no mutable state).

Common Lisp definitely supports functional programming, but it also allows mutable state and imperative programming.

Of course, there are a number of benefits to functional programming, in the area of concurrency and otherwise. But all else being equal, it is also good to have the choice of which approach you want to use for each situation. Clojure doesn't completely prohibit imperative programming, but it is less accommodating of that style than Common Lisp.

Keep in mind that Clojure is a language and an implementation (usually on the JVM). Common Lisp is a language with more than ten different implementations. So we have a category mismatch right here. You might for example compare Clojure with SBCL.

Generally:

• a version of Common Lisp runs on the JVM: ABCL

• most other Common Lisp implementation don't

• most CL implementations have multitasking capabilities, a library provides a common interface

• Common Lisp has syntax for arrays. Syntax for other data types can be written by the user and are provided by various libraries.

• Common Lisp supports neither tail call optimization nor continuations. Implementations provide TCO and libraries provide some form of continuations.

Here's a good video with a comparison of Scheme (Racket mostly) and Clojure.

To be fair, Racket has syntax sugar (additional reader stuff) for data types too (#hash, #, square brackets, etc.)

Plus, Clojure's only way to make a proper tail call is to use recur, that's the downside of compiling to JVM.

> Note that recur is the only non-stack-consuming looping construct in Clojure. There is no tail-call > optimization and the use of self-calls for looping of unknown bounds is discouraged. recur is > functional and its use in tail-position is verified by the compiler. (Special Forms).