12 ms·

I don't really understand this obsession with messages. We're moving away from it. This is not how we program in the 21st century. The last popular language th

I don't really understand this obsession with messages. We're moving away from it. This is not how we program in the 21st century. The last popular language that supported this paradigm (Objective C) is being replaced and will probably be all but gone in just a few years as Swift (not message based) takes it place. Besides, this idea of message passing is really not that useful for modern programming anyway but a lot of people still have this weird idea that message passing magically solves the problem of data integrity in parallelism. It doesn't. It does nothing to solve it. You can still have deadlocks and you can still have data corruption. The only approach that has provably improved our problems in this area is immutability, but even that paradigm comes at a cost that sometimes doesn't make it worth the trouble

_asummers 10y ago
What about e.g. HTTP? The dynamics of server to server communication are all about message passing (REST is just a message conveying state, if you ignore the other rules). Look at things like Erlang and Elixir processes. Akka and the actor model. Map/Reduce to a certain extent. These are all founded on the idea of giving a task out with enough information that the worker can reasonably go and work on the task without having to look around for state. Also look at things like FRP and more event driven architectures. While not ThingA sends message to ThingB, ThingA still broadcasts a message, possibly containing the relevant state. Also almost forgot. Look at the wealth of message queues that exist (RabbitMQ, ActiveMQ, SQS, Kafka, ... the list goes on).
- ivan_gammel 10y ago
  HTTP is closer to RPC. You always know the address of the routine to call, so it's not actually a message (except in HATEOAS, in which you first need to learn the next address from last API call). Closest analogy is the message queue (e.g. ESB) like Active MQ or Rabbit MQ (and the whole JMS tech), in which you do actually send a message and infrastructure does actually figure out who will receive and process it.
  - specialist 10y ago
    HTTP(S) is the opposite of RPC (meaning: message-based). Both SOAP and XML-RPC tried to remedy that.
    - ivan_gammel 10y ago
      How exactly it is opposite?
      - specialist 10y ago
        Difference between document (message-passing) and RPC styles: http://stackoverflow.com/questions/9062475/what-is-the-difference-between-document-style-and-rpc-style-communication http://stackoverflow.com/questions/9062475/what-is-the-diffe... Replace SOAP with HTTP, since SOAP is just an ill-advised, unnecessary, redundant obfuscation layer on top of HTTP, and so contrast still applies.
- kmiroslav 10y ago
  I was talking about programming languages. Obviously, message passing is alive and well for network protocols.
- pacala 10y ago
  Message passing implies one way broadcast. Think GOTO. HTTP is a request / reply protocol, i.e. a function call. Map / Reduce is an implementation device for SQL-like collection-based processing, modern Map / Reduce systems [Google's Flume / Dataflow] offer directly the collection API, using Map / Reduce as an implementation detail. FRP is a device for adding a collection API on top of streams of events. Collection APIs are conceptually function calls over collections [duh]. Just because your compiler uses GOTO / messaging behind the scenes to implement function calls, it doesn't follow that GOTO / messaging is the right API level for designing applications. We know this since 1968.
  - protomyth 10y ago
    > Message passing implies one way broadcast. Can you explain that since its contrary to my experience. PDO and normal Objective-C methods had a return and are not one way.
    - ivan_gammel 10y ago
      In modern enterprise programming message is very different concept (probably more widespread, if we'll look at popularity of Java and .Net, compared to Objective-C), which is not related to OOP. It's a pattern of integration, in which systems exchange with messages through a message broker, that abstracts them from each other. By their nature such messages are asynchronous and unidirectional.
      - infinite8s 10y ago
        That was also the original model of messaging in Smalltalk (well, without the necessity of a broker).
        coldtea 10y ago
        Smalltalk receivers returned values to the senders of the message. Plus, they were synchronous. So, while indeed still messaging, I'm not sure about the similarity to message queues/brokers in modern enterprise, where, as the parent said "By their nature such messages are asynchronous and unidirectional".
macintux 10y ago
Erlang and Elixir may not meet your criteria of popular, but message passing is one of several closely linked features (including immutability) that collectively make distributed, robust systems much easier. No, it's not a silver bullet, but neither is it some misbegotten relic of an earlier era as you posit.
jrochkind1 10y ago
> The last popular language that supported this paradigm (Objective C) Ruby.
deleted 10y ago
[deleted]
sb8244 10y ago
Is message passing that you're referring to different than the Ruby concept of messages? Objects respond to messages in Ruby, and it is encouraged to think of it that way rather than calling functions.
- mercer 10y ago
  Is that actually the case in practice? I haven't used Ruby enough to know, but my experience so far is that most of the time the approach is still mostly just plain method calling in practice. I vaguely recall Rails moving away from some usage of method_missing (which I'd argue is one explicit example of message passing vs method calling). Honest question, btw, I really don't know.
  - cheshire_cat 10y ago
    He said "[...] it is encouraged to think of it that way rather than calling functions." This is what Sandi Metz talks about when she speaks about message/responsibility centric design vs data-centric design in OOP. The conceptual difference is said to lead to different designs. You don't start out your design by thinking about what data you hold but you think about which responsibilities/roles you have and create objects around those by thinking how they might talk to each other to reach their goals. (I'm currently reading POODR by Sandi Metz, so this is still new to me, if I got anything wrong there then please feel free to correct me) https://www.practicingruby.com/articles/responsibility-centric-vs-data-centric-design https://www.practicingruby.com/articles/responsibility-centr...
    - hackits 10y ago
      Another good book if you're interested in actors/behaviour decomposition instead of data decomposition is: Object Design: Roles, Responsibilities, and Collaborations and also https://www.amazon.com/Object-Thinking-Developer-Reference-David/dp/0735619654 https://www.amazon.com/Object-Thinking-Developer-Reference-D... Also David West Presentation https://www.youtube.com/watch?v=RdE-d_EhzmA https://www.youtube.com/watch?v=RdE-d_EhzmA
  - 10y ago
