Why Clojure Rocks

Andreas Profous

Recently, I’ve been learning about Clojure, and I have to say I’m impressed. I just started to learn about the language in my spare time, but my impression is very positive; all the different pieces seem to just magically interact together such that the sum of the parts is larger than the individual parts. In this blog post, I will try to give you an idea of why I feel this way. Worth mentioning is that my programming background is C, C++, Python and Ruby (in that chronological order), gracefully ignoring the Basic I learnt when I was young. My impressions come from reading a book, solving some toy problems online and attending a conference, the EuroClojure 2013.


Without further ado, here are Clojure’s features at a glance:

For example:


One important thing about a new language is the culture that surrounds it. I believe in the case of Clojure, the culture is mainly centered around the creator of the language, Rich Hickey, and the people “surrounding” him, that recently founded Cognitect. I strongly recommend to view Rich Hickey’s greatest talks. I’d say they are almost a required viewing for programmers, even if you’re not interested in Clojure at all – there’s a reason the post was on top of Hacker News for quite some time.

I’ll try to give my current impression of a few trends/beliefs in that culture:

Skepticism about object-oriented programming. The atomic composable unit in a program are pure functions, not mutable objects. Clojurians always prefer generic data structures like maps, sets and lists over concrete objects. A focus on well-thought out program/system design instead of ad-hoc designs that arise from patterns like test-driven development. In Clojure, you can do so much with just one line of code, that it becomes much more important to think thoroughly before starting to code. As such also skepticism about agile programming when it drives people to rush into coding without thinking first. Separation of identities and values. Values are immutable pieces of data; identities are basically names for entities, which may change their values over time. Traditionally, programming languages complect these notions, since both of them are variables or objects. In Ruby, the BDD workflow to follow is (I’ll simplify here): write tests, write code, execute test, reiterate until tests are green, go to next feature. Clojure doesn’t have such a focus on tests, instead much of the testing is basically moved to the REPL in the “ideal” workflow. See this blog post for details. Belief in showing not only the positive parts of a solution, but also the negative parts. There is always a tradeoff, so one should consciously choose the best solution. For example, Clojure itself naturally also has negative parts: it’s not very well suited for small scripts, since the JVM takes a long time to load up. Moreover, it requires a shift in the mindset if you come from an object-oriented, imperative background. It requires some practice, you cannot just jump in so easily. Libraries and Related Stuff

###Web Programming

The “classic” stack in Clojure for a web server is Ring and Compojure. It’s roughly analogous to Ruby’s Rack and Sinatra, respectively. I’ve not been able to find something similar to Rails in the Clojure environment. Maybe a contender is pedestal. However, it seems to have quite a different approach; it’s rather comparable to Javascript’s Meteor in that it uses the same language on the server side and on the client side. It also seems to require quite some learning. It could be handled in a separate blog post, I suppose :)

tl;dr View Rich Hickey’s talks.

Andreas Profous

Andreas hat nach seinem Studium seine Leidenschaft für das Programmieren im Rahmen der Softwareentwicklung eingebetteter Systeme, in den Sprachen C++ und Python verfolgt. Er verbesserte über fünf Jahre Routingalgorithmen von Navigationssystemen, ist zertifizierter Scrum Master…

Mehr Lesen ...