Has RX Extensions "solved" the problem of complex event driven programming?

Question

I've been using Rx on a new financial analysis project that receives all data asynchronously. I've been pretty amazed at my personal productivity and how much more understandable my event based code is (as opposed to the previous model of event handlers with complex nested ifs and random state variables everywhere.). Has anyone else got a chance to play with it, and if so what are some of your thoughts?

Popish

Answer 1

I believe the Reactive Extensions dramatically simplify some portions of complex, event driven programming, but the problem as a whole is not "solved".

It does handle many situations is a much cleaner, more elegant manner than previously possible. However, it does not (necessarily) always help on the generation side of some asynchronous patterns, where event driven programming is still difficult. Rx really is focused on handling the subscription side of the event, but not necessarily the producing side of the equation.

For some distinct samples, and an idea of what is being considered for future versions of C# to handle some of the more complex asynchronous models, I'd recommend watching Luca Bolognese's PDC Talk. He presented some ideas the language team is working on to help on the authoring side of asynchronous development, such as an "iterator" like syntax to produce an IAsync<T> directly, with language features to support the generation of the events.

Halation

Reed, excellent answer as always. You also made me realize that I should have calibrated my question to reflect the difficulties developers face as consumers of events, which involve a lot of difficult synchronization, and whether rx addresses those concerns. – Popish

Answer 2

In http://channel9.msdn.com/posts/DC2010T0100-Keynote-Rx-curing-your-asynchronous-programming-blues, Bart de Smet excellently explains how handling event streams as a first-class concept raises the level of abstraction by making you think about how you implement eg. Throttle or DistinctUntilChanged every time imperatively with lots of error-prone boilerplate code. These operators encapsulate these behaviors in a reusable and composable way. So my opinion is that there is certainly room for further evolution (see e.g. the concerns about cold observables), but these tools should be in every developer's toolbox. The usual control flow constructs may cut it for single-threaded execution, but in today's highly concurrent, distributed world, I think Observable (or even better, EventStream/Property) is a proper abstraction.

Dux

Answer 3

No. The problem of complex event driven programming stems from the fact that any complex event driven computation is represented with a dynamic cyclic graph. That graph cannot be represented conveniently using linear programming text. The only way out is to have multiple tools to convert textual program representation to visual graphic form and back, and to check program correctness dynamically and statically.

Minuscule

Answer 4

I've just seen a webcast on RX extensions, not played with it, and found the explication too complicated... I thought the creators were architect astronauts.

For now I just don't see where is the problem with classic event handler... I have always found elegant solution when I had to use asynchronous communication between a client and a service.

However I'm curious with experiences from other people with this framework, depending on answers of this thread, I'll give it another try.

Excommunicatory

There is no problem, just RX makes it easier. For example, drag and drop, in order to process it you have to pass around a flag in your events whether mouse button is clicked or not. With RX you can subscribe to Mouse down, up, move etc and than use LINQ to process event without needing to pass a flag in the event for example. – Stockish