aryehof 10y ago
>>> This is not how we program in the 21st century. Actually, for many if not most, programming today means using procedures and subroutines, organized through functional decomposition, just like was done in the 1950s and 60s. We haven't gotten that far have we. OO is a different paradigm from organizing the concepts in a domain through functional decomposition, and understanding how it is different, is key to understanding OO and messaging.
- hackits 10y ago
  Could you elaborate leading by example `how it is different`? Seriously because unless you can define it, and quantify it then it is just rhetoric.
  - deleted 10y ago
    [deleted]
  - Retric 10y ago
    Functions have no internal state. Early languages used global variables to share state across functions without explicit message passing (everything was a singleton). This created worlds of pain. The alternative was passing state with each function call. This also got painful as people often passed data down through functions. OOP lets chunks of functions share state and hide that state from the wider application. More importantly you could have multiple instances of that shard state without explicit management, saving a lot of complexity and effort.
    - jdmichal 10y ago
      > Functions have no internal state. But closures do. And thus, why closures are a poor man's objects, and objects are a poor man's closures. As an example, Java closures are really anonymous objects with the closed state as instance variables. > More importantly you could have multiple instances of that shard state without explicit management, saving a lot of complexity and effort. Technically that's what classes gives you, not objects. But agreed on the sentiment.
zeveb 10y ago
> I don't really understand this obsession with messages. > We're moving away from it. This is not how we program in the 21st century. Maybe it should be? Languages like Erlang and — to a much lesser extent — Go use message-passing semantics in at least some places. To paraphrase Chesterton, message-passing has not been tried and found wanting; it's been found unusual and not tried.
felixgallo 10y ago
We're accelerating towards messages at a very high rate of speed. This is in fact how we're starting to program in the 21st century and all programming will be of that type in the 22nd century. The last popular languages that support this paradigm (Go, Rust, Erlang, Elixir) are exploding in popularity and entering the mainstream. Message passing does in fact magically solve the problem of data integrity in parallelism when the data is immutable. Languages like Rust and Pony are starting to solve the deadlock problem, and 'data corruption' has nothing to do with messages or lack of messages.
- the_why_of_y 10y ago
  Rust does many a nice thing, but nothing to solve deadlocks.
infinite8s 10y ago
>> This is not how we program in the 21st century Sadly, how we program in the 21st century isn't much different to how we programmed in the early 20th century when computers were first invented (at least to a 1st order approach). Where are the Maxwell equations of Computer Science?
- ruraljuror 10y ago
  Perhaps this is what you're referring to, but according to Kay they can be found in Lisp. http://queue.acm.org/detail.cfm?id=1039523 http://queue.acm.org/detail.cfm?id=1039523 https://www.amazon.com/LISP-Programmers-Manual-Michael-Levin/dp/0262130114/ref=sr_1_1?ie=UTF8&qid=1466786117&sr=8-1&keywords=lisp+1.5 https://www.amazon.com/LISP-Programmers-Manual-Michael-Levin...
