8 ms·

The big idea of message passing is that it's not about message passing, I think what Alan Kay has been trying to say all these year is that we should look at ho

The big idea of message passing is that it's not about message passing, I think what Alan Kay has been trying to say all these year is that we should look at how bacteria communicate, and try to mimic that. They communicate by sending protein "messages" to their vicinity, and if a close-by bacterium knows what to do with it, it processes it, and responds by either sending out their own proteins (message passing), OR change their internals to get receptive to different kinds of messages (change internal state). From this viewpoint, coding starts being about cultivating a literal society of objects (cells). The obvious advantage being that biology scales an immeasurable amount better than whatever architectures we ever come up with. He often gives the example of the internet as a well-designed system, it operates in a similar manner, objects (anything that can self-identify with an IP-address) can join/leave at any point, and the system itself stays alive. I'm not 100% sure if this is what Alan means, but after having following his talks and writings for a couple of years, I think that's the gist of it.

chrisseaton 8y ago
Sounds more like what many people would call event-drive architecture, these days. People tell me Ruby is message passing, but it doesn't seem to match your description at all.
- michaelscott 8y ago
  Just to add to the previous poster's comments, Alan Kay seems to also consider the internal state of a "cell" (or object) to be private and responsive only to external messaging. If you extrapolate this to a network I personally see a "colony" of objects that are not "aware" of each other aside from their neighbours' messages, and the whole thing starts to seem like it has a lot of the features we see in modern functional programming today. I don't think this is particularly coincidental, since functional approaches are born from lambda calculus and Kay mentions in these emails a desire to incorporate algebras into his objects (aside from the biological nature of this type of cell communication). Alan, if you're in the comments section I'd love to hear your thoughts on what you think of the resurgence of functional programming in the modern day and whether anything, other than perhaps languages like Erlang, has approached your original ideal.
  - macintux 8y ago
    I don't think I've watched it previously, and I don't have the time to now, but I have to imagine Joe Armstrong interviewing Alan Kay would at least touch on that (although from one comment it sounds like they didn't do more than that). https://youtu.be/fhOHn9TClXY https://youtu.be/fhOHn9TClXY
    - jimbokun 8y ago
      Watch it! I just watched the whole thing, based on just seeing your link. It does talk about the historical connections between Smalltalk and Erlang, but goes far beyond that to remind us to think more about the bigger problems we need to solve, and get less caught up in doing things just because we have a tool that can do them or other people are doing things that way. I found it truly inspiring.
  - rudedogg 8y ago
    > Alan, if you're in the comments section I'd love to hear your thoughts on what you think of the resurgence of functional programming in the modern day and whether anything, other than perhaps languages like Erlang, has approached your original ideal Someone asked a similar question when he did an AMA, but the answer wasn't clear to me: https://news.ycombinator.com/item?id=11940211 https://news.ycombinator.com/item?id=11940211
- madis 8y ago
  Ruby to me seems to follow this description rather well. The "cells" in close vicinity are the objects in ancestor chain. If the "closest cell" - object's class - can't respond to it, next further, which is its parent, will be given chance and so on. Also you can ask object if they know how to respond with `respond_to?` It's a bit more involved than that - modules can be included and prepended. In a sense "re-arranging the which cells are close and further". Also `method_missing` can be implemented. Beautiful in my opinion.
- deleted 8y ago
  [deleted]
- inopinatus 8y ago
  Ruby syntax & behaviour is in a hazy middle ground between message passing and method calling. Writing Ruby in a message-passing style feels natural and easy, which is why many Rubyists will recommend it, and doing so enables looser coupling between objects. To me, it's the difference between pulling the strings on a puppet (method calling) vs placing a request to a colleague (messaging). However I don't think anything in the Ruby docs ever claims that it has a message-passing intent. I think the option to write in this style is really a byproduct of duck typing combined with a Ruby object's ability to arbitrarily and dynamically reconfigure its own dispatch table. If Matz really intended a message-passing style, then Object#send would've been split into Kernel#send and Object#receive, and there'd probably be a Message class rather than just using symbols. Given the new shorthand of object.:name in 2.7 for object.method(:name) one could even argue that Matz is drifting Ruby back towards an early binding style. However I don't see myself using that syntax much outside of block parameters to Enumerable methods and the like. Overall I think the stylistic options are a strength and we don't particularly need to resolve the dichotomy to write good Ruby.
  - chrisseaton 8y ago
    > However I don't think anything in the Ruby docs ever claims that it has a message-passing intent. There is of course the `Kernel#send` method, which implies the model is messages being sent. It's not called `call`.
    - inopinatus 8y ago
      I think you mean Object#send? I actually think that's misnamed, I think it should be named Object#receive because that's what happens - you're forcing an object to receive a symbol for (by default) dispatch through its method table. The fact it isn't invoked for regular method invocation is kinda indicative of Ruby _not_ being a pure message passing language, even if we like treating it that way.
      - chrisseaton 8y ago
        > I think you mean Object#send? It's definitely Kernel#send. Object defines no instance methods at all. > Kernel.instance_methods(false).include?(:send) => true > Object.instance_methods(false).include?(:send) => false > Object.instance_methods(false) => [] https://github.com/ruby/ruby/blob/v2_6_2/vm_eval.c#L2163 https://github.com/ruby/ruby/blob/v2_6_2/vm_eval.c#L2163
