Unne wrote:It's a question of Clojure + JVM, or Common Lisp + Windows/Linux/OS X/others + a C compiler. Either way you're tied to and limited by your platform. How many Lisps have threading on Windows right now? How many even work cross-platform at all? How many libraries do? Look at ASDF for a good example of the bad side of using an operating system as your platform rather than a VM. The JVM has a very good compiler and garbage collector; how much time has been spent re-inventing those things for all the various Lisps? They're free in the JVM, and already mature and fast and stable and work on any OS.
Whether Lisps have threading on Windows right now is purely a function of their implementations and whether that's important to them. Remember that many of the Lisps out there are based on very old implementations that have literally been in existence for
decades (CMUCL -> SBCL, KCL -> ECL, MCL -> ClojureCL, etc.). In many cases, the primary implementations were built for Unix which have had very scatter-shot threading support. Put all that together and you have a mess that's going to take a while to work out. Threading support is starting to happen in standard Lisps, but it's admittedly a mess. Nobody screams about this fact more than I do.
A better comparison might be between other dynamic languages like Perl, Python, and Ruby, which all run on Windows with threading today (typically with green threads today, but threads all the same). Given these other languages, I'd just propose that any lack of features on Windows for Lisp is a self-inflicted problem, nothing inherent to not using the JVM as a foundation.
Actually, however, Armed-Bear Common Lisp (ABCL)
does use the JVM.
There are tradeoffs though, yeah. Clojure is tied to a product that's largely under the control of a mega-corp. (Java is open source nowadays, but I would imagine forking Java just to run Clojure on it might be a bit impractical.) But the admittedly nasty loop/recur is a small price to pay for all the benefits of a nice VM, in my opinion. It's not much worse than throw/catch or labelled-block returns in many languages, and in Clojure you could hide loop/recur with macros if you wanted. The JVM may be getting tail-call optimization, in which case Clojure will get it too. Sun seems to be moving to make the JVM better for dynamic languages, so maybe your concerns are more valid in theory theory than in practice. For now.
Actually, I think you have that backwards. The concerns are valid in practice now. There is no debate that Clojure had to compromise functionality and syntax in order to fit within the limitations of the JVM.
If Sun fixes the JVM (and I'm sure they will, but I'm making the point),
then Clojure has the opportunity to fix some of that. Over time, I have no doubt that Clojure will get better, but it will always be subject to the limitations that Sun puts on the system. Whether that's a problem in the long term remains to be seen. Again, I have nothing fundamentally against Clojure or the tradeoffs made in creating it. Indeed, I think it's a splendid piece of work and there is much that Lisps in general can learn from its new and interesting features. The JVM thing just gnaws at me.
Jython and JRuby are bolted on to the JVM as an afterthought, and yeah, they'll never be as popular as the canonical C versions of themselves. They have to go through contortions to get the JVM to work like the C versions. Clojure is designed for the JVM, so it's not competing with itself, and it can work more smoothly and integrate more fully with Java than Jython/JRuby ever could.
So, two things... First, it isn't competing with itself, but it is competing with other Lisps. It will have to distinguish itself to gain long term momentum. Second, it can "work more smoothly and integrate more fully with Java" because it accepts the limitations of the JVM as a given and re-labels them "features." In other words, it's a two-way street on JVM compatibility.
Boiling this down some... Clojure is a (Faustian?) bargain: if you're willing to accept some compromise in functionality to deal with limitations of the JVM, you'll get a language with Lisp syntax that runs the same everywhere the JVM runs and can take advantage of Java libraries. That's it. Whether that excites you or not depends on whether you're cool with that compromise.
All that said, if it was me working in a Java shop and I wanted to slip in a little Lisp, I'd probably reach for Clojure or ABCL to get the job done. That would be an externally-imposed limitation, however. I don't think I'd set that limitation for myself if I had the option.