Experimenting with Clojure for a day

Ruby really is my favourite programming language, I love the clean syntax and the freedom that it gives you. Beyond debugging meta programming in gems far far away, I have no real trouble with solving problems in it. Many people say that it is too slow, but I have found that effective caching and background processing negates this for the majority of typical web apps.

So why Clojure?

We all know the awesomeness that makes Lisp unique:

One thing that got me interested in it was that there was some sort of natural progression in style of coding over the years. I started placing more value in data and started seeing stateful and stateless code as a separation of concerns. Lisp seemed to have all these principles baked into its core, yet I had to work so hard to get them in procedural languages.

Made Learning Day

We recently had a day dedicated to learning / exploring something that may benefit to our daily work, whether it be a programming language, library, service or whatever. This would be the perfect opportunity to share my interest in the language.

We were divided into 3 teams with one person at the head of each team to lead the way. We all pitched our ideas and people joined the team with the idea they were most interested in.

The 3 winning suggestions were:

Leading Team Clojure, I was far from a professional but knew enough to get us started.

Some of my previous Lisp experience included:

  • Configuring Emacs
  • Smashing as much of the Wizard book into my brain as possible
  • Clojure for the Brave
  • Random katas

My two team mates were Chris and Nick, and they were pretty enthusiastic about it. London Google Campus would be our location.

I did a quick introduction to Lisp including history, features like the reader, macros, data structures, and why I think this language was worth researching. Our approach wasn’t going to be to zone in on any one aspect of the language, I instead opted for building something useful as quickly as possible.

At the end of the day I hoped to achieve the following:

  • A CRUD product system, backed by MySQL
  • Have at least one unit test
  • Make it presentable for demo

Stretch goals

  • Caching
  • I18n
  • Image uploading
  • Deployment to Heroku

We used Luminus (whoops nearly said framework there) to create the program. The documentation has an awesome example of building a xxx system, and we were going to adapt this to build our own product CRUD system. So we started hacking away at it, picking random tickets that we had created in Trello.

The bad

  • Having to reboot the JVM for changes to be picked up
  • Plain SQL, we missed our ORM’s! (as imperative programmers do)
  • Java stacktraces; the volume of data made it feel like we were not escaping any complexity
  • Testing culture in general was different, and we struggled to get into our red / green / refactor cycle
  • Less convention over configuration than we were used to; we had to actually think about glueing stuff together

The good

  • We were able to make significant progress in 5 hours and had a lovely “stable” website to demo
  • Fun talking about the origins of Lisp and realising how different it is from object oriented programming
  • Beautiful maps without commas
  • Variety of interesting datatypes
  • Preview of how awesome the community is; because the barrier to entry is higher than Ruby I find that there are a lot more smart academic types
  • The safety that immutable data structures bring; you have to be explicit about shooting yourself in the foot
  • Rainbow parentheses!

Nick wrote what I would consider the best function of the day.

(defn slug-from-name [name]
    (clojure.string/lower-case (clojure.string/replace name #"s+" "-")))

What next?

It is optimistic to assume that you will be sold on a language in 5 hours of experimenting with it. To be honest I felt quite a bit of pain as I was trying to write Clojure in my default imperative way of thinking, but I will continue to study Clojure and bring it up again as a research topic at the next MLD!

About the Author

Emile Swarts

Senior Software Engineer at Made Tech. All about big beards, beers and text editors from the seventies.

Avatar for Emile Swarts

We are hiring! Find out more about a career at Made Tech.

Download a copy of our new book

Legacy technology is one of the biggest threats to public sector organisations.
Whether you’ve started your journey already or don’t know where to begin, this 160-page book has been written to guide you to define and implement the right approach for your organisation.