Over the last 23 years of my career, I have concluded that there is no intrinsically bad or good paradigm; They’re just all different, each with their strengths

Over the last 23 years of my career, I have concluded that there is no intrinsically bad or good paradigm; They’re just all different, each with their strengths and weaknesses. Just as you wouldn’t kill a fly with a sledgehammer, you wouldn’t choose a big, heavy OOP language like Java to write up a simple script to copy some files around, would you? No, Python or Perl would be better suited for such things. But using scripting language for large Enterprise-level software begins to fall apart at some point. Suddenly you’ll find yourself wishing that you could name and encapsulate data structures, and then perhaps extend the functionality of a module, and you might even find yourself mimicking concepts of classical inheritance - and eventually you’ll end up with a mess that would have been much cleaner with some kind of OOP. Take Javascript, for example. In the days before ES6, many large JS Enterprise libraries were written with strange prototype hacks that did their best to mimic classical inheritance with varying degrees of success. A framework called Dojo tried solving this with convoluted constructs like “declare”; Whole transpiled languages like TypeScript and Coffeescript were created just to make it easier for developers to write “clean” classic OOP-style code. My point is, OOP is and has been useful in all manner of problem solving, and no matter how hard we try, we always come back to it in some way. Perhaps the question of why it’s so prevalent is misguided, driven by misunderstandings, culture, trends, and a desire to shun what’s old and promote what’s new.