somethingsimple 10y ago
This is anecdotal, but my 8-year old daughter found it quite intuitive to learn programming based on message passing (on Scratch).
lbenes 10y ago
No, message passing doesn’t solve all the problem of parallelism, but it is one of the most powerful and useful tools to have in our toolkit when attacking these problems. I hope it doesn’t dominate as OOP did in the 90s, as many other models such as actor and dataflow still have a lot of room for research and improvement.
- chc 10y ago
  Actors are based on message-passing as well. The paradigm favored by Go and Erlang is CSP, which is a pretty interesting idea that revolves around message-passing, but it doesn't have a monopoly on the practice.
njharman 10y ago
Every http request/response is a message. Every task queue, every AMQP/message system are message based systems. Modern development is lousy with message based architectures. It's just at the system level and not natively supported paradigm in most languages.
notduncansmith 10y ago
Message-passing is a necessary but insufficient abstraction. It's not pixie dust, but if you want to build a robust and organized system you'll probably want to reach for it. For the data integrity issue, you need to have a strong data model implemented upon your message-passing architecture, like an immutable event log. Project useful aggregations and indices from that. I'm wrapping up an implementation of exactly this today (Node.js + Kafka = poor man's Erlang actors), AMA. Email is in my profile as well.
watchxxx 10y ago
Well said Cedric!
coldtea 10y ago
>I don't really understand this obsession with messages. We're moving away from it. On the contrary. We use it more than ever -- only similarly to Greenspun's tenth rule -- in "ad-hoc" and crappier implementations. What do you think REST microservices are beneath the surface for example? Or AJAX, WebWorkers, SOAP. Etc. The bad parts of messaging without the flexibility (or even the performance of Smalltalk of the 90s) (Incidentally, Erlang/Elixir gets this right, Akka, etc). Or, all the Rabbit, Duck, Donkey MQs, ZeroMQs, pub/sub, event emitters etc out there. >This is not how we program in the 21st century That's more of a problem of the 21st century that messages. >Besides, this idea of message passing is really not that useful for modern programming anyway but a lot of people still have this weird idea that message passing magically solves the problem of data integrity in parallelism. It doesn't. It does nothing to solve it. You can still have deadlocks and you can still have data corruption. Deadlocks are not related to data integrity, so they're another story. As for "data corruption", messages where values are copied (and thus immutable) are not really prone to it compared to "how we program in the 21st century".
deleted 10y ago
[deleted]
tamana 10y ago
Message passing (and by extension Smalltalk/Squeak) suffers from LISP disease, the notion that because the system makes no constraints on program structure, it can do anything, and therefore is maximally powerful. But "can do anything" is different from "does anything". In real programs you have to solve performance, security, evolving product features needs, a growing team of contributors , static analysis tools to make global changes to the axioms of the system, all those details that matter when software leaves the lab and enters industry.

_asummers 10y ago

What about e.g. HTTP? The dynamics of server to server communication are all about message passing (REST is just a message conveying state, if you ignore the other rules). Look at things like Erlang and Elixir processes. Akka and the actor model. Map/Reduce to a certain extent. These are all founded on the idea of giving a task out with enough information that the worker can reasonably go and work on the task without having to look around for state. Also look at things like FRP and more event driven architectures. While not ThingA sends message to ThingB, ThingA still broadcasts a message, possibly containing the relevant state. Also almost forgot. Look at the wealth of message queues that exist (RabbitMQ, ActiveMQ, SQS, Kafka, ... the list goes on).

ivan_gammel 10y ago
HTTP is closer to RPC. You always know the address of the routine to call, so it's not actually a message (except in HATEOAS, in which you first need to learn the next address from last API call). Closest analogy is the message queue (e.g. ESB) like Active MQ or Rabbit MQ (and the whole JMS tech), in which you do actually send a message and infrastructure does actually figure out who will receive and process it.
- specialist 10y ago
  HTTP(S) is the opposite of RPC (meaning: message-based). Both SOAP and XML-RPC tried to remedy that.
  - ivan_gammel 10y ago
    How exactly it is opposite?
    - specialist 10y ago
      Difference between document (message-passing) and RPC styles: http://stackoverflow.com/questions/9062475/what-is-the-difference-between-document-style-and-rpc-style-communication http://stackoverflow.com/questions/9062475/what-is-the-diffe... Replace SOAP with HTTP, since SOAP is just an ill-advised, unnecessary, redundant obfuscation layer on top of HTTP, and so contrast still applies.
