In the real world, where many people of varying backgrounds and skill levels are editing the same code, if the OOP method becomes a mess, why wouldn’t the functional approach also become a mess? I think that is more the point OP was making. In a vacuum with a single perfect Adonian programmer, seems like the OOP and functional approaches would becomes the same level of maintainable, because we’re in a vacuum of perfection anyway.
In my experience, the mess created using OOP is harder to untangle than the mess created using a functional approach. With the latter, it's simpler to replace a different function for any part of the logic, and the data is always just data; whereas with OOP the method is usually tied up with shared state and other functions.
> In my experience, the mess created using OOP is harder to untangle than the mess created using a functional approach.
OP complained about accidental complexity, not subjective takes on how hard it is to refactor code.
Even so, anyone who has any cursory experience with TypeScript projects that follow a functional style can tell you without any doubt whatsoever that functional style is incomparably harder to refactor than any "enterprise-grade" OOP.
> Even so, anyone who has any cursory experience with TypeScript projects that follow a functional style can tell you without any doubt whatsoever that functional style is incomparably harder to refactor than any "enterprise-grade" OOP.
My experience differs greatly. One can see functional style has taken off in the TS world, particularly with the popularity of React, so I suspect I'm not alone.
