[kthielen]

> Just do some reasoning about the side effects.

"Wat?"

Have you ever inherited a 1MLoC codebase that you yourself didn't write from scratch, or worked on a large project with at least one other person? How do you know what the side-effects are and where they happen when you aren't intimately familiar with the code you're interacting with? That's the whole point of making effects explicit and available for analysis in the type system.

[QuadrupleA]

Are you saying you've inherited 1MLoC functional codebases, and due to their shining purity you haven't had to get familiar with them? Or haven't had to understand their "side effects", outputs / effects on the world?

Side effects are what you care about in a program. The simplest 8-bit CPU has side effects with every single instruction. It's baked into the bedrock, I don't think you can paper it over. Trying to shoehorn the complexity into nothing but function parameters and return values doesn't make the complexity go away, it just necessitates all these other weird contortions that add the complexity back twice over again.

[mathh]

Yes the good old days of spaghetti code where everything was simpler before it became complicated for me. Let me code my soup of ifs in methods returning void / Unit, there is nothing better, and that these FP lesson givers leave us alone.

[kthielen]

Ok but just make sure nobody else has to inherit it, and it’ll be fine.

[kthielen]

Yeah, some maintenance projects have been much easier than others. Implicit knowledge that you have to “just” hunt down is generally the cause of difficulty and delay. It has little to do with “purity” and more to do with not wasting my time.