kmiroslav 10y ago
I was talking about programming languages. Obviously, message passing is alive and well for network protocols.
pacala 10y ago
Message passing implies one way broadcast. Think GOTO. HTTP is a request / reply protocol, i.e. a function call. Map / Reduce is an implementation device for SQL-like collection-based processing, modern Map / Reduce systems [Google's Flume / Dataflow] offer directly the collection API, using Map / Reduce as an implementation detail. FRP is a device for adding a collection API on top of streams of events. Collection APIs are conceptually function calls over collections [duh]. Just because your compiler uses GOTO / messaging behind the scenes to implement function calls, it doesn't follow that GOTO / messaging is the right API level for designing applications. We know this since 1968.
- protomyth 10y ago
  > Message passing implies one way broadcast. Can you explain that since its contrary to my experience. PDO and normal Objective-C methods had a return and are not one way.
  - ivan_gammel 10y ago
    In modern enterprise programming message is very different concept (probably more widespread, if we'll look at popularity of Java and .Net, compared to Objective-C), which is not related to OOP. It's a pattern of integration, in which systems exchange with messages through a message broker, that abstracts them from each other. By their nature such messages are asynchronous and unidirectional.
    - infinite8s 10y ago
      That was also the original model of messaging in Smalltalk (well, without the necessity of a broker).
      - coldtea 10y ago
        Smalltalk receivers returned values to the senders of the message. Plus, they were synchronous. So, while indeed still messaging, I'm not sure about the similarity to message queues/brokers in modern enterprise, where, as the parent said "By their nature such messages are asynchronous and unidirectional".

macintux 10y ago

Erlang and Elixir may not meet your criteria of popular, but message passing is one of several closely linked features (including immutability) that collectively make distributed, robust systems much easier. No, it's not a silver bullet, but neither is it some misbegotten relic of an earlier era as you posit.

jrochkind1 10y ago

> The last popular language that supported this paradigm (Objective C) Ruby.

deleted 10y ago

[deleted]

sb8244 10y ago

Is message passing that you're referring to different than the Ruby concept of messages? Objects respond to messages in Ruby, and it is encouraged to think of it that way rather than calling functions.

mercer 10y ago
Is that actually the case in practice? I haven't used Ruby enough to know, but my experience so far is that most of the time the approach is still mostly just plain method calling in practice. I vaguely recall Rails moving away from some usage of method_missing (which I'd argue is one explicit example of message passing vs method calling). Honest question, btw, I really don't know.
- cheshire_cat 10y ago
  He said "[...] it is encouraged to think of it that way rather than calling functions." This is what Sandi Metz talks about when she speaks about message/responsibility centric design vs data-centric design in OOP. The conceptual difference is said to lead to different designs. You don't start out your design by thinking about what data you hold but you think about which responsibilities/roles you have and create objects around those by thinking how they might talk to each other to reach their goals. (I'm currently reading POODR by Sandi Metz, so this is still new to me, if I got anything wrong there then please feel free to correct me) https://www.practicingruby.com/articles/responsibility-centric-vs-data-centric-design https://www.practicingruby.com/articles/responsibility-centr...
  - hackits 10y ago
    Another good book if you're interested in actors/behaviour decomposition instead of data decomposition is: Object Design: Roles, Responsibilities, and Collaborations and also https://www.amazon.com/Object-Thinking-Developer-Reference-David/dp/0735619654 https://www.amazon.com/Object-Thinking-Developer-Reference-D... Also David West Presentation https://www.youtube.com/watch?v=RdE-d_EhzmA https://www.youtube.com/watch?v=RdE-d_EhzmA
- 10y ago

aryehof 10y ago

>>> This is not how we program in the 21st century. Actually, for many if not most, programming today means using procedures and subroutines, organized through functional decomposition, just like was done in the 1950s and 60s. We haven't gotten that far have we. OO is a different paradigm from organizing the concepts in a domain through functional decomposition, and understanding how it is different, is key to understanding OO and messaging.

hackits 10y ago
Could you elaborate leading by example `how it is different`? Seriously because unless you can define it, and quantify it then it is just rhetoric.
- deleted 10y ago
  [deleted]
- Retric 10y ago
  Functions have no internal state. Early languages used global variables to share state across functions without explicit message passing (everything was a singleton). This created worlds of pain. The alternative was passing state with each function call. This also got painful as people often passed data down through functions. OOP lets chunks of functions share state and hide that state from the wider application. More importantly you could have multiple instances of that shard state without explicit management, saving a lot of complexity and effort.
  - jdmichal 10y ago
    > Functions have no internal state. But closures do. And thus, why closures are a poor man's objects, and objects are a poor man's closures. As an example, Java closures are really anonymous objects with the closed state as instance variables. > More importantly you could have multiple instances of that shard state without explicit management, saving a lot of complexity and effort. Technically that's what classes gives you, not objects. But agreed on the sentiment.

