Clojure Brings STM, LISP to the JVM
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?
STM definitely attractive
I highly recommend Stuart Halloway book.
Clojure compared with Scala
Howard Lewis Ship
I think Scala's type system is a bit of a challenge, and it's not quite as powerful as Haskell's; I think Scala may fall into a kind of uncanny valley ... neither quite Java nor sufficiently Haskell, whereas Clojure seems to be building to a summit: best of Java and best of Lisp.
Re: Clojure compared with Scala
i also think that Scala's type system is actually one of its real strengths - it really shouldn't get in your way as it is both more consistent and more powerful than Java's while at the same time being clearly familiar to a Java developer.
i find Scala's OO-ness a real relieve because it means that my designs are still basically OO (with the addition of mixin-style multiple-inheritance!), which nicely fits the kind of entity-centric programs i write, while still benefiting (in the small) from Scala's closures, hardened static typing and numerous syntactic improvements. that's clearly just one of many ways of writing Scala code, though...
Re: STM definitely attractive
we have been in production now for more than a month with services
implemented in Clojure and we did not experience any unexpected down time
aside from the improvements we deployed in production.
The Clojure runtime is so stable that we felt confident enough to go live
without waiting for version 1.0.
The current status proves that we were right. Of course you might
face migration issues if you start to use some advanced features
or bleeding edge libraries. The forum has enough accumulated
threads that you can easily find out if some features will eventually
change and that should guide you to avoid these areas.
Both the code and the specs are very consistent over time so such
set backs are unlikely to happen.