3 ms·

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 SQ

by 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".
- pacala 10y ago
  There are two distinct meanings mushed together under the "messaging" umbrella: A. One way communication, aka events, goto. Very useful as an implementation concept, but generally a poor idea for structuring applications, as it makes local reasoning about code harder than necessary. B. Polymorphism, aka closures. This is a very useful device for modularizing code, albeit, in practice, vastly overused. It also happens to trivially fall out from the concept of "first class function". To have first class functions, we need to be able to create them at any point in the program, thus we need some form of variable capture to allow value capture, which was named "closure", in the example below "function g closes over variable x". Furthermore, we need to be able to return the function value we just created and invoke it later, in the example below the invocation of q(4) actually invokes the closure of g over 3. Once we have first class functions, we can add any number of concrete syntactic sugar constructs [classes, vtables, etc, etc, etc]. def f(x) = { def g(y) = { x + y } g } val q = f(3) q(4) IMHO, the "misunderstanding of OOP" is strongly attributable to a propensity in OOP community for using ambiguous terminology to pretend it possesses some sort of silver bullet, instead of recognizing the rather elementary computation constructs obscured by said terminology. In some alternate universe, we'd use "events" and "closures", and there will be very little misunderstanding. "messaging" is a false friend between computer languages and real world experience.
coldtea 10y ago
>Message passing implies one way broadcast. Where did you see that? That's not what the kind of messages we talk about are (e.g. in Smalltalk). Perhaps (as some other commenter said) you have modern message queues in mind?

by pacala 10y ago

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".
pacala 10y ago
There are two distinct meanings mushed together under the "messaging" umbrella: A. One way communication, aka events, goto. Very useful as an implementation concept, but generally a poor idea for structuring applications, as it makes local reasoning about code harder than necessary. B. Polymorphism, aka closures. This is a very useful device for modularizing code, albeit, in practice, vastly overused. It also happens to trivially fall out from the concept of "first class function". To have first class functions, we need to be able to create them at any point in the program, thus we need some form of variable capture to allow value capture, which was named "closure", in the example below "function g closes over variable x". Furthermore, we need to be able to return the function value we just created and invoke it later, in the example below the invocation of q(4) actually invokes the closure of g over 3. Once we have first class functions, we can add any number of concrete syntactic sugar constructs [classes, vtables, etc, etc, etc]. def f(x) = { def g(y) = { x + y } g } val q = f(3) q(4) IMHO, the "misunderstanding of OOP" is strongly attributable to a propensity in OOP community for using ambiguous terminology to pretend it possesses some sort of silver bullet, instead of recognizing the rather elementary computation constructs obscured by said terminology. In some alternate universe, we'd use "events" and "closures", and there will be very little misunderstanding. "messaging" is a false friend between computer languages and real world experience.

coldtea 10y ago

>Message passing implies one way broadcast. Where did you see that? That's not what the kind of messages we talk about are (e.g. in Smalltalk). Perhaps (as some other commenter said) you have modern message queues in mind?