I’m not very literate in CS; I don’t understand your characterisation of late OO as a request response paradigm. Isn’t calling a function or method to get a result just procedural programming 101?

Yes, it is, and OOP was all about message passing, not synchronous calls. The current incantation in pretty much all OOP languages (excepted maybe Smalltalk) is basically procedural programming with namespaces.

"All about message passing" was Alan Kay's vision of OOP, which was very distinct from what is considered OOP both before and after. He did coin the term "OOP" himself, though, so of course his definition carries a lot of weight, of course.

Even Simula, the original OOP language, is much closer to the procedural-ish OOP than to Smalltalk.

Genuine ignorant question: is this a language problem or a coding problem? I'm thinking of "sending a message" as a synchronous function call. Could you not code in a style that passes messages around?

Message passing has no response.

You can simulate request-response with it, using a channel to go one way and another the other way, but it can get pretty convoluted.

Understood, but could you not do this by coding style? I.e. calling a method returns void?

Whether something is already implemented in a language's core library, or a package you can use, or you build your own library, is immaterial. You can implement any patter with any turing complete language, and you can build your own language.

That's true, but I'm not really talking about that.

Correct me if I'm wrong, but you asked if message passing rests on language facilities or code style. Answer is neither. You can implement message passing patterns in Forth, in C, in Python, or you can use Erlang or Smalltalk and get it out of the box.

I wasn't making it exclusive. I think the answer is either, not neither.

The thing I wasn't asking was "can I implement a language that can do this in Java?" which is why I don't think the Turing completeness comment is particularly relevant.

Depends on neither is the same as 'you can do with either'. Just different ways to express the same answer.

That's exactly what they want to avoid.

The true goal of event-driven is the separation of concenrns, so you don't call `execute_payment`, `send_confirmation_email`, `include_in_report_dashboard` etc inside a `complete_order`.

Instead, you emit "order_issued" event and all subscribers can act based on the event, completely unknown from `complete_order`.

At least that is how I understand it.

Erlang, Objective-C, Ruby, JavaScript, CLOS still offer that as concept.

Then all the languages that support Component Programming via traits, interfaces, data classes, OS ABI like COM, or whatever they feel like calling it, do as well.

I suppose yes, if you disregard the state changes at the recipient.

Also, from the point of view of the caller it can be considered just a function call.