Hacker News Reader

Comment by ninjakeyboard | Hacker News Reader

Reactive programming - you mean like reactive like reactive manifesto? That's not event driven. See recent published manifesto (http://www.reactivemanifesto.org/): they describe message driven paradigms, not event driven ones (now - this is a revision). But that's only a very small part of it! Recommend "Reactive Design Patterns" the free chapter from manning press: http://www.manning.com/kuhn/RDP_meap_CH01.pdf

View on HN

describe message driven paradigms, not event driven ones

Messages are events.

Reactive programming - you mean like reactive like reactive manifesto?

That seems to be more about idealized system properties than about a style of programming. (Plus at least one bit of silliness, w.r.t. blocking / non-blocking being inherently inequal.)

Not exactly. Messages and events are dual to each other. Messages are sender centric. The sender determines the links to the receivers. The receiver listens regardless of who's sending.

Events are receiver centric. The receiver explicitly chooses what senders to listen to. The sender fires off events without regard for who's listening.

I'm not sure how much distinction actually matters in terms of expressive power, but it does seem to impact how the paradigms are used in practice.

> The receiver explicitly chooses what senders to listen to.

Not necessarily. The receiver could just specify what kind of messages to receive instead, and be decoupled from the sender.

Thanks for the links - Reactive Design Patterns is a great read. On the bottom of the first page, they list FP, futures & promises, CSPs, observers and observables (i.e. Rx), and actors as tools of the trade. Then in the third chapter they look at each tool and evaluate it on the basis of "reactive classification" as per the manifesto (including message passing, which is one of the tenets). In my view, it is not presented as a purely reactive/not reactive dichotomy, but more of a sliding scale - a given tool may satisfy some tenets and not the rest.

Actor model is arguably the most robust with respect to the proposed classification, but the authors also point out that it is not be-all and end-all and that specific problems or even portions of your system may call for different patterns.

Reply on news.ycombinator.com