Clojure is great if you happen to be tied to the JVM. It is fantastic to have something usable on such an environment. However, outside that environment there is little advantage compared to Common Lisp, since Clojure drags this huge piece of crap that is the JVM. I would much prefer to have libraries in the Python style -- that is, being able to connect to real, native object code in several architectures.
Clojure drags this huge piece of crap that is the JVM
What about the huge piece of crap that is the GIL? I mean come on. Clojure is a good reason to care about the JVM. I'd completely given up on the JVM until Clojure landed since there was no great way to tap into it's power without adopting Java's problems. The JVM rocks.
Many of the problems of Java are inherited from the JVM: poor performance compared to native code, long load times, funky classpath issues. Hell, Java could even be a better language if it didn't require a JVM (this is probably what the Android guys think, too). I don't see why a Lisp needs to use it, if is not for compatibility with existing Java code.
The performance of the JVM is phenomenally good with any modern implementation. The only issue remaining is the relatively poor loading time of the JVM. Hence, short tasks/scripts make little sense to run because the overhead of the startup overshadows the performance of the JVM.
But for long-running applications, the performance is very good, and the time it takes to load doesn't really matter. The startup time mostly effects the programmer, who has to start it up to debug the system so often. Clojure sort of mitigates this by having a REPL where you can do testing/debugging without restarting the JVM every time.
This is the official truth, and I agree that it must be true when you talk about benchmarks. But there is not application written in Java that I know of that runs faster than a similar application written in C/C++.
All the Java applications that I am required to run are slow, and when they perform well it is because they are using 10x the hardware required by a comparable C++ application.
Of course, if you are creating a network-bound application this doesn't matter much (I can even use Python or Perl for that), but when you want reasonable performance (e.g., on desktop applications), this idea shows to be completely wrong.
It's unfair to compare JVM performance with that of C/C++ ones. Given the kind of high-level language that Clojure is, it doesn't matter if it's slightly slow than a C program.
Today, developer time is more expensive than CPU time.
Those aren't problems with Java, they are (respectively) something that isn't important in many cases (and not even always true), something that is really only bothersome for short-running scripts, and a severe annoyance that can nonetheless be overcome fairly easily. There are plenty of reasons for a Lisp, or any language for that matter, to use it - a highly developed GC and JIT compilation capability that you don't have to write and maintain yourself not least among them. And the massive array of existing libraries that already run on the platform is not a negligible benefit in the least.
When will I stop hearing this story about "poor Java performance compared to native code"?
Just look at the shootout results, where Java is as fast as fastest native code compilers and and an order of magnitude faster then all other lisps there.
Java was about, dragging the C++ programmers half way towards Lisp. Maybe Clojure is about moving them further up to 90%... (and the last 10% is the JRE)!
JVM may be crap (or not), but it is widely deployed. In other words, widely available.
And performance is not that bad, really. Except for the startup time, it is better than most other languages, not just scripting languages. There has been a lot of effort invested in making JVM better.
