Many misleading statements here (paraphrased): With imperative code, you can just hop up the stack! ...unless something screws up your stack frames, in which

Many misleading statements here (paraphrased): With imperative code, you can just hop up the stack! ...unless something screws up your stack frames, in which case you win nothing good day sir. With OOP code, you alternate framework code with application code, which never happens with imperative libraries! ...except any sort of nontrivial library that has proper abstraction via callbacks, in which case you very much do end up alternating application code with libraries. Inheriting from a framework object can do things you don't expect! ...except that in languages that aren't C++, it's usually pretty easy to control whether or not you execute parent class code instead of/in addition to your extended function. The technical term for a programming paradigm which uses neither inheritance nor instance variables is imperative (or functional) programming. ahahahahha what? no. Imperative != functional programming. At all. Had a CTO try to convince me this was case, was dead wrong. Imperative code allows for mutation of global state and perhaps no functions-as-first-class-citizens. Functional code (in theory) allows for no mutation of global state and always has functions-as-first-class-citizens. Author has also left out declarative languages, which also somewhat fit that definition, but hey, who's counting? The best way to illustrate the issue with debugging multi-threaded programs is to describe the debugging scenario as consisting of multiple stacks. What? Fuck no. The biggest issue with debugging multi-threaded programs is having shared mutable state. The fact that thread A can write and screw up something depended upon by thread B, which is totally supported in imperative programming and is hard to protect against, is the problem. Second would be the magic of race conditions, live locks, dead locks, and all of that jazz. OOP is, other than pure functional programming, perhaps the only sane way of dealing with mutlithreaded programs when you aren't subscribing whole-hog to actor-style message passing. ~ This is a bad article, and displays both a fundamental lack of understanding as well as a sort of arrogance in the profession of the aforementioned ignorance. EDIT: And no, OOP/actor programming is not a panacea for all of your problems either. There is quite a lot of room in the world for simple imperative programs (which are basically objects interfaced with from the command line) or chained functional programs (very useful for data transformation pipelines). That said, there are reasons why we invented OOP. There are use cases for it. There are places where it is the right thing, and to pretend otherwise makes it all the harder to know when not to use it.