Skip to content
#Architecture

[1/2] Clojure: The Documentary (Category Architecture)

#Architecture #SoftwareDesign #EngineeringManagement #SystemDesign

I saw a new one. CultRepo documentary about Clojure And it's the story of how Rich Hickey's view of complexity became the language, the community, the Datomic database and the production stack for companies like Nubank. (Which I've been talking about. told). Not only does Rich appear in the film, but the other key people who built the language, wrote books about it, implemented it in companies and used it in large systems.

Below are some of the highlights in the documentary that I made for myself. (I’m not a fan of Clojure and I’ve always felt the language was far from being sold.)

1A programming language is not a syntax, but a way of thinking. Clojure is important not because it is the successor to Lisp and runs on top of JVM, it imposes a certain model of thinking, where the program is built from simple parts: immutable data, pure functions, explicit state transitions and minimal unnecessary squats. And that’s a good question for any team: Do your primary language and frameworks help you think easier or just make things easier?

2Simple and easy - different things The film constantly returns to the ideas of Rich Hickey from the report.Simple Made Easy" 15 Summertime. And Rich shares them like this. Easy is something that is nearby, familiar and quickly given to the current team. Simple is one where there are fewer weaves, fewer hidden dependencies, and less random complexity. Understanding this distinction is important for tech executives – often a team chooses easy: a familiar framework, a familiar ORM, another layer of abstraction, another microservice, another integration. And then a year later, it turns out that the system has become not simple, but simply familiar and complex.

3Mutable state - the main source of pain Clojure is trying to remove not all changeability from the program, but unmanageable changeability. Clojure is built around Lisp, functional programming, JVM and concurrency, and around immutable persistent data structures and STM. The strongest idea here is to separate identity and state. Identity can live in time, but the specific value of the state must be immutable. Value does not change; the system simply associates identity with new value. It radically changes the way we think about bugs, concurrency, auditing, debugging, and data history.

In post-continuation Let me tell you about the remaining interesting moments.

#Architecture #SoftwareDesign #EngineeringManagement #SystemDesign