[Pitarou]

TL;DR

Reactive programming is ill-defined and over-hyped, so let's talk about types and math instead (plus some not-very-subtle in-jokes about Microsoft).

An enumerator is basically a getter with the ability to fail and / or terminate. It might also return a promise rather than a value. An enumerable is a getter that returns an enumerator. We can express all this very cleanly in generic types. And if we take the category-theoretic dual of these types we get the observer and observable types.

So who needs reactive? ;-)

[seanmcdirmid]

What people really want is managed time.

[auxon0]

What kind of scenario are you thinking of? Rx has virtual time with the use of schedulers that enables you to abstract over time, which is very cool. http://channel9.msdn.com/shows/Going+Deep/Wes-Dyer-and-Jeffr...

[seanmcdirmid]

This isn't really virtual time though, at least as realized by time warp. It's a virtualization of time, for sure, but almost completely unrelated to DR Jefferson's work [1]; no rollback of bad interactions or anything like that.

[1] http://dl.acm.org/citation.cfm?id=3988

Rx is a one trick pony that focuses exclusively on the duality between event streams and data streams. Management of time in any real sense is completely missing from the framework. No continuous bindings, control flow must all be buried as data flow, etc...

React is a much better solution for writing reactive programs than Rx.

[auxon0]

Brian Beckman worked on the Time Warp OS, with Dr. Jefferson [1] and was involved with the development of Rx virtual time. You can read his comment about how Rx virtual time could be used to create a Time Warp monad. [2].

Are you speaking about React.js? Erik's point about reactive being a buzzword and distorted is proven by that because it's not the same thing at all. React.js is cool and all that but it has nothing to do with guaranteed composition and dealing with side-effects and monadic operators. That's like saying Angular.js is better than list operations and functions that operate on lists.

[1] http://dl.acm.org/citation.cfm?id=37508&CFID=356264587&CFTOK... [2] http://channel9.msdn.com/Shows/Going+Deep/Expert-to-Expert-R...

[seanmcdirmid]

That is a nice link, thanks! The previous video one was not talking about the same virtual time, as far as I can tell.

My point was that if you were building user interfaces, react would get you much further than Rx, which is a hammer looking for a problem where it is actually better.

If you want the ability to deal with side effects, I'm working that in my own work while avoiding burying everything in data flow:

http://research.microsoft.com/apps/pubs/default.aspx?id=2112...

Ironically, I started this work while working for Martin with the goal of making the scala compiler more "reactive" (the ability to responsively react to change); I actually succeeded while making minimal changes to scalac. Like actors or FRP, Rx can't be applied to scalac either, which desperately needs to be reactive to fit into the IDE. Rx's idea of reactivity revolves around event streams, virtual, managed time and frameworks like react attack the problem of change directly. Erik is right about useless definitions, but one based around change really works.

[skrebbel]

I believe that you're right, but with that attitude "against" an institution like Erik Meijer, you're not gathering many popularity points :-)