4 ms·

> Point is, a lot of what Kay says is obvious now It's obvious because he's not saying much, besides trying to redefine "function call" with "message passing"

> Point is, a lot of what Kay says is obvious now It's obvious because he's not saying much, besides trying to redefine "function call" with "message passing" so that it makes Smalltalk look better.

mpweiher 11y ago
So if "function call" and "message passing" are the same thing, why does Erlang support both?
- contingencies 11y ago
  Guesstimate: Message passing implies a fully self-encompassed message carrying enough meaning for potential distribution between systems? [Substitute: Erlang VMs, physical machines, or whatever] Function call typically means within the same interpreter instance / language virtual machine / operating system native process. (ie. in cases where parallelism exists or is warranted, a message passing model enables it. In cases where it does not, they are essentially the same, possibly message passing being slightly slower due to marshalling/encode/decode overheads. These days that overhead is usually irrelevant and thus message-orientation is a plus, as it encourages smaller components and thereby helps to bring clearer architectural paradigms to complex systems)
- vlastachu 11y ago
  tell me about message passing without concurrency. is it message passing in ruby? and why.
  - mpweiher 11y ago
    Message passing in KO (Kay Objects) is always inherently concurrent. After all the object abstraction is "individual computers all the way down"[1], and with separate computers, I hope we agree to call the message asynchronous. Anyway, mapping the passing of messages to synchronous lookup of a method in Smalltalk was always an optimization purely out of expediency. Highly important at the time so they could get real systems running on their "Interim Dynabooks" (aka Altos, 128K DRAM, 5.8 MHz[2]), and try them out. However, the ability to do a full message-send was always retained in systems like Smalltalk and descendants such as Objective-C and Ruby, with the DNU hook turning the message that only exists in pieces on the call stack into a bona-fide object (Message in Smalltalk, NSInvocation in Objective-C). And lo and behold, these hooks were and are used to implement asynchronous, remote and other forms of messaging. So to answer your question: yes, what Ruby, Smalltalk and Objective-C do is message passing. It is probably on the extreme end of what can still be considered KO-style message passing, which to me means it is late-bound and an object representing the message for further processing can be recovered easily. [1] http://worrydream.com/EarlyHistoryOfSmalltalk/ http://worrydream.com/EarlyHistoryOfSmalltalk/ [2] http://www.cpushack.com/2010/10/18/before-the-pc-before-apple-was-the-xerox-alto/ http://www.cpushack.com/2010/10/18/before-the-pc-before-appl...
