> OOP intentionally turns all software into a distributed system
OOP does have a message-passing version, but even though the coiner of the term prefers this version, no one in the industry used it that way.
The industry settled on method calls as the primary channel for these messages, which are most of the way a form of synchronous communication on the same thread, quite far from being a distributed system.
Object `a` calling a method from object b’s public API is not a distributed system at all. And while I do agree that this cohesive whole is not necessarily represented in OOP, one solution is to create an object over the whole, that itself upholds the necessary conditions/order/etc between its subcomponents, exposing only a higher level API to the outside world, and making those subcomponents otherwise inaccessible.
I think there's more in common than you give credit for.
What is the fundamental difference between a 'method call' and a 'message pass'?
In both scenarios, you can be synchronous or asynchronous, blocking or non-blocking, remain on one thread (technically 2 if it's across a network) or fork out into multiple threads. You can wait for a result, or you can fire-and-forget (void). A networking problem is just another kind of Exception.
Even in a typical microservice codebase, it's not immediately apparent from reading the code whether userService.createUser() will call across a network, or just into another class.
The only fundamental difference I can think of right now is that in a non-networked system, you can be pretty sure your static typing holds for the whole program, whereas in a networked system, your types might drift between versions.
I think the similarity is more like a mathematical/structural one, and doesn’t hold much water in a pragmatic sense. The possible error conditions for a network call are just insanely bigger than of a function call.
Also, Smalltalk and alia of the “real OOP” kind has some extremes with regards to messaging, like the number 3 being told to increase itself by one, which would not be done this way in today’s OOP languages and not just for performance reasons.
Method calls are more of a degenerate case of a distributed system, which is significantly easier to reason about.
OOP does have a message-passing version, but even though the coiner of the term prefers this version, no one in the industry used it that way.
The industry settled on method calls as the primary channel for these messages, which are most of the way a form of synchronous communication on the same thread, quite far from being a distributed system.
Object `a` calling a method from object b’s public API is not a distributed system at all. And while I do agree that this cohesive whole is not necessarily represented in OOP, one solution is to create an object over the whole, that itself upholds the necessary conditions/order/etc between its subcomponents, exposing only a higher level API to the outside world, and making those subcomponents otherwise inaccessible.