The case for Clojure is richly detailed and well-documented. But sometimes you just want the elevator pitch. OK, but I hope your building has four elevators:
- "Concurrency is not the problem! State is the problem. Clojure's sweet spot is any application that has state."
- "Don't burn your legacy code! Clojure is a better Java than Java."
- "Imperative programming and gratuitous complexity go hand in hand. Write functional Clojure and get shit done."
- "Design Patterns are a disease, and Clojure is the cure."
Any one of these ideas would justify giving Clojure a serious look. The four together are a perfect storm. Over the next few months I will be touring the United States and Europe to expand on each of these themes:
- "e;Clojure's sweet spot is any application that has state."e; At Oredev, I will be speaking on Clojure and Clojure concurrency. I will demonstrate how Clojure's functional style simplifies code, and how mere mortals can use Clojure's elegant concurrency support.
- "Clojure is a better Java than Java." I will be speaking on Clojure and other Java.next languages at NFJS in Atlanta and Reston.
- "Design Patterns are a disease, and Clojure is the cure." I will sing a siren song of Clojure to my Ruby brethren at RubyConf.
- "Write functional Clojure and get shit done." At QCon, I will give an experience report on Clojure in commercial development. Our results so far: green across the board. Both Relevance and our clients have been pleased with Clojure.
Want to learn about all four of these ideas, and more? Early in 2010, I will be co-teaching the Pragmatic Studio: Clojure with some fellow named Rich Hickey.
If you can't make it to any of the events listed above, at least you can follow along with the slides and code. All of my Clojure slides are Creative-Commons licensed, and you can follow their development on Github. Likewise, all the sample code is released under open-source licenses, including
And remember: think globally, but act only through the unified update model.
