3 ms·

This! I never understood the why for this 'send-a-message' way of talking when what I do is really call a function that may or may not affect the state (of the

This! I never understood the why for this 'send-a-message' way of talking when what I do is really call a function that may or may not affect the state (of the object it is being called on or any other object).

masklinn 5y ago
> I never understood the why for this 'send-a-message' way of talking when what I do is really call a function Because you don’t, dynamic dispatch means you don’t know and are not supposed to care how the object handles or responds to the message. That is maybe more flagrant in Self.
- codeflo 5y ago
  But you’re describing indirection, not message passing. Is that the source of the confusion? Even C has indirection.
  - masklinn 5y ago
    1. C does not have only indirection. 2. Message passing is an ideal, an ethos, the implementation (or the interface) can get in the way of that. That the messages are implemented as dynamically dispatched function calls… would be an implementation detail. Though with far ranging implications of course (especially in that the response is direct and synchronous rather than an other message as it would be in, say, Erlang). The mention of Self was not innocent, though it does use synchronously dynamic dispatch, a message might invoke a block, or just set or retrieve a value. If you’re asserting that it’s all « calling a function » then you’re basically just reductio at absurdum-ing everything to calling functions which… sure? You can model and reduce everything to lambda calculus.
    - codeflo 5y ago
      > That the messages are implemented as dynamically dispatched function calls… would be an implementation detail. Though with far ranging implications of course It can't both be only an implementation detail and also have far reaching consequences. (It's not an implementation detail.) > You can model and reduce everything to lambda calculus. You actually can't, that's precisely my point. Lambda calculus is inherently "synchronous". You can't capture the full semantics of actual message passing with lambda calculus, you need a process calculus (like pi calculus) for that. (In case you're confused, this has nothing to do with Turing completeness, it's about modeling the behavior of concurrent systems. It's a really interesting subject.) The point is, lambda calculus is sufficient to model OOP method calls, including everything in Smalltalk and Self. It's not sufficient to model the semantics of Erlang messages.
    - ProfHewitt 5y ago
      Concurrent computation is not reducible to the lambda calculus. See https://papers.ssrn.com/abstract=3603021 https://papers.ssrn.com/abstract=3603021
- geofft 5y ago
  Dynamic dispatch just means you're calling a function that happens to call another function. You're still calling a function. I don't think "You don't know the implementation" implies you're not calling a function - otherwise we'd have to say that when you use a shared library like OpenSSL, you don't "call" SSL_CTX_init(), you pass a message to the OpenSSL library, which might be 1.1.0 or 1.1.1 or even BoringSSL. But nobody would say that - it's obviously a function call. (I suppose you could defensibly argue that a system call is message passing, at least on some OSes, but that's about it.)
  - codeflo 5y ago
    You're absolutely correct, of course. I have no idea why obvious facts are downvoted to hell in this thread.

masklinn 5y ago

> I never understood the why for this 'send-a-message' way of talking when what I do is really call a function Because you don’t, dynamic dispatch means you don’t know and are not supposed to care how the object handles or responds to the message. That is maybe more flagrant in Self.

codeflo 5y ago
But you’re describing indirection, not message passing. Is that the source of the confusion? Even C has indirection.
- masklinn 5y ago
  1. C does not have only indirection. 2. Message passing is an ideal, an ethos, the implementation (or the interface) can get in the way of that. That the messages are implemented as dynamically dispatched function calls… would be an implementation detail. Though with far ranging implications of course (especially in that the response is direct and synchronous rather than an other message as it would be in, say, Erlang). The mention of Self was not innocent, though it does use synchronously dynamic dispatch, a message might invoke a block, or just set or retrieve a value. If you’re asserting that it’s all « calling a function » then you’re basically just reductio at absurdum-ing everything to calling functions which… sure? You can model and reduce everything to lambda calculus.
  - codeflo 5y ago
    > That the messages are implemented as dynamically dispatched function calls… would be an implementation detail. Though with far ranging implications of course It can't both be only an implementation detail and also have far reaching consequences. (It's not an implementation detail.) > You can model and reduce everything to lambda calculus. You actually can't, that's precisely my point. Lambda calculus is inherently "synchronous". You can't capture the full semantics of actual message passing with lambda calculus, you need a process calculus (like pi calculus) for that. (In case you're confused, this has nothing to do with Turing completeness, it's about modeling the behavior of concurrent systems. It's a really interesting subject.) The point is, lambda calculus is sufficient to model OOP method calls, including everything in Smalltalk and Self. It's not sufficient to model the semantics of Erlang messages.
  - ProfHewitt 5y ago
    Concurrent computation is not reducible to the lambda calculus. See https://papers.ssrn.com/abstract=3603021 https://papers.ssrn.com/abstract=3603021
geofft 5y ago
Dynamic dispatch just means you're calling a function that happens to call another function. You're still calling a function. I don't think "You don't know the implementation" implies you're not calling a function - otherwise we'd have to say that when you use a shared library like OpenSSL, you don't "call" SSL_CTX_init(), you pass a message to the OpenSSL library, which might be 1.1.0 or 1.1.1 or even BoringSSL. But nobody would say that - it's obviously a function call. (I suppose you could defensibly argue that a system call is message passing, at least on some OSes, but that's about it.)
- codeflo 5y ago
  You're absolutely correct, of course. I have no idea why obvious facts are downvoted to hell in this thread.