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.
OOP implicitly says it is ok to have stateful information all over the place in your code: if it's in an object, then it must be OK...
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.
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.
Distributed systems have other issues that are unrelated to message passing. Message passing is just a protocol for them to communicate but it's not what creates most issues with distributed systems like networking, state management, etc.
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.
> 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.
Software developers are highly trained and conditioned but poorly educated.
They live in the trees leaving the forest to the "experts".
As a result, they tend to "believe" as much as they reason and will accept "hype" and "opinion" as readily as proven science.
And they do so repeatedly --- OOP, AI, OSS, XML and cryptocurrency are all examples of this. They don't care where the next train is going, just give them a pseudo-plausible excuse and they will jump onboard.
I think you are generalising wildly here. My prior is that human beings are prone to hype and opinion in general. You'd need to provide some evidence that software developers are different from that in some important way for that to be significant.
Then to the substance of your points, firstly, there's nothing whatsoever wrong with jumping aboard new tech to see what it's like. As engineers our curiousity should be enough to make us want to do that. The fact that people are prepared to pay money for us to do so is a nice added bonus.
Secondly I have worked with software engineers of all kinds during my career and if you throw 10 different engineers in a room and ask their views on some technology you'll have some n>>1 and probably n>=10 opinions about it. There isn't some engineering hivemind that all thinks the same thing. People who are into a certain thing are vocal about it. If you asked engineers whethere they are into oop, functional programming, rust, react, whatever they are likely to be no less vocal about it than engineers who are into EDM, HipHop, Jazz, Metal or Taylor Swift. People like different things, engineers are people therefore engineers like different things.
Finally, we are in a new discipline so there isn't very much proven science and the way we get there is by experimentation. That means trying tech out and learning lessons from how things go wrong. Until that stage of maturity much of everything is opinion.
Clearly you don't know a lot of software developers. Or maybe you're right and I'm just lucky each time with my coworkers.
Also, adding OSS (and to a lesser degree, XML) to a list of 'hype' product is quite the reach. The first because Open Source is 50 years old and gained ground slowly, and the second because I don't think XML was ever trendy amongst developers. Maybe Ops, sec or management liked it, but devs? I recognize it's qualities but I'd rather hang myself with poorly formatted CSV (even with libraries to generate it: XML is a fucking pain to debug).
Open source is a programmer thing. And the blunt truth is that being a programmer doesn't mean you are particularly good at "design".
And design by a committee of programmers often isn't any real improvement. Just as an example, this is how you end up with a local desktop GUI running through the network stack.
In automotive terms, open source is kinda like a Russian military vehicle.
It's cheap and it may get you where you need to go but it can seem kinda industrial and unrefined, the gas mileage is poor and it's not really a joy to drive.
And consequently, you don't see too many of these on the highway.
> In automotive terms, open source is kinda like a Russian military vehicle.
The father of a highs school buddy had an old open top Soviet military jeep. He parked it in the streets.
He once told me it didn't have a key for the ignition. I asked if he wasn't worried about it getting stolen, seeing as it was open top and no keys needed to start it.
"Oh not at all. If they can figure out how to start it, they deserve it".
Apparently there was a 15 step ritual or something like that needed to get it to fire up.
Maybe people are searching for an "Answer" engine more so than an "Advertising" engine.
The concept of "relevance" is inherently corrupted by disguising ads as answers with their ranking/order sold to the highest bidder with additional income derived from mistaken/erroneous clicks.
reply