A couple nights ago I walked down to LispNYC in the East Village to hear Rich Hickey talk about Clojure, his new Lisp-like language. To be honest, I wasn’t expecting much. Another Lisp? Ho hum. I’m sure it’s very clever and cool and all, but not something I can actually use.
Instead, I was blown away by Rich’s presentation. Clojure might just be the Lisp I’ve been waiting for. Here’s why:
- Clojure targets the JVM. That doesn’t just mean it’s written in Java. It compiles directly to Java bytecode, so it can take advantage of all the optimization work that’s been done on just-in-time bytecode compilers. So it’s both fast and portable.
- Clojure is functional, i.e. “side-effect free.” The built-in data structures are immutable. At the same time, you can have side effects (via external Java calls) without needing monads.
- Clojure has modern data structures. Vectors and hash maps are built in, and both can be used as “functions” that take a key value as their argument (I immediately thought yes, that’s the way it should be).
- Clojure fits into the Java ecosystem. All squintillion Java library methods can be called directly from Clojure. (Hickey demonstrated a small Swing app with fewer lines than the Java version.) Clojure data structures implement the Java collection interfaces.
- Clojure has built-in concurrency support. I barely understand this, but Hickey has done his homework and built a sophisticated concurrency and transaction system right into the language.
- Clojure abstracts Lisp sequences. Standard functions like “map” and “filter” work on any sequence, not just lists. In fact, they work on any object that implements the Java “Iterable” interface.
- Clojure has metadata. Objects can have metadata attached to them, which can be used by the program without affecting the value of the data (e.g. two objects with identical contents but different metadata are still considered “equal”).
- Clojure is still Lisp! It has first-class functions, Common Lisp-style macros (with automatic gensyms), a reader, “eval”, and a REPL.
I haven’t been this excited about Lisp since Peter Seibel came to talk about Practical Common Lisp. Hickey’s full presentation should show up soon at LispNYC.org. There’s also a (beautiful) Clojure web site and a Google group.
Update Nov. 21: Audio and slides from the presentation are available at LispNYC.
[…] Sierra heard the talk in person and has a great overview on his […]
I always welcome new Lisps, and Clojure seems to have some nice properties, however there are couple showstoppers:
– while you may think java vm is a great think, it’s not. when you do some java threaded server software, you will find out that java VM is quite unpredictable, sometimes giving delays for dozens of milliseconds in the executing context of the thread for no reason
– Clojure’s concurrency model ala ‘transactions’ is broken. Might work fine on 2-4 cores CPU. When we will have CPUs having 8 and more cores, centralized approach to concurrency like locks, transactions, ‘lockless’ data structures (where your lock is ‘lock’ instruction) will break. The only right way to model concurrency is the way Erlang does it. And forget about that using crappy java vm
Well md, the thing is that there are projects out there that are doomed to be Java projects. In such an environment, the availability of a sophisticated higher-level language like Clojure is a really nice thing. I suspect that the large Java OLTP application I’m most familiar with isn’t much different than others like it, and I can imagine a good deal of the Java code at certain layers being replaced by Clojure.
I don’t mean to suggest that Clojure should not be a potential choice as a primary implementation language. I really don’t feel I can offer a respectable opinion on that. All I can say is that from what I’ve seen, Clojure has a lot going for it compared to Javascript (Rhino), Groovy, or JRuby.
[…] On Clojure I haven’t been this excited about Lisp since Peter Seibel came to talk about Practical Common Lisp. […]
md, it’s a matter of right tool for the job. STM is great for some problems. Just because you have N cores doesn’t mean you have N processes contending for the exact same data. Many multithreaded apps have occasional interaction with small, but potentially overlapping sets of shared data. STM makes doing the right thing easy and scalable. Doing a real transaction, i.e. read x from here, modify it, put it there without it being in both places, or no place, or changed by anything else, is very cumbersome (impossible?) in a pure asynchronous message passing system (cf Mnesia, which does plenty of locking: http://www.erlang.org/doc/apps/mnesia/Mnesia_chap4.html#4). Of course there are also merits to asynchronous concurrency systems and Clojure has that too, in its Agents (http://clojure.sourceforge.net/reference/agents.html), a slightly different take on actors (Erlang’s model).
Erlang is very cool and Clojure is not designed to compete with it, but saying there is only one way, or presuming that a specific method will not work for an unspecified class of problems, is unproductive. Sorry you don’t like the JVM, but I find it pretty impressive, even if not suitable for all problems.
[…] A new Lisp WTA. A link to the talk presenting Clojure. The website for Clojure. […]
[…] I didn’t make it clear in my first post about Clojure, I like this language. Here’s some more reasons […]
[…] On Clojure<br/> I haven’t been this excited about Lisp since Peter Seibel came to talk about Practical Common Lisp. […]
In 2007, md said: “Clojure’s concurrency model ala ‘transactions’ is broken. Might work fine on 2-4 cores CPU. When we will have CPUs having 8 and more cores, centralized approach to concurrency like locks, transactions, ‘lockless’ data structures (where your lock is ‘lock’ instruction) will break. The only right way to model concurrency is the way Erlang does it. And forget about that using crappy java vm”
Well, it’s 2010, and Clojure has been run on systems with dozens (hundreds?) of CPUs, and gets good CPU utilization and throughput there. Clojure has problems, and the JVM has problems, but its concurrency model hasn’t shown itself to be a showstopper just yet.