Hi, I'm Patrick, and I modify state

This is my first post to the “State-Modifiers Anonymous” self-help group. I wish to overcome my bad habit of modifying state in an unsafe manner, and use something like Clojure instead as a remedy.

So my name is Patrick, I’m a developer and part-time teacher based in Switzerland. I started with Visual Basic, C#, Java, JavaScript, but later discovered Go, which was quite some relief, especially the great concurrency model. Professionally, I mostly program in Python (and some JavaScript and Go).

A bit more than a year ago, I had to migrate the servers of our company’s logging/monitoring stack, which uses Riemann. Since I also wanted to make the switch from Graphite to InfluxDB, I had to learn some Clojure in order to modify the configuration. For some reason, Russ Olsen’s “Getting Clojure” was already in my book shelf; this it how it started.

It then continued, and I worked through the entire book, which I also summarized (https://raw.githubusercontent.com/patrickbucher/learning-clojure/master/getting-clojure.pdf)

I meandered between Elixir and Clojure (both hosted languages) for a while, and learned the basics of both environments. However, learning some kind of Lisp is something I wanted to do for a long time, so it’s rather Clojure than Elixir at the moment.

So I hope to make some progress in the upcoming weeks and months, and hope that this community will be part of my journey.


Welcome! Hope you’ll like it here.

1 Like

One of the nice things about Clojure is that although it makes FP natural it’s not dogmatic about it. Sometimes you should modify state–even if you don’t have to. But, you know, that’s an advanced technique. :slight_smile:

1 Like

I think a lot of Clojure I see is just stateful Python or Java rewritten in Clojure. I spent a lot of time in the past doing the same. Organizing programs to pull state to the center of the program and force IO to the edges takes a lot of experimentation. A lot of unlearning. Using a library like Integrant and making all IO and state reside in the one system map is a good way to do this. Another is to master the middleware pattern. Almost all the code written can be structured as a bucket brigade of functions that modify a request or a response. Middleware allows composition of such functions and provides flexibility without restructuring large swaths of software interlinked with the call stack. Then final systems are simply compositions of pure functions mixed with effect-full functions via middleware. And it is then all easy to do from the REPL. Programming in the small and assembling to make the large is, I think, the name of this game.