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.

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.

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

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.

I have been playing with Clojure and I love it so far. Being a functional language for the JVM is probably what got my attention first. The STM was something I have always wanted to have as part of a language so this made it even more compelling to get me started. Since it is still too early to consider Clojure for production, I use it for prototyping and I consider it more as a utility language extending Java at least for now.

We were just having a discussion of Clojure vs. Scala over lunch today. None of us really have enough experience with both to make a firm comparison, but my gut feeling is that Clojure will provide a better investment than Scala: the Clojure syntax is really easy, and the functional nature (immutable everything, no side effects) is very pragmatic and supports lots of lazy evaluation.

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.

the litmus test is probably whether you want to keep on using a (pure) OO language - Scala is that (and much more), Clojure isn't.

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

we have been in production now for more than a month with servicesimplemented in Clojure and we did not experience any unexpected down timeaside from the improvements we deployed in production.

The Clojure runtime is so stable that we felt confident enough to go livewithout waiting for version 1.0.

The current status proves that we were right. Of course you mightface migration issues if you start to use some advanced featuresor bleeding edge libraries. The forum has enough accumulatedthreads that you can easily find out if some features will eventuallychange and that should guide you to avoid these areas.

Both the code and the specs are very consistent over time so suchset backs are unlikely to happen.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.