An interactive Clojure journey



This document is primarily an aide to an evening of learning focused on Clojure. However, ideas want to spread. The second objective is therefore to share a Clojure experience with any reader.

Why Clojure?

I like Clojure because:

  1. It has great support for interactive programming
  2. It has a great standard library
  3. It is a great tool for building your own abstractions.

If Clojure is so great, why doesn’t more people learn Clojure?

Clojure is not easy. Getting started with Python, Javascript, Java, Go, Rust, Haskell or Elm is easier.

Clojure is also more different from other common languages than the common languages are different from each other.

Here’s a very subjective chart of languages:

less different                                          more different

      .    .   .   .     .          .    .                  .        .
      .    . Java  .     .         Elm   .                  .        .
      .    .      Go     .            Haskell               .        .
Javascript .            Rust                             Clojure     .
        Python                                                  Prolog

I tried learning Clojure myself in 2014. You know what I thought? It sucked. No types. Mismatching parentheses. Who would ever like this crap?

But revisiting the language in 2017 made me fall in love. What happened?

In 2014 I thought I was done learning how to work. I expected to write reasonably correct code at once. No iteration needed. Long strides, in GeePaw’s words. I was also far from humble enough. Heck, I had studies stuff. Hard math. Programming languages.

In 2017, my approach was different. Curiosity over entitlement. I had had started to get into Emacs, without really understanding why. I guess I was missing something from Vim and Sublime. A kind of mobility. A flexible context. An ability to move fast around, to see. Then I got to watch an experienced Clojure programmer using the REPL to its full potential. He assembled his system on the fly, changing the pieces as required. He saw. What’s on this HTTP request? What’s in this JSON payload? He saw, he coded, he changed the system, he observed the new system behavior.

I wanted that.

“So, should everyone code in Clojure?”


I like providing options. I don’t like forcing things stuff down throats. If I can aide a curious mind, I’d be happy. Please do keep your own agency. And please keep treating yourself as a person.

Why Clojure 2

“We need to conform on languages” predicates that programming languages are like different breeds of horses. Different breeds of horses are mostly interchangeable.

What if one programming language is a horse, another one is running shoes? One is a bike. Another is a lawnmower. One an excavator. Another a set of Lego bricks for building factories.

If we assume the excavator model of programming languages, there is tremendous risk of only using horses.


So! Onto the day.

We will be working together on a distributed system, live. Why? Because live is fun.

First, there needs to be a server. The server is dumb. Or thin. It doesn’t do much. But we need it to coordinate between clients.

Second, there’s clients. Clients can talk to each other by sending messages. What kind of messages? Just data, really. I’m hoping we can play with doing interesting stuff with messages!

Step - running server

There needs to be a server. To host websocket connections. So that clients can connect. And … subscribe? Or should everyone just get every message? That’s easiest.

We’re going to use HTTP-kit, compojure and Chord (because Zombie CLJ uses that). Also perhaps integrant, integrant is nice.

http-kit/http-kit {:mvn/version "2.5.3"}   ; HTTP server
compojure/compojure {:mvn/version "1.6.2"} ; Routing
jarohen/chord {:mvn/version "0.8.1"}       ; Websockets
integrant/integrant {:mvn/version "0.8.0"} ; System (optional?)