5 ms·

In the interests of rigor I'm going to propose a ranking system. A higher rank means more "Message Oriented". Rank 1: Polymorphism. You can "send" a message to

In the interests of rigor I'm going to propose a ranking system. A higher rank means more "Message Oriented". Rank 1: Polymorphism. You can "send" a message to an object. You don't know or care exactly what the object does. Other than the polymorphism, the "message" behaves just like a function call. It will definitely be handled by your target object, and it will definitely return instantly with a response. The compiler might even be able to inline this function call. As seen in: Pretty much every OOP language. Rank 2: Messages as first-class values. It's possible to write a function that forwards all incoming messages to another object, based on some logic. The caller does not know what will happen to the message. However, the message can be expected to be handled instantly, and it may respond instantly (if it does have a response). As seen in: Objective-C, Smalltalk Rank 3: Asynchronous messaging. When sending an outgoing message, it might be placed in a queue and handled at a later date. The message does not return a result instantly, so agents must have some other mechanism (such as including a "reply to" address) to be able to talk back and forth. From the perspective of the caller, it's a bit like putting a message in a bottle and watching it drift off to sea. As seen in: Erlang, message queueing libraries.

georgemcbay 14y ago
I'm going to be the token annoyingly overeager Go supporter and post that Go channels fit nicely into rank 3.
- riobard 14y ago
  Scala with actors fit into rank 3 too.
look_lookatme 14y ago
Can't most languages in (1) implement forwardable patterns that accomplish (2), or is there some underlying language features in Objective-C or Smalltalk that are superior in this case?
- TazeTSchnitzel 14y ago
  I'm guessing that in these languages you don't need special argument types (or you can use the same code for any function) There are several others that support this though... Python and JavaScript spring to mind.
- paulhodge 14y ago
  Sure, with enough boilerplate code you can do anything in anything. It's more of a categorization of what's the normal style, of what is already provided and encouraged.
- xsmasher 14y ago
  In Objective-C, I can easily say "if anyone calls a method on me that I don't implement, sent it to this object instead". I can also say "if anyone calls a method on me that I don't implement, do (foo) instead". C++, for example, has no equivalent language facility for these scenarios; in fact they're nonsensical since they would both fail to compile. You could build a similar system for C++ by making every object inherit from some base class that has a method performMethod( method, params) and replace all C++ method calls with your modified calls; but you're building a facility from scratch that comes out-of-the-box on Objective-C.
gruseom 14y ago
That's nice and simple. I like it. "Message passing" means too many different things (though not as many as "object-oriented"). Distinctions are helpful. One thing people usually understand as part of "message passing" is "no shared state". How/where do you fit that in?
- paulhodge 14y ago
  > One thing people usually understand as part of "message passing" is "no shared state". How/where do you fit that in? Good question, it seems like all definitions of message passing involve not sharing state. Even OOP emphasizes data hiding as a core practice.
  - gruseom 14y ago
    But there's a huge difference between working in a model where you can do it (even if you're "not supposed to") and working in a model where it's impossible. I've been writing a Chrome extension, where the programming model is a #3 in your system — everything is async and shared-nothing — and boy do I notice the difference. Calls between two Chrome contexts are done by async message-passing using JSON, and this is like walking through mud in heavy boots compared to calling something in the same context (a normal function call). No doubt well-designed languages and libraries help to make it easier, but still. I suspect asynchronousness is responsible for more of the mental burden than shared-nothingness is (or, more precisely, serialize-everything-into-JSON-ness), but they're definitely both contributors. It's the latter that makes it impossible for me to pass a DOM element from one context to another, for example. When "passing a message" is a heavier operation syntactically than "calling a function" is, one thinks of the two as being more fundamentally different than they really are. I find that interesting because it's superficial yet influential. Do Erlang programmers think of function calls as a kind of message passing? or as totally different things? How far apart are the two, psychologically? Is sync vs. async the more fundamental distinction?
    - klibertp 14y ago
      About Erlang and function calls: I tend to view them differently. For me, in Erlang code, function call is about 'here', while sending a message is about 'there'. Syntactic difference is big, but neither function call nor message send are heavy: func({my, params, in, a tuple}) proc ! {my, params, in, a tuple} The difference is that function call returns something, message send just happens and we have no guarantee at all what is going to happen with the message. We frequently write functions which send message and wait for reply for a certain amount of time, and then return this reply or error if no reply was sent. So, in Erlang there is - I think - huge difference between functions and messages, but that is because it's functions are just that: functions. The situation is quite different in Smalltalk, where you have no functions at all, only objects. Everything there already is a message being passed, and so the difference between asynchronous and synchronous message should be very minor. I don't know Smalltalk well enough, but I suspect there are libraries implementing async message passing in Smalltalk and that they are almost indistinguishable from normal Smalltalk code, if at all.
