[ruszki]

It’s academic blabla, because as I stated it created a new vocabulary for no good reason. You can say the same thing without introducing it. You can say those things even better with examples.

I told you that I don’t know clojure, I know Haskell, which was also topic of Hickey’s presentation. I also know builder pattern… But looking into it:

> Clojure data structures use mutation every time you call, e.g. assoc, creating one or more arrays and mutating them, before returning them for immutable use thereafter.

So the solution is mutability… when Hickey preached about immutability. And basically builder pattern. A pattern which is in almost every programming language, most of the times a single line. So… immutability is not the best option every time, just as I stated, and it causes worse code. We agree.

You hit limitations with everything. ORM is not different regarding that. When I write s.isEmpty() in a condition in Java, I had to use a workaround… very painful. And yes, I state that if you think an entity is a simple class, then you are a bad coder, and if you cannot jump this “complexity”, you will never be a not bad coder. Same with sockets, ports, and pins.

Your last paragraph is totally worthless. You can say the same thing about everything.

I simply don’t preach. And I also wouldn’t say such things without considered an expert in ORM for example. I also wouldn’t say anything about which I don’t have first hand experience.

And as I stated, no matter what’s your tooling, bad coders will make bad code. On the other hand, you don’t need restrictive tooling to make good code. So what’s my problem is that, you don’t need Clojure or Haskell. It’s good to see something like that in your life, the reasoning etc, but it’s pointless to say, that you must be “simple”, when we can see that that is simply not true. Not even in Clojure according to Clojure.

[iLemming]

You seem to have been frustrated with prescriptive programming advice and language evangelism, which is understandable. Yet it looks like you're conflating Hickey's design philosophy with language zealotry. The talk's core message about reducing accidental complexity remains valuable, even if the presentation style and some specifics, sure, can be characterized as debatable.

I can buy your vocabulary criticism - fair point, okay. Although vocabulary often can help crystallize concepts. Clojure's internal mutation - alright, accurate observation. Clojure uses mutation internally for performance while presenting an immutable interface. This does show pragmatism over purity. "Tooling doesn't fix bad coders" - true. No language or paradigm prevents bad code if developers don't understand the principles. Immutability isn't always best - correct. Even functional languages acknowledge this (IO monads, ST monad, etc.), but Clojure doesn't force immutability - it provides default immutability with escape hatches.

Now things that I can't agree with:

"Academic blabla" is outright dismissive. The talk addresses real architectural problems many developers face. The criticism of ORMs isn't just about "complexity" - it's about impedance mismatch, hidden performance costs, and leaky abstractions. These are well-documented issues. "Must be simple" is a misrepresentation of Hickey's point. He advocates for simplicity as a goal, not an absolute rule. Builder pattern equivalence is oversimplification. Persistent data structures offer different guarantees than builders (structural sharing, thread safety, etc.).