Clojure sounds cool, I even read the book and enjoyed it a lot, but at the end of the day it is still tainted by the ugliness of Java. If I learn a completely new language, why not use the opportunity to get rid of Java once and for all?
Arc could be that one language that is not missing anything (once more libraries become available).
Being JVM-based is a feature, not a bug. There's huge amounts of industrial-strength code available in Java, so you completely get around the lack-of-libraries problem. It might not be so hard to write an HTTP library in <lang>, but not having to reimplement support vector machines -- or any thousands of other things -- is a big win. Further, the problem is Java, not the JVM. The JVM is a highly efficient, battle-tested environment. With a de novo runtime, you'll spend the first five years fighting overall stability bugs that are a major distraction from the language itself.
Clojure is a Lisp-1 and attempts to be a purely functional language (I say attempts because it, of course, isn't pure, but encourages you to write functional code by making the alternatives more complicated). There are some problems this just isn't well suited for, i.e., anything highly stateful. Being able to interface with -- without RPC -- Java or Scala components for that part of your application is a big win.
Finally, because Clojure (and Scala, for that matter) coexist with Java in one runtime, it's possible to incrementally introduce the langage to a legacy Java codebase without needing a "rewrite a doom". I've heard stories of Clojure being introduced to a Java application via, "hey, can I use this library for concurrency called Clojure?".
Sure, but with Clojure you still have to use Maven, package imports and so on. Maybe I am just too highly allergic against Java now, it's a personal thing. As soon as you want to use one of the Java libraries, your code starts getting ugly.
Also there seem to be non-JVM environments that come with a sufficient amount of libraries (Python?). I suppose most of them simply interface with C libraries.
The only other comparable standard virtual machines are LLVM and CLR. Python doesn't really make sense in that it's a language, not a VM, and "Python" doesn't automatically connote a runtime like how Java is something of a synonym for the JVM. Incidentally, there is a Clojure port to the CLR. There are also always people working to port it to either LLVM or native code or whatnot and the mainstream community always looks at them oddly wondering what the heck they'd want to throw out Java compatibility for.
java is the most used language right now and using the jvm gets you access to all of that infrastructure. it also makes it really easy to port code to linux, macs, windows, phones, tablets, etc. practicality is one of the stated goals of clojure and the jvm adds a lot of it. aside from the lack of tail-call recursion, it doesn't really bring any real downsides.
on topic: theres no reason that only one can succeed. it's like asking whether linux will beat windows or whether hamburgers will beat hot dogs. they both bring different things to the table and target different people. scala has more common territory and thus more at stake with clojure than arc does. the only thread of commonality between arc and clojure is that they are both lisps and that is hardly the most important thing about either of them.
Other than not minding so much about the JVM thing (even though Clojure.NET is coming along) I find my answer still holds up pretty well after all this time :)
Now, it's pretty obvious that clojure has succeeded, and arc is most likely dead. Paraphrasing Steve Yegge, "Rich Hickey torvalds-ed Arc into obsolescence".
Once Clojure in Clojure gets further along and Clojure becomes even more portable, it'll be even better.
8 comments
[ 4.0 ms ] story [ 38.0 ms ] threadArc could be that one language that is not missing anything (once more libraries become available).
Clojure is a Lisp-1 and attempts to be a purely functional language (I say attempts because it, of course, isn't pure, but encourages you to write functional code by making the alternatives more complicated). There are some problems this just isn't well suited for, i.e., anything highly stateful. Being able to interface with -- without RPC -- Java or Scala components for that part of your application is a big win.
Finally, because Clojure (and Scala, for that matter) coexist with Java in one runtime, it's possible to incrementally introduce the langage to a legacy Java codebase without needing a "rewrite a doom". I've heard stories of Clojure being introduced to a Java application via, "hey, can I use this library for concurrency called Clojure?".
Also there seem to be non-JVM environments that come with a sufficient amount of libraries (Python?). I suppose most of them simply interface with C libraries.
The only other comparable standard virtual machines are LLVM and CLR. Python doesn't really make sense in that it's a language, not a VM, and "Python" doesn't automatically connote a runtime like how Java is something of a synonym for the JVM. Incidentally, there is a Clojure port to the CLR. There are also always people working to port it to either LLVM or native code or whatnot and the mainstream community always looks at them oddly wondering what the heck they'd want to throw out Java compatibility for.
on topic: theres no reason that only one can succeed. it's like asking whether linux will beat windows or whether hamburgers will beat hot dogs. they both bring different things to the table and target different people. scala has more common territory and thus more at stake with clojure than arc does. the only thread of commonality between arc and clojure is that they are both lisps and that is hardly the most important thing about either of them.
Once Clojure in Clojure gets further along and Clojure becomes even more portable, it'll be even better.