I think we are very much on the same page Alexis. As you say, people can define OOP in different ways. What I tried to show here is that what we call OOP today is not the original definition or idea of OOP.
And that is fine, mostly. Words change in meaning and that is something we have to relate to. But I think it is worth bringing up when people characterize OOP as the best thing since sliced bread and hold up Java as some sort of excellent example of OOP. Today OOP has become a word for Java-like. That is fine, as long as people don't start to claim that being Java-like is inherently a good thing.
About real-time updates, it depends on what granulaity and context we are talking about. You have to be able to look at systems at different levels of abstraction.
The whole internet itself can in the Alan Kay sense be looked at as objects (the servers) sending messages to each other (over wires with TCP/IP).
Thus you can view the internet as one system. Just like you can view the environment on a single computer as a system.
At the internet level we do indeed to real-time updates. Nobody shuts down the whole internet when they add another computer to the network.
Likewise you don't shut down the whole OS, when you add another piece of software.
When you make a mobile application or a lot of server stuff, then you are frequently using lots of cloud services. All of these parts gets replaced live. If my application uses Facebook authentication, then I can change my application without shutting down all of Facebook.
This is possible because we are strongly decoupled and communicating only through messages and keep our state separate. That is the Alan Kay idea of OOP. Isolated objects with their own isolated state and isolated execution, communicating through messages.
I think Erlang is probably the only well known language which really incorporates these principles at a language level. With Erlang you split your system into hundreds or thousands of Erlang processes which have independent execution and state communicating through messaging just like servers on the internet.
That is what gives it high fault tolerance. One Erlang process can crash, and it doesn't bring the whole system down. Another monitoring process can bring it back up.
As for modifying production systems. The key part here is about whether you want to expose to a customer what experiments you are doing with the code. You don't want that. But that doesn't mean you cannot use this model while you are developing software, as long as you hide those changes to the customer by running development server not visible from the outside.
