Requesting a clear, picturesque explanation of Reactive Extensions (RX)?

Question

For a long time now I am trying to wrap my head around RX. And, to be true, I am never sure if I got it - or not.

Today, I found an explanation on http://reactive-extensions.github.com/RxJS/ which - in my opinion - is horrible. It says:

RxJS is to events as promises are to async.

Great. This is a sentence so full of complexity that if you do not have the slightest idea of what RX is about, after that sentence you are quite as dumb as before.

And this is basically my problem: All the explanations in the usual places you find about RX make (at least me) feel dumb. They explain RX as a highly sophisticated concept with lots of highly complicated words and terms and whatsoever, and I am never quite sure what it is about.

So my question is: How would you explain RX to someone who is five years old? I'd like a clear, picturesque explanation of what it is, what it is good for, and what its main concepts are?

Wetterhorn

Just to be clear, if this turns into a link-fest its going to get closed as not constructive. But if we can get some good answers in here hitting the highlights with a little code, I'll be happy as well to read them. – Obnoxious

Very helpful answers in this question, so thanks for asking it :) – Nikkinikkie

Answer 1

So, LINQ (in JavaScript, these are high-level array methods like map, filter, reduce, etc - if you're not a C# dev, just replace that whenever I mention 'LINQ') gives you a bunch of tools that you can apply to Sequences ("Lists" in a crude sense), in order to filter and transform an input into an output (aka "A list that's actually interesting to me"). But what is a list?

What is a List?

A List, is some elements, in a particular order. I can take any list and transform it into a better list with LINQ.

(Not necessarily sorted order, but an order).

An Event is a List

But what about an Event? Let's subscribe to an event:

OnKeyUp += (o,e) => Console.WriteLine(e.Key)
>>> 'H'
>>> 'e'
>>> 'l'
>>> 'l'
>>> 'o'

Hm. That looks like some things, in a particular order. It now suddenly dawns upon you, a list and an event are the same thing!

If Lists and Events are the Same....

...then why can't I transform and filter input events into more interesting events. That's what Rx is. It's taking everything you know about dealing with sequences, including all of the LINQ operators like Select and Where and Aggregate, and applies them to events.

Easy peasy.

A Callback is a Sequence Too

Isn't a Callback just basically an Event that only happens once? Isn't it basically just like a List with one item? Turns out it is, and one of the interesting things about Rx is that it lets us treat Events and Callbacks (and things like Geolocation requests) with the same language (i.e. we can combine the two, or wait for ether one or the other, etc etc).

Pisci

I think this answer makes a great start, but would benefit from some code samples, especially to demonstrate how Rx can make events, callbacks and similar asynchronous "streams" composable. For instance, contrasting a chain of two or more event handlers with composed IObservables, especially when extra complexity like marshalling onto UI threads is involved. – Traveler

@shambulator That's not what the question is asking for. Adding code to this answer would just make it longer. If you want code examples there are plenty on the web. – Prelacy

Absolutely brilliant answer! This is the clearest answer I have ever seen that describes why RX was introduced. – Izy

Answer 2

Along with Paul's excellent answer I'd like to add the concept of pulling vs pushing data.

Pipeline

Lets take the example of some code that generates a series of numbers, and outputs the result. If you think of this as a stream on one end you have a producer that is creating new numbers for you, and on the other end you have a consumer that is doing something with those numbers.

Pull - Primes List

Lets say the producer is generating a list of prime numbers. Normally you would have some function that yields a list of numbers, and every time it returned it would push the next value it has calculated through the pipe to the consumer, which would output that number to the screen.

Prime Generator ---> Console.WriteLine

In this scenario it is easy to see that the producer is doing most of the work, and the consumer would be sitting around waiting for the producer to send the next value. The consumer is pulling on the pipeline, waiting for the producer to return the next value.

Push - Progress percent events from a fast process (Reactive)

Ok, let's say you have a function that is processing 1,000,000 items. Each item takes milliseconds to process, and then the function yields out a percentage value of how far it has gotten. So lots of progress values, very fast.

At the other end of the pipeline you have a progress bar. Now if the progress bar was to handle every update the UI would block trying to keep up with the stream of values.

1-Million-Items-Processor ---> Progress Bar

In this scenario the data is being pushed through the pipeline by the producer and then the consumer is blocking because too much data is being pushed for it to handle.

Reactive allows you to put in delays, windows, or to sample the pipeline depending on how you wish to consume the data. In this case I would sample the data every second before updating the progress bar.

Lists vs Events

So lists and events are kinda the same. The difference is whether the data is pulled or pushed through the system. With lists the data is pulled. With events the data is pushed.

Prelacy

This is a great answer too! – Pisci