4 ms·

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)

by 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?
    - jacquesm 11y ago
      - messages are asynchronous, function calls are (pretty much by definition) synchronous - messages do not require a reply (but function calls typically do expect a result) - messages are a lot more secure in that the credentials of the sender can be inspected by the recipient which can be walled off in a different area of memory or even on a different machine - message based architectures are easier to scale than function call based architectures - message based architectures tend to have higher overhead per message than a function call with the same payload and return value - message based architectures tend to lend themselves to soft real time approaches better than monolithic threaded software using functions as the main means of passing data around - message based architectures tend to be more reliable - message based architectures typically allow for things that are next to impossible in a function based environment, such as process migration and load balancing as well as coping with hardware failures - message based architectures are easier to debug (by far) than large systems built up using nothing but function calls. - message based systems tend to be a bit slower, especially if they take the message idea all the way to the lowest levels of the language (such as in smalltalk). Really, the differences are legion. I've built some stuff using message passing that I would simply have had absolutely no way of getting production ready if not for using a message based approach, it allows you to limit the scope to the processing of a single message at all time rather than to have to model the entire call stack in your head to keep track of what you're doing and why. As an abstraction model it is extremely powerful and for that reason alone I'd happily advise anybody that has not yet played with an environment like that to give it a whirl. It's not a passe-partout but it certainly is a powerful tool in the toolbox.
      - Jare 11y ago
        > message based architectures are easier to debug (by far) This is the opposite of my experience, mainly because of the lack of proper call stacks, it is very hard to inspect the reason the values in a message are what they are. Can you elaborate?
- mpweiher 11y ago
  Messaging and vtables are not at all the same thing. See my other comment here for an explanation of the messaging part. Vtables by themselves fall just on the other side of the "is it still a message" divide. You can obviously optimize a messaging system further with vtables and enrich a vtable-based system so that it has enough information to be considered "messaging", but out of the box that's where the divide is.
lispm 11y ago
Lisp/CLOS provides parts of that in the function-call model. In Lisp/CLOS the function is being assembled based on the arguments. That's called 'computing the method combination'. If there this is not possible, because there are no methods defined for these argument types, the generic function NO-APPLICABLE-METHOD gets called with the the original function and the arguments - for NO-APPLICABLE-METHOD, the user can write methods.

by cconroy 11y ago

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?
  - jacquesm 11y ago
    - messages are asynchronous, function calls are (pretty much by definition) synchronous - messages do not require a reply (but function calls typically do expect a result) - messages are a lot more secure in that the credentials of the sender can be inspected by the recipient which can be walled off in a different area of memory or even on a different machine - message based architectures are easier to scale than function call based architectures - message based architectures tend to have higher overhead per message than a function call with the same payload and return value - message based architectures tend to lend themselves to soft real time approaches better than monolithic threaded software using functions as the main means of passing data around - message based architectures tend to be more reliable - message based architectures typically allow for things that are next to impossible in a function based environment, such as process migration and load balancing as well as coping with hardware failures - message based architectures are easier to debug (by far) than large systems built up using nothing but function calls. - message based systems tend to be a bit slower, especially if they take the message idea all the way to the lowest levels of the language (such as in smalltalk). Really, the differences are legion. I've built some stuff using message passing that I would simply have had absolutely no way of getting production ready if not for using a message based approach, it allows you to limit the scope to the processing of a single message at all time rather than to have to model the entire call stack in your head to keep track of what you're doing and why. As an abstraction model it is extremely powerful and for that reason alone I'd happily advise anybody that has not yet played with an environment like that to give it a whirl. It's not a passe-partout but it certainly is a powerful tool in the toolbox.
    - Jare 11y ago
      > message based architectures are easier to debug (by far) This is the opposite of my experience, mainly because of the lack of proper call stacks, it is very hard to inspect the reason the values in a message are what they are. Can you elaborate?
mpweiher 11y ago
Messaging and vtables are not at all the same thing. See my other comment here for an explanation of the messaging part. Vtables by themselves fall just on the other side of the "is it still a message" divide. You can obviously optimize a messaging system further with vtables and enrich a vtable-based system so that it has enough information to be considered "messaging", but out of the box that's where the divide is.

lispm 11y ago

Lisp/CLOS provides parts of that in the function-call model. In Lisp/CLOS the function is being assembled based on the arguments. That's called 'computing the method combination'. If there this is not possible, because there are no methods defined for these argument types, the generic function NO-APPLICABLE-METHOD gets called with the the original function and the arguments - for NO-APPLICABLE-METHOD, the user can write methods.