zeveb 10y ago

> I don't really understand this obsession with messages. > We're moving away from it. This is not how we program in the 21st century. Maybe it should be? Languages like Erlang and — to a much lesser extent — Go use message-passing semantics in at least some places. To paraphrase Chesterton, message-passing has not been tried and found wanting; it's been found unusual and not tried.

felixgallo 10y ago

We're accelerating towards messages at a very high rate of speed. This is in fact how we're starting to program in the 21st century and all programming will be of that type in the 22nd century. The last popular languages that support this paradigm (Go, Rust, Erlang, Elixir) are exploding in popularity and entering the mainstream. Message passing does in fact magically solve the problem of data integrity in parallelism when the data is immutable. Languages like Rust and Pony are starting to solve the deadlock problem, and 'data corruption' has nothing to do with messages or lack of messages.

the_why_of_y 10y ago
Rust does many a nice thing, but nothing to solve deadlocks.

infinite8s 10y ago

>> This is not how we program in the 21st century Sadly, how we program in the 21st century isn't much different to how we programmed in the early 20th century when computers were first invented (at least to a 1st order approach). Where are the Maxwell equations of Computer Science?

ruraljuror 10y ago
Perhaps this is what you're referring to, but according to Kay they can be found in Lisp. http://queue.acm.org/detail.cfm?id=1039523 http://queue.acm.org/detail.cfm?id=1039523 https://www.amazon.com/LISP-Programmers-Manual-Michael-Levin/dp/0262130114/ref=sr_1_1?ie=UTF8&qid=1466786117&sr=8-1&keywords=lisp+1.5 https://www.amazon.com/LISP-Programmers-Manual-Michael-Levin...

somethingsimple 10y ago

This is anecdotal, but my 8-year old daughter found it quite intuitive to learn programming based on message passing (on Scratch).

lbenes 10y ago

No, message passing doesn’t solve all the problem of parallelism, but it is one of the most powerful and useful tools to have in our toolkit when attacking these problems. I hope it doesn’t dominate as OOP did in the 90s, as many other models such as actor and dataflow still have a lot of room for research and improvement.

chc 10y ago
Actors are based on message-passing as well. The paradigm favored by Go and Erlang is CSP, which is a pretty interesting idea that revolves around message-passing, but it doesn't have a monopoly on the practice.

njharman 10y ago

Every http request/response is a message. Every task queue, every AMQP/message system are message based systems. Modern development is lousy with message based architectures. It's just at the system level and not natively supported paradigm in most languages.

notduncansmith 10y ago

Message-passing is a necessary but insufficient abstraction. It's not pixie dust, but if you want to build a robust and organized system you'll probably want to reach for it. For the data integrity issue, you need to have a strong data model implemented upon your message-passing architecture, like an immutable event log. Project useful aggregations and indices from that. I'm wrapping up an implementation of exactly this today (Node.js + Kafka = poor man's Erlang actors), AMA. Email is in my profile as well.

watchxxx 10y ago

Well said Cedric!

coldtea 10y ago

>I don't really understand this obsession with messages. We're moving away from it. On the contrary. We use it more than ever -- only similarly to Greenspun's tenth rule -- in "ad-hoc" and crappier implementations. What do you think REST microservices are beneath the surface for example? Or AJAX, WebWorkers, SOAP. Etc. The bad parts of messaging without the flexibility (or even the performance of Smalltalk of the 90s) (Incidentally, Erlang/Elixir gets this right, Akka, etc). Or, all the Rabbit, Duck, Donkey MQs, ZeroMQs, pub/sub, event emitters etc out there. >This is not how we program in the 21st century That's more of a problem of the 21st century that messages. >Besides, this idea of message passing is really not that useful for modern programming anyway but a lot of people still have this weird idea that message passing magically solves the problem of data integrity in parallelism. It doesn't. It does nothing to solve it. You can still have deadlocks and you can still have data corruption. Deadlocks are not related to data integrity, so they're another story. As for "data corruption", messages where values are copied (and thus immutable) are not really prone to it compared to "how we program in the 21st century".

deleted 10y ago

[deleted]

tamana 10y ago

Message passing (and by extension Smalltalk/Squeak) suffers from LISP disease, the notion that because the system makes no constraints on program structure, it can do anything, and therefore is maximally powerful. But "can do anything" is different from "does anything". In real programs you have to solve performance, security, evolving product features needs, a growing team of contributors , static analysis tools to make global changes to the axioms of the system, all those details that matter when software leaves the lab and enters industry.