Clojure is rather new member of the LISP family of languages which runs on the Java platform. Introduced in 2007 it has already garnered a lot of interest. One reason is Clojure's approach to concurrency which is built upon the concepts of Software Transactional Memory (STM).
Stuart Halloway is the author of "Programming Clojure" (published by the Pragmatic Programmers), which is now in beta. We talked to Stuart about Clojure, STM, tooling and more.
InfoQ: Clojure uses STM to help with concurrency; what's your elevator explanation/elevator pitch for STM?
STM is one part of a bigger story: explicit APIs for mutable state. By dividing your code into pure functional and mutable layers, you get two enormous advantages:
* your pure functional code is much easier to test and reuse
* you can choose an explicit mutable API that matches your concurrency and scalability needs. Clojure provides four different APIs for different situations: refs and STM, agents, vars, and atoms. Plus, you can always drop down a level and use the Java Concurrency APIs.
InfoQ: Another group interested in Clojure are programmers already familiar with LISP; what do they need to watch out for when trying Clojure?
My advice to Lispers is "be patient at first." Clojure is Lisp unconstrained by backward compatibility with other Lisps. What this means in practice is that many things are different. Once you spend some time with Clojure, you will probably agree that Rich's design decisions are well-motivated.
The Clojure website has a document that shows differences with many other LISPs. The creator of Clojure, Rich Hickey, provides slides that (PDF links) explain Clojure for Java developers and vice versa from a LISPer's point of view.
InfoQ: What habits do Java users, or more generally, developers used to OOP, need to unlearn to work with Clojure?
Unlike other hot new VM languages, Clojure is *not* object-oriented. This can be intimidating at first: "How am I supposed to design a system without objects?"
But Clojure *does* provide many of the things you want from OO:
* encapsulation (via namespaces, private definitions and closures)
* polymorphism on steroids (multimethods)
* functional reuse is better than inheritance. (Functions and immutable state compose better than inheritance hierarchies.)
The difference between Clojure and many OO languages is that the OO languages offer a fixed menu, while Clojure's capabilities are a la carte.
InfoQ: What resources do you recommend for starting with LISP (besides your book, obviously)?
Clojure ties together a lot of good ideas. In addition to Programming Clojure, I would recommend
* Seibel, Practical Common Lisp for getting up to speed on Lisp
* Graham, On Lisp for Lisp macros
* Goetz et al, Java Concurrency in Practice for concurrency
* O'Sullivan et al, Real World Haskell for functional programming
* Abelson and Sussman, Structure and Interpretation of Computer Programs, because everybody should read it
Note: most of these books are also available online for free: Practical Common Lisp, On Lisp, Real World Haskell and SICP.
InfoQ: What older LISP patterns/practices should Clojure developers stay away from? (Eg. instead of lists everywhere prefer Clojure data structures like maps/vectors/... where possible?).
You pretty much nailed it in the question. In Clojure, lists are mostly for code. For data, choose the right structure for the job, and embrace the sequences library. Don't be afraid to call Java APIs directly.
InfoQ: What's the library ecosystem like for Clojure?
For any given need (web development, db access, testing, bdd) there are three or four up-and-coming Clojure libraries. The book ends with a "Clojure in the Wild" chapter that briefly introduces several of these, and provides more extended examples using the test-is testing framework and Compojure.
On the Clojure mailist list, Rich Hickey recently asked for maintainers of Clojure libraries to report the library they're working on. Many Clojure projects can be found on GitHub under the Clojure language category.
InfoQ: Would you like to see a multi-platform Clojure (not just Clojure for the Java platform)?
No. Clojure's tight integration with Java is key to its power. Of course I would welcome a functional Lisp tied to the .NET platform -- but it shouldn't be Clojure.
InfoQ: What tools do you use for Clojure programming?
I use Emacs, plus SLIME sometimes. But I was already an Emacs user, so that choice was obvious. There are also plugins for vi, Eclipse, IDEA, and NetBeans.
Some examples of IDE/editor support for Clojure are: clojure-dev (Eclipse), clojure-intellij-plugin (IntelliJ), enclojure (NetBeans). Gorilla (VIM), is similar to SLIME (Emacs). (Bill Clementson has a has a howto on setting up Emacs and SLIME for Clojure).
As many of these tools need to do similar things, there's been talk of collaborating on a common backend for these tools. One option is to use an aproach like SLIME and Gorilla, ie. run a Clojure instance and query it for documentation lookup (Clojure symbols carry their docstring as metadata), code lookup, namespace browsing, etc.
InfoQ: Would you use Clojure in a commercial, non-trivial project now?
If you are on an agile team and have a good test suite I wouldn't hesitate to use Clojure in production today.
InfoQ reported recently about one example of a Clojure application being put in production. (More Clojure content on InfoQ).
Would you consider Clojure? Which aspect of Clojure is most interesting for you - it's LISP heritage, STM, something else?