I’m looking at a few job opportunities which require a working knowledge of Clojure, so I thought I would spend some time learning it in more depth to be prepared for that possibility.
I’ve been enamored of Clojure (especially for scientific use) for a while, but have never taken the time to learn it well enough to make it my “go to” language. When Clojure was first making a big splash a couple of years ago, I worked through the Pragmatic Programmers’ book, Learning Clojure, and I watched several talks by Rich Hickey about the underlying design of the language. I am not new to functional programming, having worked my way through the classic Structure and Interpretation of Computer Programs in Scheme, so the ideas strongly resonated with me. At the time, however, I was working on a slow maching and found the JVM load time majorly off-putting in my development cycle. I assumed there were tools to avoid that startup penalty, but I never put in the necessary time to work that out.
Eventually, I got a taste for the language but did not immediately have a place to use it in the real world, and so it slowly faded to the background.
The Clojure Koans
My first idea for refreshing my Clojure knowledge was to see if someone had created a set of koans, and indeed I quickly found the Clojure Koans. So, I forked the repository and started working through them. Unfortunately, I completed the Clojure Koans almost as quickly as I could type, so I didn’t learn much that I didn’t already know. However, it was useful in compiling a list of topics for further exploration. These are the language areas that felt unclear:
- lists vs. vectors — review the underlying differences to understand better when to use each
- refs vs. atoms vs. agents vs. vars — learn these concurrency models in detail
- macros and quoting — sort out when to quote things and how for complex macro definitions
- records vs. types — get a better handle on the fundamental differences
In general, I also think I need a lot more experience with:
- leiningen and overall project structuring
- testing tools
- the package ecosystem
The Koans did not require me to synthesize much new code, so I set out to find
something a bit more challenging and stumbled upon
Project Euler. This looked like a good way to
improve my core Clojure skills in a more mathematical context, so I generated a
new project using
lein and began
working through the Project Euler problems
in order. I think this is a great way to exercise little-by-little my problem
solving skills in Clojure, and I plan to continue adding new problems/solutions
in my spare time.
Besides potential contracting work which requires Clojure, I am also interested in using it as a data science tool. In general the community has rallied around Python for that purpose, but I think that Clojure’s immutable data and functional paradigm are a much more natural fit. I am just beginning to explore the Clojure package ecosystem, but I hope to find more and more tools for data analysis in context. It seems this idea is gaining some momentum, as I have seen some job postings for Clojure data scientists. Also, I watched Clojure Data Science – Edmund Jackson last night and was encouraged about the role of Clojure in the future of data science.