I can see this being useful for problems that are extremely linear and require extreme parallelization on large quantities of data, but that's about it.
That's the danger: Relying on your own lack of imagination to support your argument. If you cared to google a little you would realize that there are many other areas where RP could be relevant.
The idea is that a mouse is a series of "rows" with mouse positions and button states. Instead of viewing them as series of *events*, RP views them as streams of objects. That allows you to apply filters, actions, transformations etc.
Suddenly, the events become *composable*.
Think of a touch interface. The touch surface fires events. But if you view the events as streams of objects you can define filters and transforms which let only certain "events" through, like a stream which accepts objects starting/resetting at the "touch" but only accepts messages as long as they describe an ever longer diatance in a certain direction until the finger is lifted again. Now you have a composable stream of "flicks". You can define similar streams which will filter/generate circular moves, pinching with 2, 3 or 4 fingers.
Think of the problem of cache eviction. You can define sweeping/eviction algorithms as (simple) streams.
Think of asynchronous programming in a web browser. Parred with web sockets (or in .NET the awesome SignalR which uses web sockets but automatically falls back to other channels when web sockets are not available) you can build responsive, asynchronous interfaces where you *declare* what should happen as server messages are received.
Think of a dealer system where the dealer wants to track certain papers, positions, rates. RP enables you to build a chained, composable filter where alarms are raised (alarms being messages on streams) when a rate changes more than a certain percentage within a given time period.
I've done this 'methodology' many times using Excel.
Sure. Haven't we all?
It also uses a *lot* more ram because you are now maintaining a permanent block of memory for every single operation, for every different piece of data you are coding against.
Not neccesarily . In .NET, Reactive Extensions are integrated with LINQ. As a supplement to IObservable, Reactive Extensions also define IQbservable (a *queryable* observable). Analogous to LINQ for IQueryable, LINQ applied to a IQbservable is actually capable of combine criterias and transformations "up the chain" all the way to the source. I.e. if the "event" source is capable of filtering/transforming - like a SQL database or a RSS based web feed is - LINQ for Reactive Extensions can apply the filter very early in the chain and avoid uneccesary progression of objects which would be masked later anyway.
Is it just me, or does it seem like everyone now-a-days is trying very hard to come up with new methodologies and paradigms and web 6.5isms, so they can get their 5 minutes in the lime light?
It is not just you. There a scores of other people out there who have always done it before 20 years ago.
Grow up. Sometimes Computer Science does see advanced. Realizations. Erik Meijer did an awesome job with Reactive Programming. He found a *duality* between actively "pulling" objects from sequences and reactively receiving "pushed" objects from a source. Given the mathematical duality he even managed to find places where the LINQ pull model was not complete yet.
Reactive Programming is not new. Nor was OO when it really took off. OO actually was don back in the 1970ies with Simula (IIRC). But now RP has *matured* as is ready to go mainstream. It is an interesting approach with combines beautifully with both OO and FP.
So please spare us the "I've done that for years" chest thumping. When you at the same time demonstrate lack of imagination and lack of understanding of the topic, you just come off as an ignoramus.