- profalseidol 8y ago
  Here's one talk about 'message' in Ruby: RailsConf 2015 - Nothing is Something https://www.youtube.com/watch?v=OMPfEXIlTVE https://www.youtube.com/watch?v=OMPfEXIlTVE But to me, this simply looks like Functional Programming done in an OOP mess.
  - pjmlp 8y ago
    Smalltalk was also influenced by Lisp work being done at Xerox PARC. Map, filter, flapmap, lambdas, symbols, are all there. You can easily do LINQ in Smalltalk-80 without any additional library.
Pamar 8y ago
Are you sure about this? (I haven't read the article yet) - I am asking because what you are describing looks to me closer to https://en.wikipedia.org/wiki/Tuple_space https://en.wikipedia.org/wiki/Tuple_space than "traditional" OOP.
- azeirah 8y ago
  I said I wasn't sure, but it's what Alan keeps coming back to, his roots in biology and mathematics, scaling, and scaling through communication. It's obviously a bit wooshy, but I'm pretty sure that's the gist of what he intends to get across.
  - eternalban 8y ago
    It is more than a bit wooshy. The 'solid' parts are all "biology", "mathematics", etc. Alan Kay is, of course, correct that nature provides excellent guidance on how to build resilient systems. I would think that thought is fairly self evident to the subset that is preoccupied with such thoughts. But as the endless exegesis of still-with-us Dr. Kay's historic utterances here and elsewhere demonstrate, there is this very obviously missing link (or unkindly 'hand waving') between "his" 'big idea' and how could we possibly build bio-morphic computational systems with the current state of the art and craft of building software. At which point one could ask the question "why are we discussing these wooshy notions?"
    - azeirah 8y ago
      His point is, as far as I understand, that we should keep studying biological systems as inspiration for our computational systems, not for the short term (5-10 years) but long term (100-500 years). Sussman equally has famous lectures on the same topic, "we don't know how to compute" The why is not to be practical right now, but to research these ideas to the point where they do become practical, no? But then again, I agree with you, he does keep going on about the same ideas again and again and again, without pointing to the slightly more practical details... Basically ever. It's always "no what we do is bad, all of it, haha don't we suck?" "Look at these cathedrals and ant hills! Why can't we do that???"
zumu 8y ago
> The obvious advantage being that biology scales an immeasurable amount better than whatever architectures we ever come up with. Not sure what you mean by this. In the general case, the hard part of "scaling" is building systems that are easy to reason about / maintain as the complexity / throughput increases. Meanwhile, biology is notoriously difficult to reason about and maintain (think medicine).
- TelmoMenezes 8y ago
  Conventional software engineering is extraordinarily brittle, in the sense that any random mutation to a program is likely to cause catastrophic failure: it is very likely that it will not even be valid anymore, or behave in a completely different way. In this scenario, complexity is the enemy, and we take all the well known-measures that are taken in human engineering to manage complexity. When one dreams of a biological approach, one is interested in replicating the "graceful degradation" aspect of biological structures, which is the opposite of brittleness. If you remove one random cell from your body, it will make virtually no difference. If you remove 1K random cells, you will still not notice anything. If you remove 1M cells, maybe it's not so nice, etc. Biological systems have fewer central points of failure and are much better at adapting to unexpected situations. In this case, complexity can be our friend. I believe it is possible to learn how to design systems more like nature does, and I think this is Kay's dream.
jdonaldson 8y ago
FWIW I had Alan Kay's biologically-inspired "message passing" approach when I wrote a routing library : https://github.com/jdonaldson/golgi https://github.com/jdonaldson/golgi The premise was to start with a standard class-based instance, and then use metaprogramming to autodefine a corresponding ADT for all possible typed responses from the API. This gets around the main problem of message routing (IMHO): Namely, if you're relying on a host system to interpret your message how it sees fit, then you don't really know how it will respond in a given case. Will it error? Will it call something different than what you thought? The solution is just to enumerate every possible response type, and return a corresponding composite type as an ADT. I was doing that manually in a few prior cases, and then realized I could use the macro programming features in Haxe to do something automatically, and put together a library as a POC. I'm certain that FP purists would argue that this is equivalent to some other pre-existing type transformation... but I haven't found it yet. I'm interested if anyone else has been experimenting in this area.
hota_mazi 8y ago
> The big idea of message passing is that it's not about message passing, I think what Alan Kay has been trying to say all these year is that we should look at how bacteria communicate, and try to mimic that. It is such a horrible programming model, though. Making calls and sometimes they get picked up and sometimes not?!? If we're talking remote processes, sure, that's understandable, remote resources are not always available. But in-process? If I call a function on an object, I want the compiler to tell me right now if this code makes sense, and the compiler should stop me right away if that code cannot possibly work once deployed.
- function_seven 8y ago
  I don't think it's about sending a message into the void and "hoping" that a compatible agent receives the message. Rather, it's about your object not having to know who is handling the message, only what the message is ("what" in both content and type). It's still up to you as the programmer to make sure that you have implemented the other objects to act on whatever message types your code will pass. Just like it's up to you to make sure the method exists in the target class when the caller tries to invoke it. Later on, if you decide to swap out your logging infrastructure for a different one, you don't need to update all the places that called the old one. You just tell your new logger to listen for messages directed at Logger.
  - macleginn 8y ago
    But is it possible for the compiler to check that some object was actually set to wait to receive a particular message that another object was instructed to send? When coding with method calls, it is possible to accidentally leave a stub instead of method code that is supposed to produce some important side effect, say, but at least you know where to look.
  - da_chicken 8y ago
    > I don't think it's about sending a message into the void and "hoping" that a compatible agent receives the message. Except that is the bacterial model. When you want something done, you signal for it by releasing proteins, and keep releasing proteins until you're satisfied even if the work ended up being done 50 times more than you needed. That's why biological systems so commonly overreact to stimulus. The biological method is to flood communication until whatever demanded response is met. It's the equivalent of a user mashing a button until a program responds, like the elevator button problem. Actually, elevators seem like an extremely good analogy for this kind of asynchronous service system. I understand we're not trying to perfectly mimic the analogy, but I think it's important to see that nature's model, while robust and asynchronous, carries significant problems due to how it communicates. It's that very robustness that we're trying to mimic, so we should expect to inherit some of the problems that go along with it.
jimmy_ruska 8y ago
Sussman of SICP fame gave a similar analogy. Not really about messaging but about biology in general - https://www.youtube.com/watch?v=O3tVctB_VSU https://www.youtube.com/watch?v=O3tVctB_VSU

chrisseaton 8y ago

Sounds more like what many people would call event-drive architecture, these days. People tell me Ruby is message passing, but it doesn't seem to match your description at all.

michaelscott 8y ago
Just to add to the previous poster's comments, Alan Kay seems to also consider the internal state of a "cell" (or object) to be private and responsive only to external messaging. If you extrapolate this to a network I personally see a "colony" of objects that are not "aware" of each other aside from their neighbours' messages, and the whole thing starts to seem like it has a lot of the features we see in modern functional programming today. I don't think this is particularly coincidental, since functional approaches are born from lambda calculus and Kay mentions in these emails a desire to incorporate algebras into his objects (aside from the biological nature of this type of cell communication). Alan, if you're in the comments section I'd love to hear your thoughts on what you think of the resurgence of functional programming in the modern day and whether anything, other than perhaps languages like Erlang, has approached your original ideal.
- macintux 8y ago
  I don't think I've watched it previously, and I don't have the time to now, but I have to imagine Joe Armstrong interviewing Alan Kay would at least touch on that (although from one comment it sounds like they didn't do more than that). https://youtu.be/fhOHn9TClXY https://youtu.be/fhOHn9TClXY
  - jimbokun 8y ago
    Watch it! I just watched the whole thing, based on just seeing your link. It does talk about the historical connections between Smalltalk and Erlang, but goes far beyond that to remind us to think more about the bigger problems we need to solve, and get less caught up in doing things just because we have a tool that can do them or other people are doing things that way. I found it truly inspiring.
