Ask HN: What's Paul Graham's opinion of Clojure?

kinleyd · on March 11, 2012

pg on an Arc FAQ: Why not build Arc on top of Java/Parrot/.NET?

We're trying to make something for the long term in Arc, something that will be useful to people in, say, 100 years. (If that sounds crazy, remember that we're already up to 50.) So (a) we're not in a hurry to save effort; when you're trying to make something that will last 100 years, there is plenty of time to work on it, and (b) we don't want to adhere to anything that isn't timeless, lest the whole project curl up like a bimetallic strip. (http://paulgraham.com/arcfaq.html)

If I read it correctly, according to pg JVM isn't timeless, and Clojure is at risk of curling up like a bimetallic strip. :) (For the record, I believe Rich Hickey is a genius and his recently released Datomic is ground-breaking. Clojure is pretty good too, but just a trite top heavy with Java/JVM.)

dsrguru · on March 11, 2012

But the JVM is just Clojure's underlying implementation. Or technically one of two. That can change in the future. I believe Arc's underlying implementation is pre-Racket PLT Scheme, which is already out of date, but that doesn't mean Arc itself can't exist in 100 years.

I think Clojure's reliance on the JVM was more to facilitate its initial adoption (release early and often rather than once you've written and tested thousands of libraries) rather than a permanent language feature. So assuming pg agrees that Clojure is unlikely to curl up like a bimetallic strip even if and when the JVM loses popularity, I wonder what his view on using it at the present is.

kinleyd · on March 11, 2012

"But the JVM is just Clojure's underlying implementation. Or technically one of two."

Yes, the CLR is the other half. Hmm, just trying to reassess this myself: While playing with Clojure, I found I had to use the Java libraries for basic stuff like file i/o (at least that is what all the examples pointed me to). I'd have been much happier playing with native Clojure libraries for things like that as I found the syntax became really unLisp like. I'm hoping I missed something, and that there are in fact ways to avoid the Java libraries when you want to. In which case I'd agree that "JVM is just Clojure's underlying implementation" and might in fact take another stab at Clojure.

dsrguru · on March 11, 2012

I'm new to Clojure as well, so I don't know if there's a native way to perform normal I/O. The cleverly named article at http://copperthoughts.com/p/clojure-io-p1 is over a year old, so I don't know if things have changed, but it suggests that besides the slurp function (which appears as impractical from a memory standpoint as the Perl equivalent), you really do need to dip into Java for I/O.

Assuming it's just a matter of time before I/O and all other common tasks in Clojure are done in native Clojure, it really seems like a contender for the pg "hundred year language." It has lots of default macro shortcuts for common tasks and really seems to prefer abstracting away redundancy to following tradition. It even uses the Arc-style let macro instead of the paren-happy one found in Scheme and CL. It also makes concurrency almost as simple as pg's "Bring Back Moore's Law" startup idea. And it's also well suited to web applications. The more I think about, the more it really does seem to be the Arc that's already here.

kls · on March 12, 2012

While it is not a totally Clojure native IO lib, there is clojure.java.io http://richhickey.github.com/clojure/clojure.java.io-api.htm... which gives you more LISP like syntax when dealing with common IO functions. That being said, it is just wrapping much of the same stuff you would do with the Java libs directly.