cconroy 11y ago
In a function call the arguments are applied to the function after being evaluated (LISP's apply). In Message Passing a message (which is just another object) is sent to the receiver object. The crucial difference is in a function call the the function is already bound when the args are sent. With message passing the args are sent to the receiver object which can handle them there or up its superclass hierarchy -- with the ability to handle messages it does not recognize too after exhausting the superclass hierarchy. The smalltalk blue book has the VM implementation of message sending which is very straight forward.
- pacala 11y ago
  The distinction is mostly of historical relevance, being relevant to the time where function names were bound at link time in mainstream systems. In a modern system, Java/C#/Python/Javascript/..., we take for granted that function names are bound at runtime. "Calling a function into a module/object" means having the module resolve the function name, then execute the function. Messaging is an implementation detail, just like vtables are another way to implement this idea.
  - jacquesm 11y ago
    That's a fundamental difference which allows a whole pile of stuff to happen that otherwise would be either hard or impossible. Messaging versus parameter passing is an entirely different beast that for instance (but not limited to) allows you to send the message to another process for handling and that other process could (theoretically) live on another host. Smalltalk has a lot of nifty stuff under the hood and never managed to realize even a fraction of its potential due to all kinds of factors none of which have anything to do with the core ideas of the language. Message passing is a game changer, and is in no way equivalent or comparable to calling functions with a bunch of parameters though implementing that using message passing is trivial. The runtime binding aspect is only one detail, and not the most important one at that.
    - dang 11y ago
      > The runtime binding aspect is only one detail, and not the most important one at that. What are some of the others?
chriswarbo 11y ago
The implication of "function call" is that we're calling a particular function (eg. in `square(x)`, `square` is a function). The implication of "message passing" is that we're only providing a name (eg. in `square(x)`, `square` is a name). This name is used to look up a function just-in-time, and the mapping may be altered arbitrarily during the course of the program. To me, it's like a half-way-house between first-order (functions and variables are distinct) and higher-order programming (functions are a sub-set of variables).
- sjolsen 11y ago
  Other differences between message passing and function calls aside, I disagree with this characterization. While many mainstream languages perform static binding of functions, it is not an inherent feature of functions (at least as I personally have come to understand them); the canonical example is Common Lisp's generic functions, which behave in almost exactly the way you describe message passing. I think no small part of the disagreements in this thread can be attributed to people simply having different notions of what phrases like "function call" mean, with some envisioning invoking a statically resolved, monotyped C-style subroutine, and others a more abstract notion of issuing a command to perform a computation with an understood set of semantics on a provided collection of data. The latter is what I think of a function as in a computational context, and from what I've gathered from the other comments here, a fair approximation of what is typically meant by "message passing." Now, there's something to be said for differences like the treatment of synchronization and process boundaries, but I'm inclined to categorize those as the same sort of pragmatic-but-technically-untrue distinctions as that between so-called "compiled languages" and "interpreted languages." Certainly there is at the very least an isomorphism to be established between the two conventions, given access to threads, promises, and some form of IPC.

> Point is, a lot of what Kay says is obvious now It's obvious because he's not saying much, besides trying to redefine "function call" with "message passing" so that it makes Smalltalk look better.

mpweiher 11y ago

So if "function call" and "message passing" are the same thing, why does Erlang support both?

contingencies 11y ago
Guesstimate: Message passing implies a fully self-encompassed message carrying enough meaning for potential distribution between systems? [Substitute: Erlang VMs, physical machines, or whatever] Function call typically means within the same interpreter instance / language virtual machine / operating system native process. (ie. in cases where parallelism exists or is warranted, a message passing model enables it. In cases where it does not, they are essentially the same, possibly message passing being slightly slower due to marshalling/encode/decode overheads. These days that overhead is usually irrelevant and thus message-orientation is a plus, as it encourages smaller components and thereby helps to bring clearer architectural paradigms to complex systems)
vlastachu 11y ago
tell me about message passing without concurrency. is it message passing in ruby? and why.
- mpweiher 11y ago
  Message passing in KO (Kay Objects) is always inherently concurrent. After all the object abstraction is "individual computers all the way down"[1], and with separate computers, I hope we agree to call the message asynchronous. Anyway, mapping the passing of messages to synchronous lookup of a method in Smalltalk was always an optimization purely out of expediency. Highly important at the time so they could get real systems running on their "Interim Dynabooks" (aka Altos, 128K DRAM, 5.8 MHz[2]), and try them out. However, the ability to do a full message-send was always retained in systems like Smalltalk and descendants such as Objective-C and Ruby, with the DNU hook turning the message that only exists in pieces on the call stack into a bona-fide object (Message in Smalltalk, NSInvocation in Objective-C). And lo and behold, these hooks were and are used to implement asynchronous, remote and other forms of messaging. So to answer your question: yes, what Ruby, Smalltalk and Objective-C do is message passing. It is probably on the extreme end of what can still be considered KO-style message passing, which to me means it is late-bound and an object representing the message for further processing can be recovered easily. [1] http://worrydream.com/EarlyHistoryOfSmalltalk/ http://worrydream.com/EarlyHistoryOfSmalltalk/ [2] http://www.cpushack.com/2010/10/18/before-the-pc-before-apple-was-the-xerox-alto/ http://www.cpushack.com/2010/10/18/before-the-pc-before-appl...

cconroy 11y ago

In a function call the arguments are applied to the function after being evaluated (LISP's apply). In Message Passing a message (which is just another object) is sent to the receiver object. The crucial difference is in a function call the the function is already bound when the args are sent. With message passing the args are sent to the receiver object which can handle them there or up its superclass hierarchy -- with the ability to handle messages it does not recognize too after exhausting the superclass hierarchy. The smalltalk blue book has the VM implementation of message sending which is very straight forward.

pacala 11y ago
The distinction is mostly of historical relevance, being relevant to the time where function names were bound at link time in mainstream systems. In a modern system, Java/C#/Python/Javascript/..., we take for granted that function names are bound at runtime. "Calling a function into a module/object" means having the module resolve the function name, then execute the function. Messaging is an implementation detail, just like vtables are another way to implement this idea.
- jacquesm 11y ago
  That's a fundamental difference which allows a whole pile of stuff to happen that otherwise would be either hard or impossible. Messaging versus parameter passing is an entirely different beast that for instance (but not limited to) allows you to send the message to another process for handling and that other process could (theoretically) live on another host. Smalltalk has a lot of nifty stuff under the hood and never managed to realize even a fraction of its potential due to all kinds of factors none of which have anything to do with the core ideas of the language. Message passing is a game changer, and is in no way equivalent or comparable to calling functions with a bunch of parameters though implementing that using message passing is trivial. The runtime binding aspect is only one detail, and not the most important one at that.
  - dang 11y ago
    > The runtime binding aspect is only one detail, and not the most important one at that. What are some of the others?

chriswarbo 11y ago

The implication of "function call" is that we're calling a particular function (eg. in `square(x)`, `square` is a function). The implication of "message passing" is that we're only providing a name (eg. in `square(x)`, `square` is a name). This name is used to look up a function just-in-time, and the mapping may be altered arbitrarily during the course of the program. To me, it's like a half-way-house between first-order (functions and variables are distinct) and higher-order programming (functions are a sub-set of variables).

sjolsen 11y ago
Other differences between message passing and function calls aside, I disagree with this characterization. While many mainstream languages perform static binding of functions, it is not an inherent feature of functions (at least as I personally have come to understand them); the canonical example is Common Lisp's generic functions, which behave in almost exactly the way you describe message passing. I think no small part of the disagreements in this thread can be attributed to people simply having different notions of what phrases like "function call" mean, with some envisioning invoking a statically resolved, monotyped C-style subroutine, and others a more abstract notion of issuing a command to perform a computation with an understood set of semantics on a provided collection of data. The latter is what I think of a function as in a computational context, and from what I've gathered from the other comments here, a fair approximation of what is typically meant by "message passing." Now, there's something to be said for differences like the treatment of synchronization and process boundaries, but I'm inclined to categorize those as the same sort of pragmatic-but-technically-untrue distinctions as that between so-called "compiled languages" and "interpreted languages." Certainly there is at the very least an isomorphism to be established between the two conventions, given access to threads, promises, and some form of IPC.