Ask HN: What's Paul Graham's opinion of Clojure? | Hacker News Reader

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

12 pointsdsrguru5 comments

Paul Graham is one of the biggest advocates of using LISP for web development, and Clojure seems to be the most popular LISP for web development. In fact, since it emphasizes immutable data structures and parallelization, it's even supported by Heroku and will probably get more and more adopters.

I know Paul Graham believes Arc is or will ultimately be the most expressive LISP for web development, but he still writes about Scheme and Common Lisp. I cannot find anything on Google where he discusses his views on Clojure.

So what are they?

View on HN

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.)

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.

"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.

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.

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.

Reply on news.ycombinator.com