tree_of_item 14y ago
Asynchronous messages can also return results instantly in the form of futures/promises, avoiding the need to program in a continuation passing style with "reply-to" addresses. Mark Miller's E language does this.
mkelley 14y ago
So would messages ala Laurent Bungion's (sp?) MVVM-Light Messaging system fall under 1,2, or 3? You send out a message from an object and then any object "registered" to receive these messages can pick them up and handle them as they wish... doing something, doing nothing.... returning a value or more likely not...

georgemcbay 14y ago

I'm going to be the token annoyingly overeager Go supporter and post that Go channels fit nicely into rank 3.

riobard 14y ago
Scala with actors fit into rank 3 too.

look_lookatme 14y ago

Can't most languages in (1) implement forwardable patterns that accomplish (2), or is there some underlying language features in Objective-C or Smalltalk that are superior in this case?

TazeTSchnitzel 14y ago
I'm guessing that in these languages you don't need special argument types (or you can use the same code for any function) There are several others that support this though... Python and JavaScript spring to mind.
paulhodge 14y ago
Sure, with enough boilerplate code you can do anything in anything. It's more of a categorization of what's the normal style, of what is already provided and encouraged.
xsmasher 14y ago
In Objective-C, I can easily say "if anyone calls a method on me that I don't implement, sent it to this object instead". I can also say "if anyone calls a method on me that I don't implement, do (foo) instead". C++, for example, has no equivalent language facility for these scenarios; in fact they're nonsensical since they would both fail to compile. You could build a similar system for C++ by making every object inherit from some base class that has a method performMethod( method, params) and replace all C++ method calls with your modified calls; but you're building a facility from scratch that comes out-of-the-box on Objective-C.

gruseom 14y ago

That's nice and simple. I like it. "Message passing" means too many different things (though not as many as "object-oriented"). Distinctions are helpful. One thing people usually understand as part of "message passing" is "no shared state". How/where do you fit that in?

paulhodge 14y ago
> One thing people usually understand as part of "message passing" is "no shared state". How/where do you fit that in? Good question, it seems like all definitions of message passing involve not sharing state. Even OOP emphasizes data hiding as a core practice.
- gruseom 14y ago
  But there's a huge difference between working in a model where you can do it (even if you're "not supposed to") and working in a model where it's impossible. I've been writing a Chrome extension, where the programming model is a #3 in your system — everything is async and shared-nothing — and boy do I notice the difference. Calls between two Chrome contexts are done by async message-passing using JSON, and this is like walking through mud in heavy boots compared to calling something in the same context (a normal function call). No doubt well-designed languages and libraries help to make it easier, but still. I suspect asynchronousness is responsible for more of the mental burden than shared-nothingness is (or, more precisely, serialize-everything-into-JSON-ness), but they're definitely both contributors. It's the latter that makes it impossible for me to pass a DOM element from one context to another, for example. When "passing a message" is a heavier operation syntactically than "calling a function" is, one thinks of the two as being more fundamentally different than they really are. I find that interesting because it's superficial yet influential. Do Erlang programmers think of function calls as a kind of message passing? or as totally different things? How far apart are the two, psychologically? Is sync vs. async the more fundamental distinction?
  - klibertp 14y ago
    About Erlang and function calls: I tend to view them differently. For me, in Erlang code, function call is about 'here', while sending a message is about 'there'. Syntactic difference is big, but neither function call nor message send are heavy: func({my, params, in, a tuple}) proc ! {my, params, in, a tuple} The difference is that function call returns something, message send just happens and we have no guarantee at all what is going to happen with the message. We frequently write functions which send message and wait for reply for a certain amount of time, and then return this reply or error if no reply was sent. So, in Erlang there is - I think - huge difference between functions and messages, but that is because it's functions are just that: functions. The situation is quite different in Smalltalk, where you have no functions at all, only objects. Everything there already is a message being passed, and so the difference between asynchronous and synchronous message should be very minor. I don't know Smalltalk well enough, but I suspect there are libraries implementing async message passing in Smalltalk and that they are almost indistinguishable from normal Smalltalk code, if at all.

tree_of_item 14y ago

Asynchronous messages can also return results instantly in the form of futures/promises, avoiding the need to program in a continuation passing style with "reply-to" addresses. Mark Miller's E language does this.

mkelley 14y ago

So would messages ala Laurent Bungion's (sp?) MVVM-Light Messaging system fall under 1,2, or 3? You send out a message from an object and then any object "registered" to receive these messages can pick them up and handle them as they wish... doing something, doing nothing.... returning a value or more likely not...