[bigDinosaur]

Pretty poor attitude to just adopt so generally. I've seen 'actively harmful' qualities from all paradigms. Once peoples start adopting attitudes like yours they've just become the mirror of the condescending FP type and just kill outright any of the really cool features that are useful, as well as any discussion of them.

[wokwokwok]

Do whatever you want with your own code bases; my responsibility is to make the ones I work on maintainable by other people.

/shrug

[cpursley]

Some of us don't find OOP code maintainable.

[wokwokwok]

It doesn’t matter if it’s FP or OOP.

Here’s the real question: do you think dense code is more maintainable?

Generally yes? More than a verbose multilayered abstraction, probably?

…but where do you draw the line? Map statements instead of for loops? Collapse all the white space onto a single 200 character line? Make everything one big regex?

Dense code means that every change has more impact, because there’s less code; it’s unavoidable: less code to do the same work means more impact from changing any part of that code.

That is why it’s difficult to maintain; because you can’t touch it without making side effects; you can’t reason about a small part of the code, because the logic is dense and difficult to unpack into small parts.

Certainly OOP can often be verbose and annoying, but that’s a different thing.

Code density and being functional are orthogonal; some OOP is too dense too. …but generally I’ve found that inexperienced people see density and strive for it, believing this makes it functional; but the truth is the opposite.

Good functional programming is often naturally concise, but most people don’t actually seem to understand FP.

They just seem think it means to put more “reduce” statements in the code, remove for loops and generally make the code harder to debug and denser.

…in my, limited experience, working with lots and lot of different folk at many different organisations.

[cpursley]

For me it's not density - it's the OOP class abstractions and all that. I'm not smart enough to keep up with it vs the FP approach of just doing data transformations.

[CharlieDigital]

I think of OOP done well at a high level as "structural logic". Whereas in FP, one might use `map()` and `bind()` to replace complex imperative logic flows, in OOP, this is done with object hierarchies and structures.

When you have a abstract base class or an interface that defines some contract, it's creating a "shape" that defines how an instance of the class can be used.

I think that this might be why some folks have an affinity for OOP and some have an affinity for FP. OOP affinity might be tied to more visual thinkers. For me, I see the "shapes" of the code defined by the contracts.