Why Clojure over other JVM Lisps: Kawa, Armed Bear

Question

The JVM already had three Lisps before Clojure arrived on the scene: Kawa, Armed Bear and SISC.

What gap does Clojure fill that was left by those Lisps?

Answer 1

The rationale page on clojure.org states:

Why did I write yet another programming language? Basically because I wanted:

• A Lisp
• for Functional Programming
• symbiotic with an established Platform
• designed for Concurrency

and couldn't find one.

Do the 3 languages you mentioned (Kawa, ABCL and SISC) meet these requirements? They are:

• Lisps (either the CL or Scheme dialects) ✓
• for Functional Programming ✓
• symbiotic with an established Platform (the JVM) ✓

but they are not designed for (STM) Concurrency; however, to be fair and complete, there are at least 2 STM libraries I found for CL that have not yet been mentioned:

1. STMX
   • Tested working on ABCL. Under active development.
2. CL-STM
   • Dead? Last change was in 2007.

Hmm... So why create a new Lisp? Mainly because these are libraries. The rationale page on clojure.org continues (emphasis added):

What about the standard Lisps (Common Lisp and Scheme)?

• Slow/no innovation post standardization
• Core data structures mutable, not extensible
• No concurrency in specs
• Good implementations already exist for JVM (ABCL, Kawa, SISC et al)
• Standard Lisps are their own platforms

It is a language concurrency design issue, as others have mentioned.

Furthermore, why stop at the JVM? Clojure CLR support is under active development.

Those are the 2 gaps it fills, from my perspective. You should use Clojure if it meets your needs. Don't worry about losing your skills if Clojure drops off the map. Your Lisp skills, but more importantly your way of thinking, will carry over to other Lisp dialects.

Answer 2

The advantage of Clojure is that it gives you access to all the java libraries/code out there, and multi-threading support because it's based on the JVM. In addition it was designed with concurrency in mind, something not generally designed into lisp, although because of the mapping primitives it probably wouldn't be hard to design a lisp that would support concurrency well.

That being said, I tried Clojure and hated the syntax and the pain in the butt factor that seems to go along with anything Java-connected.

Answer 3

If I were being cynical, I'd say it's because Clojure's got a nicer website and a sexier name.

Answer 4

We don't have to have one more answer (and I don't expect votes for this one), but here are some small enhancements to several other answers.

Newer is not necessarily better. Newer and poorly designed is not good, newer and not maintained is not good, and newer without a larger (or at least growing) user community is not good. (New languages come out regularly, but most of them fall by the wayside because of disuse.)

I love Common Lisp. Part of its beauty is its quirkiness, which comes from the fact that it was designed by committees with a goal of backward compatibility to several incompatible dialects.

I love Scheme. It's a beautiful, elegant language. Nevertheless, its development depends on committees, and perhaps that has slowed it down at times. In any event, its goals are different from Clojure's.

Common Lisp and Scheme have emphases such as tail recursion that are not well-suited to efficiency on the JVM. Clojure was designed from the start to map well onto the JVM, and to interoperate (fairly) well with Java. (I'm not sure what that means about the Clojurescript and CLR dialects.)

The fact that Clojure was developed, initially, by one person, Rich Hickey, and is controlled by him along with a small team, does not necessarily make it better than a language controlled by committees. If that one person made bad decisions, Clojure would not be a good language.

However, and this is the important point: Hickey designed a language that is well thought out, elegant, and that from the start included a systematically related suite of functions that make it easy to do a lot with a little. That goes for the basic JVM interop as well as the rest of the language. The folks who control Clojure continue to be strict about sticking to the language's goals, so far.

This is a big part of what I love about Clojure: It is well designed both as a whole and in its details. That means that once you get used to it, it's a pleasure to program in it.

It would only be a little bit of an overstatement (or understatment?) to say that Clojure has the power of Common Lisp with the elegance of Scheme. Common Lisp has lots and lots of what you need built into the language, but it's a mess (I say that with love), and when you need something more than what's in the language, there are sometimes several incompatible libraries with different tradeoffs. Scheme by design is small, although there are libraries available. Clojure has a growing body of standard libraries (unlike CL) that are more or less parts of the language. A nice illustration of this is the core.matrix project, which provides a common interface to several different matrix implementations. This is important, because there are different matrix implementations that are best for occasional use of small matrices, or for extensive use of huge matrices, for example.

None of this is intended to say that Clojure is better than Common Lisp or Scheme; it's not. The three languages have different virtues.

Answer 5

It's new! Which means not a lot of old lispers will use it since the traditional lisp community is well, traditional, but it also means that people with no previous lisp experience will pick it up as the new thing.

Imho, Clojure is to older Lisps what Ruby was to Smalltalk. Not necessarily better, but good enough. And crucially, it's more acceptable to your employer because it has momentum and is viewed as a language on the rise, much like Ruby once was.

Answer 6

1. "Clojure is a Lisp not constrained by backwards compatibility" (that's from the Clojure website). It's a fresh start. It's progress. Use the ideas that make Lisp/Scheme powerful but rethink them around the Java platform.

2. Clojure will always be the most recent Clojure. With any other language ported to the JVM, the JVM version might always be playing catch-up. If you don't need the Java Platform why use SISC over another Scheme? If you do, why not use the one Lisp (Clojure) that was designed specifically for it?

3. Designed with concurrency in mind.