[arendjr]

Thanks! I would just like to clarify I’m actually not opposed to OOP at all, and at several points I tell people it’s fine to go in that direction for the problems where you need it. I do try to warn against it as a go-to solution before you’ve understood what are the problems that actually need fixing, which it sounds like we’re pretty aligned on.

Indeed if you pass by value/use immutability where feasible, you already avoid most of the issues I’m warning against, so it sounds like you found a sensible way to apply it while avoiding the pitfalls.

> If I have to give a taxi driver a jerrycan full of petrol, that's the definition of a leaky abstraction... Possibly literally in this case.

:D

[cryptica]

My view on FP is that one of its main benefits in terms of avoiding bugs is that it forces you to turn all your 'movable state' into raw messages. The fact that it also abolishes 'unmovable state' is just a quirk of it, not necessarily a benefit.

My main point in support of OOP is that OOP doesn't prevent you from making all your 'movable state' into raw messages too. Properly encapsulated instance state is not dangerous. What I like about OOP is that it offers some additional benefits in terms of high cohesion and loose coupling because co-locating logic with related state helps to write high cohesion, loosely coupled modules. It reduces the amount and complexity of state that needs to be transferred between modules. It allows my messages and function/method signatures to be even leaner than FP allows.

If you want to catch a taxi to the airport, FP still requires that you bring a jerrycan of fuel and steering wheel to give to your taxi driver, the only restriction is that he cannot alter them (no mutations). The benefit of this is that you can fully trust that the integrity of your jerrycan and steering wheel has been maintained after the trip and you can then confidently re-use them for your airplane as well... Anyway, as elegant as that seems in theory, it's not quite how the world works.