[iLemming]

I'm not sure what you're saying, but just in case if you're implying that choosing to use something like Clojure or Elixir adds "unnecessary layer of problems" just because they are not statically typed, let me remind you that "simplicity" is basically Clojure's middle-name. Rich Hickey made a seminal talk on simplicity, https://www.youtube.com/watch?v=SxdOUGdseq4 it's quite eye-opening and isn't really about Clojure. Every programmer should watch it, perhaps even multiple times throughout different stages of their career progression.

[ruszki]

I don’t imply anything. I state (pun very much intended).

I cannot consider seriously anybody who thinks that programmer convenience and maintainability are different things on any level. And focusing on one doesn’t need the other.

Also this speech is academic blabla. I understand it, but there is a reason why he had to build a completely new vocabulary… because it’s not simple and easy at all. And there is a reason why there is exactly zero examples in almost the whole speech.

Because I can give you a very, very good example to contradict the whole speech: NAND gate.

Also you can code in Haskell basically with the same logic as in imperative languages (I used Clojure rarely, so I cannot say the same). So the “simplicity” is there only if you want to. But that’s true also the other way around: you can have the same “simplicity” in languages where mutability is the default. I agree that you should do immutability by default, but it’s stupid to enforce it. And he said the same thing, just it was a half sentence, because it contradicts everything what he preached: there are cases when his simplicity toolkit is the worse option.

Ruthless immutability causes less readable and maintainable code in many cases. And I state it, and I can give you an example right away (not like Hickey did): constructing complex data.

Also every time when somebody comes up with ORM and how bad it is, I just realize that they are bad coders. Yes, a lot of people don’t know how to use them. But just because it allows you to do bad things, doesn’t mean that it’s bad. You can say the same thing about everything after all. Every high level languages are slower than code in Assembly. Does that mean that every high level languages are OMG, and we should avoid them? Obviously not. You need to know when to touch lower layers directly. This is especially funny because there is a thread about that part on Reddit, because he used some vocabulary which is basically non existent, and the thread is a clear example of that people don’t even know what’s the problem with it. It’s a common knowledge that it’s bad, and they don’t know even why. For example, whoever fuck up a query through ORM, would fuck up the same way just with different syntax, like with a loop, because they clearly don’t know databases, and they definitely don’t even heard about normal forms.

And yes I state it again, using flexible type systems add unnecessary layer of problems. I also like that he mentioned Haskell, because it makes it clear, that his speech is completely orthogonal to the discussion here.

[iLemming]

You seem to be making several interconnected points, but your writing style is making it somewhat difficult to follow.

It looks like you're mischaracterizing Hickey's talk. The distinction between "simple" (not intertwined) and "easy" (familiar) isn't "academic blabla' - it's fundamental to building maintainable systems.

Your NAND gate example actually supports his point: we build higher-level abstractions precisely because working at the lowest level isn't always optimal. That's what Clojure's immutable data structures do - they provide efficient abstractions over mutation.

As for "constructing complex data" being harder with immutability - have you ever heard about Clojure's transients or update-in, lenses or Specter? They make complex data manipulation both readable and efficient.

The ORM critique isn't about "bad coders" - it's about impedance mismatch between relational and object models. Even expert users hit fundamental limitations that require workarounds.

Calling dynamic typing an "unnecessary layer of problems" at this point is pretty much just your opinion, as it is clear that you have one-sided experience that contradicts everything I said. The choice between static and dynamic typing involves real tradeoffs; there isn't a clear winner for every situation, domain, team, and project, you can "state" whatever you want, but that's just fundamental truth.

[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.).