How does Rx relate to reactive programming? [closed]

Question

I've read about the basic idea of reactive programming as having variables that change over time based on their source value expression. I've even implemented this using Expressions. But then I look at Microsoft's Reactive Extensions (Rx) and see something totally different. Where are the variables that self-update over time? There are none to be seen. Just some fancy way of enumerating through event arguments.

So my question is: how "reactive" is Rx really? Is the functionality that we're seeing there now a precursor to what's to come? Or is Microsoft carelessly throwing around a buzz word? Or am I just totally missing the point (in which case I'd like you to explain how)?

EDIT: I got some great answers already with descriptions of Rx, in addition the question being closed. :( But I'm still hoping to hear more along the lines of:

1. In what sense is Rx "reactive"? I thought that self-updating variables were central to the idea but Rx doesn't supply these. LINQ-to-Events seems like a better name for Rx. I'm starting to think that maybe Microsoft misused the word "reactive" in applying it to Rx.
2. In what way might the current Rx functionality be a precursor to self-updating variables? I've implemented such functionality and did not notice anything useful from Rx for this purpose.

Answer 1

"Reactive" might be more of a buzz-word than anything, although it does tie in nicely to another language concept called "Functional Reactive Programming"...

At any rate, what Rx "is" has been answered by far more intelligent people than myself, but I'll give it a go:

• In the beginning, there were things; these things had shape, and were called POCOs

• Collections of these POCOs formed, and thus they were named IEnumerable<T>

• "But what of events" the people moaned and wailed, "They do not fit nicely into collections and groups! We must create strange and alien-feeling call and response handlers to cope with them!"

• It was then that TheErik, TheBart and others looked at these strange events and thought "Hey, we can make them act like POCOs, for they are but the mirror image of the IEnumerable<T>!"

• This was the birth of the IObservable<T>, the dual of the IEnumerable<T> (for the stream "pushes" information to the observer, instead of the observer "pulling" items out)

• Then I got sick of writing in "Genesis Mode", and those really smart folks bundled up the same monadic query logic that formed LINQ along with the ability to "time-travel" with ISchedulers and called it "Rx"

Answer 2

Oh boy! Okay. I think that the main issue here is vocabulary. Rx is often described as a Linq to "Event" or something of the like, and is implemented with something called an IObservable.

I am sure everyone who has just started out in Rx will have fallen for the same pitfalls. When we see the word 'event' we think of the keyword event/event handler etc etc... However in the context of Rx, an event is more general than that. It is anything that happens asynchronously, most likely on another thread. Now of course, one type of event is the .net event, and there is some value in using the Observable.FromEventPattern factory method for creating event handler-> IObservables, as the life cycle of them is represented as a IDisposable (but more about that later).

Another usage of Rx is data parallelism, in that it overlaps heavily with TPL Data Flow. A typical pattern I use for a large data parallel piece of work is to convert it to an Rx IObservable and then apply the processing/threading behaviors as monads.

With respect to the fancy part, IObservable has a Linq provider, which allows you to use Linq to process asynchronous processes asynchronously (for example Speculative execution using the TPL).

Finally IObservable is an unfortunate name as it leads most people to confuse it with the idea of INPC as it looks similar to ObservableCollection. I assure you its not.