> till I realized that anything taken to an absurd degree is absurd
Whenever I see OOP taught, the expectation is that every non-primative is an object in a massive hierarchy. If the default is an absurd degree, what does that say?
If the default level is good, and some people take it to absurd counterproductive levels, you need to give a bit of a warning.
If the default level is absurd and counterproductive, but using a fraction that much is good, you need to approach the conversation in an entirely different way and "OOP is bad" is kind of correct and important to address.
We want to be able to say that one type of OOP is good and another is bad with relatively specific examples. We should have different terms for those types.
You did the equivalent of replying to someone talking about nutritional tactics with "tl;dr eat healthy". Yeah, figuring out healthy is why we're here, looking at these different techniques and sub-techniques and figuring out at what point they become counterproductive.
I actually had a great professor who'd worked at Microsoft during the dark ages, and taught OOP with very sensible "this can get way out of control if you drink the cool-aid" warnings.
I also had a different professor that preached FP to an absurd degree, literally refusing to accept work that had a "too much OOP" flavor to it. Bad teaching and practices exist anywhere, hence my TLDR at the top.
TLDR; bad code practices make bad code.
I think that this is confined to people who have a functional programming fetish, and those that worked at companies that drank the "OOP cool-aid" back in the late 90's early 2000's and built their codebase into massive, sprawling, strictly hierarchical monstrosities... I may have worked for one of these, and hated OOP with a passion till I realized that anything taken to an absurd degree is absurd.
If we all just orient our models in relationships that make sense for what they do, OOP is fine.