lotypart deux

scala_vs_clojureA few days ago I pontificated on my need to choose a new “Language of the Year.” Right now I'm attempting to choose between Scala and Clojure. If nothing else, I've learned from this exercise that asking the community for feedback is a GOOD thing. Your comments have been very helpful.

To summarize:

  1. As far as the polls go, Scala is in the lead by a margin of 4 to 2.

  2. Two of the Scala votes have been simple +1's, and two have provided a supporting argument.

  3. Both Clojure voters have provided a supporting argument.

  4. So, to make this a bit more of a fair fight, I'm only going to consider the “supported votes” at this point. This leads to the obvious result of a tie!

So, what to do?

The argument for using Scala is that it is a functional/OO hybrid, so it will be easier to slide into. Interestingly enough, the argument against using Scala is that it is a functional/OO hybrid, so it will be easier to slide back into OO/imperative habits! Clojure, being more of a purely functional language, will be harder to get into initially, but will force me to think functionally. Hmmm…

So here's my idea. Let's do this the agile way. What I'd like to do is complete a timeboxed spike (in terms of actual time spent learning the language, not calendar time - I'm doing this in my spare time, and I've got my wife, four kids, and three other side projects competing for my attention!) of roughly two weeks in each language. The first week of the spike would be spent getting comfortable with the syntax, reading articles/documentation/blogs/etc., writing “Hello, World!” etc. The second week of the spike would be spent solving the same problem in each language, preferably a problem sitting in the functional sweet spot.

How does this sound to everyone? And to follow up, does anyone have a suggested problem I might tackle? Cheers!

Avatar
Matt Stine
Executive Director, Architecture

My research interests lean/agile software development methodologies, DevOps, architectural principles/patterns/practices, and programming paradigms.