Clojure is cool
Tonight we had a special edition of the Western Mass. Developers’ Group as Rich Hickey made the long trek north to talk to us about Clojure, his functional Lisp dialect that runs on the JVM.
I enjoyed Rich’s presentation a lot. He’s clearly a very smart guy with very focused goals for the language. He breezed through the basic Clojure intro stuff to get to slides and a demo app focused specifically on concurrency issues. He walked us through almost every piece of the example app, a simple graphical simulation a couple hundred lines long. Remarkably, given that I have almost no non-toy experience with Lisp or Java, I found it mostly understandable.
He’s definitely on a tear against gratuitous mutability in software. Those are my words, not his; what he said was: “Mutability is the new spaghetti code.” (If this seems perplexing, reading up on functional programming may help. I know I had no idea why people were railing against mutability and state before I started playing with Haskell.)
Some miscellaneous things that I found interesting or cool:
- The REPL. Honestly, after so much time with Python, I consider this an essential feature.
- A lot of Clojure is written in Clojure. See the
boot.cljsource file. - Maps (hash tables) act as functions of their keys. Nice uniformity; why have a separate syntax for these? Also allows you to replace your map with a more complex function later without messing with the interface.
- “Persistent data structures” allow you to have both immutability and performance. If you create an updated version B of a data structure A, B is not a full copy; it’s more like a diff. There’s a lot of stuff under the hood here that I am not yet smart enough to understand.
- Clojure code can be edited to change a running application on the fly.
- Earlier implementations generated Java and C# source code; now it compiles directly to JVM bytecode. It seems that code generation almost always ends up being a prototype solution, not a final solution.
Rich is an effective language advocate not just because he’s smart and articulate, but because he’s clearly done his research and understands the relevant alternatives and tradeoffs in a deep way. When asked about Erlang, he took pains to point out the things that Erlang does well, and the differences between Clojure and Erlang that are the result of different conscious tradeoffs. Engineering is about tradeoffs.
Thanks to Lou and Chas for organizing and hosting this, and of course to Rich for making the drive and the time to evangelize Clojure to a small group of programmers in the (relative) sticks.