a little madness

Last Thursday I rolled up to a London Java Community talk by Rich Hickey, the creator of Clojure. Rich was in town for QCon, but was good enough to do an extra talk for those of us not attending the conference — thanks Rich.

The talk, entitled “Clojure for Java Developers” was polished and interesting. Rich is a good speaker and clearly articulates the motivations behind Clojure, as well as giving a basic feature overview. In a nutshell, Clojure is a Lisp for the JVM with tight Java integration and a strong functional bias. I won’t go over all the basics here: for that you’re better of heading to the Clojure website. I did, however, take a few notes on what I found to be the more interesting aspects of the talk:

• Rich made a distinction between languages ported to the JVM (e.g. Jython, JRuby) and those designed for the JVM like Clojure. The idea is that Clojure is designed to work in the hosted environment, and has native support for, e.g. calling Java.
• A key reason for building a lisp-like language is the fact that the language itself can all be built on a very small number of primitive constructs (I believe it could be as few as 7).
• Clojure has native syntax for lists, maps and vectors (unlike many lisps in which only lists are distinguished). These are each built on a simple sequence abstraction with only 3 operations: seq, first, and rest. By it’s nature this abstraction allows sequences to be lazy.
• The built in data structures are all immutable, to enable a functional style of dealing with concurrency. To allow for efficient manipulation, they are all backed be a tree representation, which cuts down on the amount of data that must be copied to create a modified version of a structure. I presume the trees are all balanced to keep depth at O(log n), meaning only O(log n) nodes need to be copied on a change.
• Rich emphasised the point of treating aggregate structures as unchanging values so that they may be shared among threads without locking. Building efficient support for immutable structures is key to enabling this style.
• On top of the immutable data structures, Clojure also natively supports Software Transactional Memory (STM). Instead of changing data structures directly, threads share indirect references that point to immutable structures. Within a (language-supported) transaction you can produce a new version of a structure and on commit the shared reference is updated to point to your new version.

With the interest in dynamic languages continuing, people would do well to consider Clojure. After all, once you’ve gone dynamic, why not go all the way to Lisp — the most famously-extensible language family?