What I learned from the object-oriented fad was that it doesn't matter: many developers will write bad code no matter what.<p>Making it easier to focus on low coupling and high cohesion (the retconned goals of OO since those principals were pulled into software about the same time simula was created) is not enough. Software writers actually have to do it, and do it without over-complicating what they've written.
A great way to avoid these manias is to constantly appreciate the importance of how a program is mechanically executed by the processor.<p>For example, in OOP that means do you know what vtables are doing in C++ or how method dispatch works in Java? In Erlang do you know why those linked lists are like that and how it interacts with the garbage collector? Do your functional constructs for the JVM spit out nice optimised code or are they spamming all over the heap?<p>The moment people lose touch with these things they become highly susceptible to the nonsense that follows, as basically once you have made that leap everything is just magic.
> <i>Rapid Spread, Amplification, Peer Influence, Conformity, ..</i><p>A nice list of features, and you can apply it to nearly every hype we observe (today e.g. AI, or memory safety, or climate, or gender, etc.). There doesn't seem to be a good idea or intention that doesn't eventually lead to Cargo Cult; seems to be part of human nature. And Cargo Cult has various forms and intensities, right up to sects and totalitarian social systems. OO is just a way to structure code, no more, no less.
I like this article.<p>Complexity is the biggest challenge we face in most systems and OOP is a great way to manage it... sometimes.<p>But it winds up being <i>suuuuuuuch</i> a leaky abstraction much of the time, and when applied blindly it creates more cognitive overhead than it purports to solve.
A very abrupt ending to what could have been a very educative text aimed at people who want to know 'what to choose', how to reason, and where we are currently at. I'd love to read more.