Could you elaborate on that? And would you say for instance that Rust suffers from the same problems? Because Rust offers many characteristics of OOP.
Distributed systems typically rely on messaging passing to some sort of "interface" in order to communicate and coordinate actions with remote nodes. Objects work much the same way and are designed to mimic the characteristics of an independent, remote computer node.
This can be done in any language that offers encapsulation of data, methods and state.
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.
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.
But again, more similarities than differences.
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 turns software into a message passing architecture, which definitely has its advantages if the software you need to write fits well into its compartmentalisation features.
Like you mention (and as with almost anything with software development) it's a trade-off, reasoning about the logic flow can be harder if the design of the OOP software is too convoluted but the same is absolutely true for a badly designed C code with function calls, I don't think OOP itself makes software harder to reason about but it has footguns with its features to make code unreadable through layers of indirection/delegation, badly designed inheritance models (which I tend to avoid nowadays, I really prefer composition over inheritance for most cases), etc.
This is my main beef with OO: a good design will have good clean statefulness, and getting there is completely orthogonal to how much object-orientation you got.
Good question. OOP seperates software into isolated units called "objects". But in order to function as a cohesive whole, these units have to communicate somehow. And this is usually where the fun begins.
OOP intentionally turns all software into a distributed system --- even if it is not distributed.
Whether there is any real advantage to this is a matter of opinion --- it can't be proven one way or the other. But in my experience with distributed systems, it is often less efficient and more difficult to see and reason about the logic flow and harder to debug and test. Your mileage may vary.