To me, messaging is the most important part of "OOP", and "OOP" should have been Message Oriented Programming. Calling it object oriented programming and having

To me, messaging is the most important part of "OOP", and "OOP" should have been Message Oriented Programming. Calling it object oriented programming and having classes and inheritance made all of academia excited because you got to name and classify things. Object reuse was going to save the world, etc. Message oriented programming - that you need some kind of message protocol between two things to communicate is something we do a lot of, and has built huge systems like The Internet and all of our web services and JSON API's and all that jazz. The beauty of MOP is that once you have a format between two things, you can simply code to the format. We do this all the time with Web API's. The entire paradigm of microservices that is gaining popularity is really close to what Alan Kay was talking about when he created OOP. The biggest difference is microservices add network overhead complexity. If we built software as a series of Objects/Services/Containers that sent messages to each other over an enforced protocol, many of the OOP complaints go away because what is important is NOT the object, it's the communication protocol between objects that drives value. We have completely inverted the paradigm and lost a lot of value along the way. You don't need a lot to do message oriented programming. You need request/response formats, you need to enforce those formats, and you need a sender and receiver that do things on either end of the request-response. Erlang and the Actor pattern seems to be one approach to solving problems using this technique, microservices is another. I think there is a third option where you have contained objects/services/whatever running in the same program sending simple data structures like hashes as messages back and forth to each other. It would work well as long as you have code to enforce the message protocol between things(right data format, nil checks, etc). That approach could be done in OO languages like Ruby, Java, C++, PHP, Python, etc. OR it could be done in FP languages like Clojure, LISP, etc. It's not complicated, it's just applying the request-response pattern to connect objects/processes/code together in a sane way. Sort of like UNIX pipes on the command line. Sort of like HTTP. Sort of like a lot of things we use, but don't seem to think would be good patterns for code.