Why I’m Still Learning Clojure

Last year was C# and Erlang, this year was Clojure thanks in part to the excellent London Clojure Code Dojo.

(Bear with me for the next paragraph, and the subjective nature of later bits)

Clojure has been an interesting experience because I have neither a Lisp nor JVM background. I’ve found myself having to deal with prefix notation and a parenthesis overdose, as well as the unfamiliarity of the Java ecosystem. The official documentation is patchy, the language is still new and evolving, dedicated development tools are relatively immature, and there are moments when the JVM leaks through. It’s the first time I’ve felt a little out-of-my-depth when learning a new programming language, which is not necessarily a bad thing.

Yet I keep going to the dojos, I still flick through the book when I get the odd spare moment, I keep improving my development environment and I’m still umming and ahhing between Clojure and Erlang for a possible home project I want to work on next year, once my FluidDB and game ideas have been unleashed upon the world properly.

So why am I still learning Clojure?

I asked myself that question recently. I still disagree with Neal Stephenson’s comment that Lisp “is the only computer language that is beautiful”, but Clojure has helped me to understand why people like Lisp as well as clean up some of the ugliness of the language. I’m sorry guys, but Lisp has always looked pretty ugly to my eyes, despite the lack of boilerplate found in languages like, say, Java or C#. When Clojurians say that it’s Lisp reloaded, they mean it – which has upset some Lisp programmers but pleased others.

There’s a greater sense that people are using Clojure to solve real problems, evolving the language to deal with real issues rather than thought exercises from the ivory towers of academia. The community itself is generally a friendly and positive one with a good mix of people from different backgrounds, not just the Lisp and Java worlds. Being there as the language and community evolves has been fascinating and quite exciting.

Getting back to Clojure’s Lisp origins, I still believe it should be the starting point, not the direction. Clojure needs to find its own way, its own metaphors and patterns – retaining Lisp’s strengths while confidently discarding the legacy baggage.

Take macros, for example: much as I can see the power of them, I think they’re a distraction rather than a tool in this day and age. A controversial view for sure, but I guess I’ve never seen a conclusive argument for their use – indeed, the wisdom seems to be that you shouldn’t really need to use them. It feels like there should be a more contemporary or Clojure-like way of providing the power of macros, without the complexity or obfuscation. I don’t know what that way is yet – but I’m not sure others do either.

Clojure encourages immutable data structures, but acknowledges that the real world doesn’t work that way so a pragmatic language needs to handle mutable state. Clojure implements this in more controlled ways to other languages. My favourite option is software transactional memory. STM is a natural fit to someone who has used relational databases for the last ten years. It feels right for many applications in a concurrent environment, and it’s right there in the language from the start – not hacked in later or provided as a third-party module.

It might not quite fit in my brain like Python, I don’t quite grok the intricacies of the language yet, and the sooner more of Clojure is implemented in Clojure the better. Yet it still has me interested – I want to learn more about the language and write more Clojure code because deep down there’s something kinda cool about it.

Out of the Comfort Zone

One of the best ways to learn new skills is to be out of our comfort zone. When we’re out of our comfort zone, the mind and body attempts to deal with the situation – we become more alert and adaptable, we have to think a bit more, we have to pay attention to what’s going on. After all, we can’t rely on the situation being safe and predictable because we just don’t know what might happen.

When I’m not programming, I love snowboarding. I’m fortunate in that I’m just a few minutes away from an indoor snow slope. It might not be a proper mountain, but I can go ride any day of the year. I’ve been snowboarding for years and am pretty good because I’ve taken the plunge and put myself out of my comfort zone on many occasions. I’ve progressed up the instructor levels, I’ve been on performance courses with top pros, I’ve done a bit of proper off-piste, I’ve even raced boardercross (despite being an injury wuss).

One notable occasion was enrolling on an instructor course in Australia a few years ago. I had no intention to teach, just to improve my technique. In the end, I found myself having to improve my skills in front of people who were much better than me, and do something I feared most: public speaking.

All I wanted was the ground to swallow me up, but I didn’t have that luxury – I had to push myself harder than everyone else, and I had to just do it. Stand up in front of a group of strangers and teach them to snowboard. Keep up with people who had many more days on snow than me. Some had been instructors before. Nothing makes you learn fast like trying to match people way above your skill level.

I still get nervous before every lesson, but I found I enjoyed it a lot. It feels like it exercises different parts of my brain to those I use when programming or even snowboarding for my own enjoyment. The brain specialists might disagree with me, but you get what I mean.

However, there is a limit to how far we can go outside our comfort zone before the benefits disappear. And they can disappear very quickly. I’d never dream of taking a complete beginner to the top of a black run. They would be so far out of the zone that fear would overwhelm any opportunity to learn – it would also be incredibly dangerous and probably put them off ever going on a mountain again.

One of the things I love about code dojos, like the Python and Clojure dojos I attend each month in London, is that they provide a safe environment to move out of the comfort zone and learn new skills. Mistakes are all part of the learning process, yet we often don’t embrace them. I’m a firm believer that people learn most when things go wrong, because we’re taken out of that nice, comfortable, step-by-step process. When we make a mistake, we have to start thinking again to correct the mistake.

The trouble is that people don’t like to admit they’ve made a mistake because they feel they’ve lost credibility against their peers. But their peers are in the same situation. If no one wants to make a mistake, no one learns because of that fear of public failure and embarrassment. Dojos are great because everyone is there to learn new things and make mistakes in the process. Any mistakes you make stay in the dojo – it’s not production code, nor is it intended to be.

So where am I going with this? Well, my next out-of-comfort-zone situation is taking the skill I learnt as an instructor and bringing it into my full-time career: public speaking. Teaching beginner snowboarders is, relatively speaking, easy because they mostly don’t know anything about the subject. If I make a mistake, no one will notice. I get a big fear teaching other instructors because they know the subject, they know when you make a mistake.

But that’s a good thing right? They can let you know the mistake and help you fix it. It also forces you to practice and improve so you don’t make those mistakes – pushing that comfort zone further out.

I want to do the same thing with technical talks. The idea of standing up in front of other programmers and talking tech fills me with dread. Yet I know it’s exactly the same situation I was in when I first stood on an Australian mountain and tried to explain part of a lesson to a group of experienced snowboarders. After a few such experiences, I ended up loving it because it taught something new to my audience and because it helped me to improve my own understanding of the subject.

So my intention is to try to present a few talks over the coming months at events like the dojos, where I can make mistakes in safety. My goal is to present at one of the Python conferences. I was talking to one of the organisers of PyCon AU when I was at EuroPython this year, and he mentioned about presenting, which is where the whole process was set in motion. I’d like to attend PyCon AU next year, combining it with a visit to my brother in Sydney. Presenting would be both great fun and terrifyingly scary at the same time, but if the Aussies in the audience are as supportive of a nervous Pom as those Aussie instructors-to-be were, I should be just fine.

Tips, tricks and encouragement would be very welcome.