Sometimes the best way to decide what to do, is a OOP-like 100,000 line long legal code. Sometimes the best way to decide what to do, is something short and sw

Sometimes the best way to decide what to do, is a OOP-like 100,000 line long legal code. Sometimes the best way to decide what to do, is something short and sweet yet possibly not entirely clear, like the Ten Commandments. When what the original designers chose was correct, everything will work quickly and reliably. When they don't, you'll suffer for a long time. Given that, you'll spend almost all of your wall clock time suffering and complaining about the designers selection being wrong. With a side effect of most of your suffering will be due to poorly implemented examples of the dominant paradigm. "AKA OOP SUX" In summary, given all of the above, there are two true statements that OOP works AND simultaneously you'll spend almost all of your mental effort on OOP not working. Generally, OOP being inappropriately hyper dominant at this time, means that non-OOP solutions will utterly master some very low hanging fruit for first movers who abandon OOP. I've seen some truly horrific object relational mappers trying to connect OOP to inherently functional software APIs, hardware device interfaces, "chronological engineering" in general, and persistent data stores. Not surprising if you're working in those areas, abandoning OOP will lead to massive success.