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.
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?
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...
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?
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.
As with many things, the bias toward object-oriented programming (OOP) rather than message-oriented programming (MOP) reflects a tradeoff at implementation time. There is more to MOP than just the interfaces (OOP has that), it is also about methods for optimally scheduling message flows, preferably asynchronously or even out of order.
MOP has upfront costs that you do not have to pay using OOP if your software system remains reasonably small. Many software systems start out with the limited goals that suggest it would not be worth the effort to implement a MOP architecture. As an aside, this partly a reflection of the fact that our software tools for OOP are much better than our software tools for MOP. A good MOP implementation still requires rolling a lot of your own infrastructure components.
However, MOP architectures scale much better than OOP architectures if you need them to. The clarity of resource boundaries implicit in MOP architectures eliminate a lot of coordination and decouple nominal dependencies. Even if you start out building a MOP design on a single computer, where every core has its own process and set of resources, the design leap to putting those components on different hardware or different computers is relatively small. The interface is the same, only the latency changes, and there are many methods for making that abstraction efficiently scale this way. This is the reason large-scale parallel and distributed computing systems are all based on message-oriented architectures.
'MOP' has been my go-to paradigm for most of my professional career. I freely admit that I 'go there' too soon in some situations, but you are quite correct about the benefits.
Scalability is only one benefit. Testability is another. And my favorite, it's very easy and usually safe to do run-time hacks, as the need arises.
I am currently working on a wide-scale, multi-language MOP family of libraries that I hope will make this programming paradigm a lot more accessible.
It wasn't just an important aspect, it was the aspect. I'm glad the author included the link to Alan Key's email message because it really brings home that fact.
This is exactly what Object-Oriented programming was supposed to be. Passing messages to objects that know how to respond to them, without you needing to know how they do it or them needing to know why you asked.
Yes, but it certainly was not what it became. I'm less impressed by one guy's stated goals forty years ago than what it actually became.
That's not a criticism of Alan Kay. It's an observation that his saying a thing a long time ago didn't and doesn't change what actually was created, and what OO is today is not message passing.
The very, very core of what we call OO today, the feature without which you can not call yourself OO, is the binding together of a structure with associated "methods" for operating on it into a single unit. It's a way of structuring programs (note I do not say "language"; C can be programmed in OO, for instance) that chooses the OO answer to the Expression Problem: http://c2.com/cgi/wiki?ExpressionProblem There's other frippery... there's a LOT of other frippery, actually, tons and tons and tons... but that's the core.
It is not message passing. And the attempt to map one to the other is pretty klunky and generally lossy in both directions, another sign they really aren't the same thing. Alan Kay's description of message passing, when read in English rather than Smalltalk, always sounded a lot more like Erlang than Smalltalk to me, but I observe that Smalltalk is what he in fact created as the manifestation of his ideas, not Erlang. I think we can't ignore that fact.
More subtly, passing around objects at all couples the program to the object
system — the rules for looking up the objects’ data and behavior is an
implicit global context. If the modules communicate by passing around
self-contained textual data, or a simple structured format like JSON,
then they impose fewer assumptions on each other. Different parts can be
written using different platforms or languages, allowing access to far more
libraries. (They can also be on physically separate computers.)
I may be mis-reading this, but is the author advocating this sort of serialized message passing within local environments, not just between them?
Passing around data bags within local systems seems kinda odd given they have to be deserialized and mapped to a local object anyway. At that point you introduce an overhead of converting objects in the sender context, sending the data bag, converting that message to a an object usable in the receiver context and reverse the process when the method returns.
If you are passing around literal values in strings, then this doesn't matter, but if you are passing around JSON in strings, you end up with a general container that probably has to be inspected and categorized which seems contrary to the whole point of the article.
This is like an American company opening offices in multiple foreign countries and then requiring english to be the only language that can be spoken in those offices.
I'm advocating breaking the system into modules with messaging between them, at a fairly course grain (i.e., between subsystems). Within the modules, do whatever you want, but I'm talking about decomposing a system into a service-oriented architecture, or multiple Erlang processes and applications, or Unix pipes, or whatever you want to call it. (Doing it at too fine a grain leads to lots of CPU churn from excess serialization, of course.)
JSON is a decent example of a neutral and lightweight protocol, but it's worth actually thinking long and hard about the shape those messages should take. (I prefer text or binary payloads, but I'm also doing embedded development and a real JSON library costs ROM.) Thinking hard about those interfaces/protocols between the pieces, and keeping them tight, is where the value comes from.
(Kind of a quick response because I'm at Clojure/Conj today, sorry if I'm missing part of your point.)
Well, you could simply pass around data that can be round-trip (de)serialisabled to/from JSON, and if you need to send it outside the process, actually do real (de)serialisation.
From Alan Kay, the inventor of Object-oriented programming:
> OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I’m not aware of them.[1]
It is good to see messaging become more popular! It has been around for a long, long time, but it has never been given the spotlight.
going meta for a bit...
When I see the number of comments here, I have optimism for the system that is distributing the important knowledge (the Internet and good online communities ( HN )).
I don't think the ACM or any of the engineering related orgs are ahead of the curve
on these things. Engineers need to share with engineers on this topic.
I just read the paper by Richard Gabriel on CLOS and Mixins.
One of the tl;drs for that paper is that engineers are the driving most of the innovation in this field. (or at least as much as academia). This reinforces the point above.
In contrast, throughout the 80s,90s or even 00s, when I talked or asked about Smalltalk, Objects, and other interesting tech... I was usually told that those were failures. "Go with C++ or Java". Those languages are the very ones that made MOP and other interesting
paradigms feel like you were going against the grain.
Even if you were following some usenet newsgroup that had good discussion. There was usually a bozo factor or too much religion (aka not much cross pollination)
So glad to be in the future and see positive discussion occurring!
... going un-meta
tl;dr - It is good to see people look at the existing paradigms with an open mind.
just like functional programming. Overall the post linked to is not that interesting.
It is the discussion in the comments here that is inspiring.
The asynchronous aspect of this is a big deal. It makes life both easier (because components can continue to run without blocking on data) but introduces complexity (sometimes you /need/ to synchronize). I've recently been working on a research project where this difference became very apparent. If you're working with wall-clock time (and especially any deadlines) the synchronization between different processes can subject you to needing a real-time operating system. At the very least (without deadlines) you're going to be doing some semaphore coding which can be difficult to scale.
On a related note: I look forward to the new Intel Haswell architecture. Built in HW Transactional Memory!!! Hurray!
Recently back from QCon SF, one of my favorite bits was a tutorial given by James Lewis from ThoughtWorks on micro-services (which he said was not the best moniker but close enough that people understand the idea). Lots of resonance with the concept described in this post -- use existing APIs and formats to create "just enough" architecture to connect distinct components in well-defined ways.
Very good article by the way. Not very thorough, but that's what is good. It just remembered me about a state of enlightenment i have already felt, but forgotten since.
I too am on the Message Oriented bandwagon. I even wrote my own ORM (https://github.com/agentgt/jirm) because the current Java ORMs (Hibernate) kind of suck for messages where you generally want immutable objects.
The biggest problem I have had so far is Java is just not as friendly for this kind of architecture compared to Scala.
If you declare message passing as the only true form of OO then you're just drawing your box too big. Within the infrastructure that allows you to pass those messages around are many interesting lower-level problems that require the uglier, statically typed and binary-incompatible OO programming maybe better described as class based programming.
My current work involves managing a range of different concurrency and multi-process systems. Focusing on clean, forgiving message channels as the foundation of the system has been a win in the last three very different problem spaces. Only thing missing is perhaps a nod to Communicating Sequential Processes.
Have a look at ROS.org, its the same system you jsut reinvented (even with kinect intergration!). You write typed messages and it generates c++, python and lisp interfaces. It is also a build system, logging and data playback.
I would search for "Squeak By Example" and read through the book. It is Smalltalk, aka the seminal OO language. It also provides all of the code use to create the system and the VM it runs on in a readable, editable, runnable format so you can play with everything. Reading the code was really eye opening for me. And super fun to boot!
Pardon the evangelization, but this is precisely one of the strengths of node.js; being network-focused means it's very easy to build a collection of small services instead of a monolithic server.
I'm surprised that no one thus far has mentioned that message passing is just a special case of multiple dispatch. In that light, it seems less expressive. Any thoughts?
Message passing allows you to code the individual components in multiple languages on multiple platforms that run at multiple speeds. The thing that makes it work, however, is that the sender also has a queue, and work-completed messages go into his in-queue, in the order completed, so there is no need of mechanism to collect the results of multiple dispatches, nor is there a need to pass along with the message what function needs to be called on message completion, since the caller queue handler will do that.
[+] [-] paulhodge|13 years ago|reply
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|13 years ago|reply
[+] [-] gruseom|13 years ago|reply
One thing people usually understand as part of "message passing" is "no shared state". How/where do you fit that in?
[+] [-] mkelley|13 years ago|reply
[+] [-] look_lookatme|13 years ago|reply
[+] [-] tree_of_item|13 years ago|reply
[+] [-] jandrewrogers|13 years ago|reply
MOP has upfront costs that you do not have to pay using OOP if your software system remains reasonably small. Many software systems start out with the limited goals that suggest it would not be worth the effort to implement a MOP architecture. As an aside, this partly a reflection of the fact that our software tools for OOP are much better than our software tools for MOP. A good MOP implementation still requires rolling a lot of your own infrastructure components.
However, MOP architectures scale much better than OOP architectures if you need them to. The clarity of resource boundaries implicit in MOP architectures eliminate a lot of coordination and decouple nominal dependencies. Even if you start out building a MOP design on a single computer, where every core has its own process and set of resources, the design leap to putting those components on different hardware or different computers is relatively small. The interface is the same, only the latency changes, and there are many methods for making that abstraction efficiently scale this way. This is the reason large-scale parallel and distributed computing systems are all based on message-oriented architectures.
[+] [-] Diederich|13 years ago|reply
Scalability is only one benefit. Testability is another. And my favorite, it's very easy and usually safe to do run-time hacks, as the need arises.
I am currently working on a wide-scale, multi-language MOP family of libraries that I hope will make this programming paradigm a lot more accessible.
[+] [-] ericHosick|13 years ago|reply
"OOP, defined in the purest sense, is implemented by sending messages to objects." - http://www.inf.ufsc.br/poo/smalltalk/ibm/tutorial/oop.html
For varying reasons, people focused on inheritance. In my opinion, inheritance is bad (at least the over-use of).
[+] [-] adestefan|13 years ago|reply
[+] [-] gliese1337|13 years ago|reply
[+] [-] jerf|13 years ago|reply
That's not a criticism of Alan Kay. It's an observation that his saying a thing a long time ago didn't and doesn't change what actually was created, and what OO is today is not message passing.
The very, very core of what we call OO today, the feature without which you can not call yourself OO, is the binding together of a structure with associated "methods" for operating on it into a single unit. It's a way of structuring programs (note I do not say "language"; C can be programmed in OO, for instance) that chooses the OO answer to the Expression Problem: http://c2.com/cgi/wiki?ExpressionProblem There's other frippery... there's a LOT of other frippery, actually, tons and tons and tons... but that's the core.
It is not message passing. And the attempt to map one to the other is pretty klunky and generally lossy in both directions, another sign they really aren't the same thing. Alan Kay's description of message passing, when read in English rather than Smalltalk, always sounded a lot more like Erlang than Smalltalk to me, but I observe that Smalltalk is what he in fact created as the manifestation of his ideas, not Erlang. I think we can't ignore that fact.
[+] [-] Aardwolf|13 years ago|reply
[+] [-] fmargaine|13 years ago|reply
[deleted]
[+] [-] look_lookatme|13 years ago|reply
Passing around data bags within local systems seems kinda odd given they have to be deserialized and mapped to a local object anyway. At that point you introduce an overhead of converting objects in the sender context, sending the data bag, converting that message to a an object usable in the receiver context and reverse the process when the method returns.
If you are passing around literal values in strings, then this doesn't matter, but if you are passing around JSON in strings, you end up with a general container that probably has to be inspected and categorized which seems contrary to the whole point of the article.
This is like an American company opening offices in multiple foreign countries and then requiring english to be the only language that can be spoken in those offices.
[+] [-] silentbicycle|13 years ago|reply
I'm advocating breaking the system into modules with messaging between them, at a fairly course grain (i.e., between subsystems). Within the modules, do whatever you want, but I'm talking about decomposing a system into a service-oriented architecture, or multiple Erlang processes and applications, or Unix pipes, or whatever you want to call it. (Doing it at too fine a grain leads to lots of CPU churn from excess serialization, of course.)
JSON is a decent example of a neutral and lightweight protocol, but it's worth actually thinking long and hard about the shape those messages should take. (I prefer text or binary payloads, but I'm also doing embedded development and a real JSON library costs ROM.) Thinking hard about those interfaces/protocols between the pieces, and keeping them tight, is where the value comes from.
(Kind of a quick response because I'm at Clojure/Conj today, sorry if I'm missing part of your point.)
[+] [-] TazeTSchnitzel|13 years ago|reply
[+] [-] chimeracoder|13 years ago|reply
From Alan Kay, the inventor of Object-oriented programming:
> OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I’m not aware of them.[1]
[1] 2003. http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...
[+] [-] silentbicycle|13 years ago|reply
It's a meditation on why Erlang feels more OO to me than (say) Java or C#.
[+] [-] drudru11|13 years ago|reply
going meta for a bit...
When I see the number of comments here, I have optimism for the system that is distributing the important knowledge (the Internet and good online communities ( HN )). I don't think the ACM or any of the engineering related orgs are ahead of the curve on these things. Engineers need to share with engineers on this topic.
I just read the paper by Richard Gabriel on CLOS and Mixins. One of the tl;drs for that paper is that engineers are the driving most of the innovation in this field. (or at least as much as academia). This reinforces the point above.
In contrast, throughout the 80s,90s or even 00s, when I talked or asked about Smalltalk, Objects, and other interesting tech... I was usually told that those were failures. "Go with C++ or Java". Those languages are the very ones that made MOP and other interesting paradigms feel like you were going against the grain.
Even if you were following some usenet newsgroup that had good discussion. There was usually a bozo factor or too much religion (aka not much cross pollination)
So glad to be in the future and see positive discussion occurring!
... going un-meta
tl;dr - It is good to see people look at the existing paradigms with an open mind. just like functional programming. Overall the post linked to is not that interesting. It is the discussion in the comments here that is inspiring.
[+] [-] jwfergus|13 years ago|reply
On a related note: I look forward to the new Intel Haswell architecture. Built in HW Transactional Memory!!! Hurray!
[+] [-] Cyranix|13 years ago|reply
Slides from an ealier version of the talk here: http://www.slideshare.net/jamesalewis/java-microservices
[+] [-] Raphael_Amiard|13 years ago|reply
link : https://plus.google.com/112678702228711889851/posts/eVeouesv...
Very good article by the way. Not very thorough, but that's what is good. It just remembered me about a state of enlightenment i have already felt, but forgotten since.
[+] [-] agentgt|13 years ago|reply
The biggest problem I have had so far is Java is just not as friendly for this kind of architecture compared to Scala.
[+] [-] zwieback|13 years ago|reply
[+] [-] spenrose|13 years ago|reply
My current work involves managing a range of different concurrency and multi-process systems. Focusing on clean, forgiving message channels as the foundation of the system has been a win in the last three very different problem spaces. Only thing missing is perhaps a nod to Communicating Sequential Processes.
[+] [-] silentbicycle|13 years ago|reply
[+] [-] tlarkworthy|13 years ago|reply
[+] [-] silentbicycle|13 years ago|reply
[+] [-] hamxiaoz|13 years ago|reply
[+] [-] jgon|13 years ago|reply
[+] [-] ricardobeat|13 years ago|reply
[+] [-] capisce|13 years ago|reply
[+] [-] chris_mahan|13 years ago|reply
[+] [-] TazeTSchnitzel|13 years ago|reply
[+] [-] debacle|13 years ago|reply
[+] [-] sek|13 years ago|reply