- rudedogg 8y ago
  > Alan, if you're in the comments section I'd love to hear your thoughts on what you think of the resurgence of functional programming in the modern day and whether anything, other than perhaps languages like Erlang, has approached your original ideal Someone asked a similar question when he did an AMA, but the answer wasn't clear to me: https://news.ycombinator.com/item?id=11940211 https://news.ycombinator.com/item?id=11940211
madis 8y ago
Ruby to me seems to follow this description rather well. The "cells" in close vicinity are the objects in ancestor chain. If the "closest cell" - object's class - can't respond to it, next further, which is its parent, will be given chance and so on. Also you can ask object if they know how to respond with `respond_to?` It's a bit more involved than that - modules can be included and prepended. In a sense "re-arranging the which cells are close and further". Also `method_missing` can be implemented. Beautiful in my opinion.
deleted 8y ago
[deleted]
inopinatus 8y ago
Ruby syntax & behaviour is in a hazy middle ground between message passing and method calling. Writing Ruby in a message-passing style feels natural and easy, which is why many Rubyists will recommend it, and doing so enables looser coupling between objects. To me, it's the difference between pulling the strings on a puppet (method calling) vs placing a request to a colleague (messaging). However I don't think anything in the Ruby docs ever claims that it has a message-passing intent. I think the option to write in this style is really a byproduct of duck typing combined with a Ruby object's ability to arbitrarily and dynamically reconfigure its own dispatch table. If Matz really intended a message-passing style, then Object#send would've been split into Kernel#send and Object#receive, and there'd probably be a Message class rather than just using symbols. Given the new shorthand of object.:name in 2.7 for object.method(:name) one could even argue that Matz is drifting Ruby back towards an early binding style. However I don't see myself using that syntax much outside of block parameters to Enumerable methods and the like. Overall I think the stylistic options are a strength and we don't particularly need to resolve the dichotomy to write good Ruby.
- chrisseaton 8y ago
  > However I don't think anything in the Ruby docs ever claims that it has a message-passing intent. There is of course the `Kernel#send` method, which implies the model is messages being sent. It's not called `call`.
  - inopinatus 8y ago
    I think you mean Object#send? I actually think that's misnamed, I think it should be named Object#receive because that's what happens - you're forcing an object to receive a symbol for (by default) dispatch through its method table. The fact it isn't invoked for regular method invocation is kinda indicative of Ruby _not_ being a pure message passing language, even if we like treating it that way.
    - chrisseaton 8y ago
      > I think you mean Object#send? It's definitely Kernel#send. Object defines no instance methods at all. > Kernel.instance_methods(false).include?(:send) => true > Object.instance_methods(false).include?(:send) => false > Object.instance_methods(false) => [] https://github.com/ruby/ruby/blob/v2_6_2/vm_eval.c#L2163 https://github.com/ruby/ruby/blob/v2_6_2/vm_eval.c#L2163
