As a professional dev who has made a career out of working in oop languages and codebases, I agree, and it took me far too long to realize that when it comes to

As a professional dev who has made a career out of working in oop languages and codebases, I agree, and it took me far too long to realize that when it comes to oop, the emperor has no clothes. To this day, oop advocates can't even agree on what oop even is or means. Apparently oop as envisioned by Alan Kay was supposed to work like cells in the body that pass messages between each other and take actions independently. Why? Who knows! It was never really explained why literally one of the most complex systems imaginable, one that we still really have very little idea how it even works, should be the model for what could and should probably be a lot simpler. Today's modern oop languages are probably very far from what Kay envisioned (whatever that was), but it's remains unclear why classes and objects are "better" than the alternatives. And before anyone goes and comments aksully code organization blabla like yes but code organization can be great or shit in oop or fp or procedural codebases, it has nothing to do with the "paradigm". Let alone that the entrenched, canonical, idiomatic coding styles of most modern oop languages encourage state, mutability, nulls, exceptions and god knows how many trivially preventable entire classes of errors. Granted, most have now started to come around and are adopting more fp features and ideas every year, but still. --- EDIT tacking on other old comments: --- Don't get me wrong, writing programs like cells in the body that pass messages between each other and take actions independently is an interesting idea which deserves pursuing, if nothing else but to satisfy our curiosity and seeing to what if anything it's applicable and suited. (and even if the answer turns out to be "nothing", we've still learned something!) But going from there to making strong claims about it being a more or less universally superior paradigm for computing and writing code, with little to zero evidence, that's a huge, huge stretch. To the degree Erlang and Actors work, I think that's kind of a happy coincidence, and not due to any rigorous work on Alan Kay's part. --- Just look at all the "OOP" languages where both the language developers and the user community are coming around to the facts that * immutability and absence of state is preferable to mutation and statefulness * Option/Maybe types (or "nullable types" which are a shoddy implementation of the same thing) are better than null * Either/Result types are better than exceptions * making things implement map, filter etc and sending in a function that describes what you want to do is better than manually eg looping through lists etc etc etc etc Anyone who doubts how endorsed this is, just read what Brian Goetz and Josh Bloch have to say about how to code in Java. Just imagine if these languages had been implemented with these ideas in mind from scratch instead of the current situation of trying to adopt and retrofit this style when the core libraries fundamentally don't support it. The current trend of "OOP" languages is basically inexorably heading towards FP and abandoning the old school "OOP" style. Eventually they will only be nominally "OOP", mostly in order to please people who have irrational attachments to labels like that, but be way more FP in nature and in all but name. For what it's worth, people shouldn't be irrationally attached to the "FP" label either. Labels aren't important - what matters is the code, how easy or hard it is to reason about it, how well it avoids entire categories of defects from even being possible etc etc. https://proandroiddev.com/kotlin-avoids-entire-categories-of-java-defects-89f160ba4671 https://proandroiddev.com/kotlin-avoids-entire-categories-of...