I have spent the last 6 months on a project where Clojure was the main technology in use. I can’t really say much about the project itself, except that it’s a fairly complicated thing with lots of analytics and different kinds of data involved. We ended up with an environment that had a lot of Ruby and JavaScript/CoffeeScript as well as Clojure. We are using Neo4J for most of our data storage.
In this blog post I wanted to basically talk about a few different things that has worked well or not so well with Clojure.
Being on 1.4
When the project started, Clojure 1.4 was in alpha. We still decided to run with it, so we were running Clojure 1.4alpha for about one month, and two different betas for another month or so. I have to say I was pleasently surprised – we only had one issue during this time (which had to do with toArray of records, when interacting with JRuby) – and that bug had already been fixed in trunk. The alphas and betas were exceptionally stable and upgrading to the final release of 1.4 didn’t really make any difference from a stack standpoint.
Compojure and Ring
We ended up using Compojure to build a fairly thin front end, with mostly JSON endpoints and serving up a few HTML pages that was the starting points for the JavaScript side of the app. In general, both Compojure and Ring works quite well – the ring server and the uberjar both worked with no major problems. I also like how clean and simple it is to create middleware for Ring. However, it was sometimes hard to find current documentation for Compojure – it seems it used to support many more things than it does right now, and most things people mention about it just aren’t true anymore.
Enlive
In order to get some dynamic things into our pages, we used Enlive. I really liked the model, and it was quite well suited for the restricted dynamicity we were after.
DSL with lots of data
One of my less bright ideas was to create an internal DSL for some of our data. The core part of the DSL was a bunch of macros that knew how to create domain objects of themselves. This ended up being very clean and a nice model to work with. However, since the data was in the amounts of millions of entries the slowness of actually evaluating that code (and compiling it, and dealing with the permgen issues) ended up getting unbearable. We recently moved to a model that is quite similar, except we don’t evalute the code, instead using read-string on the individual entries to parse them.
Dense functions
Clojure makes it really easy to create quite dense functions. I sometimes find myself combining five or six data structure manipulation functions in one go, then taking a step back and look at the whole thing. It usually makes sense the first time, but coming back to it later, or trying to explain what it does to a pair is usually quite complicated. Clojure has extraordinarily powerful functions for manipulation of data structures, and that makes it very easy to just chain them together into one big mess.
So in order to be nice to my team mates (and myself) I force myself to break up those functions into smaller pieces.
Naming
One aspect of breaking up functions like described above, is that the operations involved are usually highly abstract and sometimes not very coupled to domain language. I find naming of those kind of functions very hard, and many times spend a long time and still not coming up with something I’m completely comfortable with. I don’t really have a solution to this problem right now.
Concurrency
For some reason, we haven’t used most of the concurrency aspects of Clojure at all. Maybe this is because our problems doesn’t suit themselves to concurrent processing, but I’m not sure this is the root of the reason. Suffice to say, most of our app is currently quite sequential. We will see if that changes going forward.
Summary
I’ve been having a blast with Clojure. It’s clearly the exactly right technology for what I’m currently doing, and it’s got a lot of features that makes it very convenient to use. I’m really looking forward being able to use it more going forward.
5 Comments, Comment or Ping
Chas Emerick also exposes the ‘funtion density’ problem on this talk: http://www.infoq.com/presentations/What-Sucks-about-Clojure-and-Why-You-ll-Love-It-Anyway
I don’t believe there’s such thing. In Chas’ example `camel->keyword`, concision hides complexity, in a very concrete sense: the funtion does N things – which are pretty much orthogonal.
Descomposing it on more functions yields more flexible APIs and clearer impls – at the cost of verbosity or even duplication, of course. A tradeoff that may be worth it in more substantial cases.
August 3rd, 2012
Interessting. Could you please elaborate on your motivations to choose Clojure as a language? And for what parts of the system, as opposed to ruby?
And, if another question is permitted: Did you consider using ClojureScript for client facing stuff?
August 3rd, 2012
So since you seem to being using clojure like me not just for its concurrency features, what would you like to see coming in clojure 1.6.
Me myself was missing clojure database persistence.
But that has changed since they created Datomic.
Many Greetings and thank you for sharing your experiences!
John
August 3rd, 2012
I like this notion of “function density.” Has a good ring to the ear, while drawing an appropriate mental picture of the issue.
November 23rd, 2012
How does this language compare with VB6? I am yet to find a language as powerful as VB6.
August 27th, 2013
Reply to “6 months with Clojure”