> This passertion is disingenuous. The whole point is that the reason why bad code is bad is not because it's OO, it's because it's bad code.
This is pretty false on its face. Let's say that some paradigm insists that inheritance should be used for every problem. Almost all programmers agree that this is bad code, thus code written in this paradigm is bad because of the paradigm.
> You do not fix bad code by switching programming paradigm, specially if it's to move back to procedural programming and wheel reinvention due to irrational class-phobia.
Agreed. Instead you should start with your current paradigm and remove the problematic aspects until you're left with something that works reasonably well. I posit that when you start with OO and drop its problematic aspects like inheritance or Armstrong's observation of banana-gorilla-jungle architecture, you end up with something that looks pretty functional or data-oriented, a la idiomatic Go or Rust. If your definition of "OO" already excludes these things, then it probably looks something like Go or Rust or perhaps even Erlang.
The issue I'm raising with "OO" is that there is no consensus about what OO is; rather every defense of OO is about what it isn't (and then there's the ever predictable straw man, "But you can write bad code in any paradigm!").
This is pretty false on its face. Let's say that some paradigm insists that inheritance should be used for every problem. Almost all programmers agree that this is bad code, thus code written in this paradigm is bad because of the paradigm.
> You do not fix bad code by switching programming paradigm, specially if it's to move back to procedural programming and wheel reinvention due to irrational class-phobia.
Agreed. Instead you should start with your current paradigm and remove the problematic aspects until you're left with something that works reasonably well. I posit that when you start with OO and drop its problematic aspects like inheritance or Armstrong's observation of banana-gorilla-jungle architecture, you end up with something that looks pretty functional or data-oriented, a la idiomatic Go or Rust. If your definition of "OO" already excludes these things, then it probably looks something like Go or Rust or perhaps even Erlang.
The issue I'm raising with "OO" is that there is no consensus about what OO is; rather every defense of OO is about what it isn't (and then there's the ever predictable straw man, "But you can write bad code in any paradigm!").