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?
Kawa, ABCL, and SISC are reimplementations of existing languages that are quite long in the tooth. They are excellent if for some reason you want to use standard Scheme or standard Common Lisp on the JVM.
Clojure is a new language. It doesn't fill a gap. It adds entirely new possibilities. It favors a purely functional approach- Scheme and CL are both multi-paradigm. Clojure borrows heavily from the design of various FP languages (ML, Haskell).
And yes you could add concurrency support to other Lisps, but that's entirely missing the point. Clojure was designed from the very beginning as concurrent language. So much so that writing concurrent programs is trivial in Clojure - not rocket science as it is in non-functional languages (Scheme, CL not excluded). Look at this way:
People say that C lets you write fast programs by default.
Well, Clojure lets you write concurrent programs by default.
"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.
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?
Designed with concurrency in mind.
The most simple answer I can come up with is, Clojure is not Common-Lisp. Clojure is not constrained by the history of other Lisps. It is a new language built for the JVM.
I simply wasn't aware of those, which is a serious benefit for Clojure (that people made enough noise I found out). The biggest thing Clojure has that I didn't see in those you listed is Software Transactional Memory.
Clojure was also designed for the JVM, as opposed to being a layer for another language, so it's a little more "Java-y" that I imagine the others would be when you have to do interoperation.
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:
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.
If I were being cynical, I'd say it's because Clojure's got a nicer website and a sexier name.
I should also add that Clojure is a relatively new language, implemented by one person, with good marketing skills and a lot of energy. He's investing a lot of time and hype into clojure ... sometimes, the hype is a self-fulfilling prophecy in that if you can convince enough people that it's the latest greatest thing, then you can get enough support and momentum to make it actually work.
I suspect the implementers of Kawa etc. don't have as much at stake, hence are not hyping their product. Besides, what's there to hype? "We've got a great language .. it's called Lisp" It's a harder marketing sell.
I think Java is a prime example of this. It had some very serious deficiencies, but because it was marketed and hyped so heavily it achieved a lot of momentum which meant support from hardware/software vendors, producers of tools, investment by industry, etc. Either way, it achieved a certain degree of success, although I hated programming in it. Clojure might achieve a similar success where other Lisps have not.
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.
Clojure is "a lisp", it's not any lisp you already know. I've spent the last couple days reading the material and viewing the videos, and I'm impressed. Its premise is that functional programs (based on immutable data) are the best way to manage concurrency. Clojure implements a lisp-like system based on JVM to provide it.
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.
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.
来源：https://stackoverflow.com/questions/1413390/why-clojure-over-other-jvm-lisps-kawa-armed-bear-or-sisc