profalseidol 8y ago
Here's one talk about 'message' in Ruby: RailsConf 2015 - Nothing is Something https://www.youtube.com/watch?v=OMPfEXIlTVE https://www.youtube.com/watch?v=OMPfEXIlTVE But to me, this simply looks like Functional Programming done in an OOP mess.
- pjmlp 8y ago
  Smalltalk was also influenced by Lisp work being done at Xerox PARC. Map, filter, flapmap, lambdas, symbols, are all there. You can easily do LINQ in Smalltalk-80 without any additional library.

Pamar 8y ago

Are you sure about this? (I haven't read the article yet) - I am asking because what you are describing looks to me closer to https://en.wikipedia.org/wiki/Tuple_space https://en.wikipedia.org/wiki/Tuple_space than "traditional" OOP.

azeirah 8y ago
I said I wasn't sure, but it's what Alan keeps coming back to, his roots in biology and mathematics, scaling, and scaling through communication. It's obviously a bit wooshy, but I'm pretty sure that's the gist of what he intends to get across.
- eternalban 8y ago
  It is more than a bit wooshy. The 'solid' parts are all "biology", "mathematics", etc. Alan Kay is, of course, correct that nature provides excellent guidance on how to build resilient systems. I would think that thought is fairly self evident to the subset that is preoccupied with such thoughts. But as the endless exegesis of still-with-us Dr. Kay's historic utterances here and elsewhere demonstrate, there is this very obviously missing link (or unkindly 'hand waving') between "his" 'big idea' and how could we possibly build bio-morphic computational systems with the current state of the art and craft of building software. At which point one could ask the question "why are we discussing these wooshy notions?"
  - azeirah 8y ago
    His point is, as far as I understand, that we should keep studying biological systems as inspiration for our computational systems, not for the short term (5-10 years) but long term (100-500 years). Sussman equally has famous lectures on the same topic, "we don't know how to compute" The why is not to be practical right now, but to research these ideas to the point where they do become practical, no? But then again, I agree with you, he does keep going on about the same ideas again and again and again, without pointing to the slightly more practical details... Basically ever. It's always "no what we do is bad, all of it, haha don't we suck?" "Look at these cathedrals and ant hills! Why can't we do that???"

zumu 8y ago

> The obvious advantage being that biology scales an immeasurable amount better than whatever architectures we ever come up with. Not sure what you mean by this. In the general case, the hard part of "scaling" is building systems that are easy to reason about / maintain as the complexity / throughput increases. Meanwhile, biology is notoriously difficult to reason about and maintain (think medicine).

TelmoMenezes 8y ago
Conventional software engineering is extraordinarily brittle, in the sense that any random mutation to a program is likely to cause catastrophic failure: it is very likely that it will not even be valid anymore, or behave in a completely different way. In this scenario, complexity is the enemy, and we take all the well known-measures that are taken in human engineering to manage complexity. When one dreams of a biological approach, one is interested in replicating the "graceful degradation" aspect of biological structures, which is the opposite of brittleness. If you remove one random cell from your body, it will make virtually no difference. If you remove 1K random cells, you will still not notice anything. If you remove 1M cells, maybe it's not so nice, etc. Biological systems have fewer central points of failure and are much better at adapting to unexpected situations. In this case, complexity can be our friend. I believe it is possible to learn how to design systems more like nature does, and I think this is Kay's dream.

jdonaldson 8y ago

FWIW I had Alan Kay's biologically-inspired "message passing" approach when I wrote a routing library : https://github.com/jdonaldson/golgi https://github.com/jdonaldson/golgi The premise was to start with a standard class-based instance, and then use metaprogramming to autodefine a corresponding ADT for all possible typed responses from the API. This gets around the main problem of message routing (IMHO): Namely, if you're relying on a host system to interpret your message how it sees fit, then you don't really know how it will respond in a given case. Will it error? Will it call something different than what you thought? The solution is just to enumerate every possible response type, and return a corresponding composite type as an ADT. I was doing that manually in a few prior cases, and then realized I could use the macro programming features in Haxe to do something automatically, and put together a library as a POC. I'm certain that FP purists would argue that this is equivalent to some other pre-existing type transformation... but I haven't found it yet. I'm interested if anyone else has been experimenting in this area.

hota_mazi 8y ago

> The big idea of message passing is that it's not about message passing, I think what Alan Kay has been trying to say all these year is that we should look at how bacteria communicate, and try to mimic that. It is such a horrible programming model, though. Making calls and sometimes they get picked up and sometimes not?!? If we're talking remote processes, sure, that's understandable, remote resources are not always available. But in-process? If I call a function on an object, I want the compiler to tell me right now if this code makes sense, and the compiler should stop me right away if that code cannot possibly work once deployed.

function_seven 8y ago
I don't think it's about sending a message into the void and "hoping" that a compatible agent receives the message. Rather, it's about your object not having to know who is handling the message, only what the message is ("what" in both content and type). It's still up to you as the programmer to make sure that you have implemented the other objects to act on whatever message types your code will pass. Just like it's up to you to make sure the method exists in the target class when the caller tries to invoke it. Later on, if you decide to swap out your logging infrastructure for a different one, you don't need to update all the places that called the old one. You just tell your new logger to listen for messages directed at Logger.
- macleginn 8y ago
  But is it possible for the compiler to check that some object was actually set to wait to receive a particular message that another object was instructed to send? When coding with method calls, it is possible to accidentally leave a stub instead of method code that is supposed to produce some important side effect, say, but at least you know where to look.
- da_chicken 8y ago
  > I don't think it's about sending a message into the void and "hoping" that a compatible agent receives the message. Except that is the bacterial model. When you want something done, you signal for it by releasing proteins, and keep releasing proteins until you're satisfied even if the work ended up being done 50 times more than you needed. That's why biological systems so commonly overreact to stimulus. The biological method is to flood communication until whatever demanded response is met. It's the equivalent of a user mashing a button until a program responds, like the elevator button problem. Actually, elevators seem like an extremely good analogy for this kind of asynchronous service system. I understand we're not trying to perfectly mimic the analogy, but I think it's important to see that nature's model, while robust and asynchronous, carries significant problems due to how it communicates. It's that very robustness that we're trying to mimic, so we should expect to inherit some of the problems that go along with it.

jimmy_ruska 8y ago

Sussman of SICP fame gave a similar analogy. Not really about messaging but about biology in general - https://www.youtube.com/watch?v=O3tVctB_VSU https://www.youtube.com/watch?v=O3tVctB_VSU