[bad_user]

Erik is a little trollish when expressing his opinions. From what I noticed, he loves flames. People either love his style or hate it. I guess you're in the later group - personally I don't mind when he's mocking something I care about, because from what I observed, he's always joking or half-joking and he'll say the opposite of what he just said in a couple of weeks.

> He is dismissive of "reactive programming" as nonsense from architecture astronauts, without giving a remotely fair description of what it actually is.

That's because his presentation is from React 2014, so he can fairly assume that the audience has some idea of what he's talking about, because "reactive" is the freaking topic of this audience - http://reactconf.com/

> if you're throwing punches you should know what you're talking about

Well, he kind of does. He's one of the architects of Reactive Extensions (Rx) and now he's contributing to RxJava. I don't agree with many of his opinions, for example I think they made design mistakes while architecting Rx, but he's OK in the knowledge department ;-)

> At 17:30 he makes a joke about a Steve Jobs function that says "iPhone", "iPad", "iCloud", and then "terminates naturally". Holy bad taste.

He also makes the same joke about himself - was trying to explain how streams are terminated, either naturally or by error (the joke on himself was that he was fired, i.e. onError).

[headinthebox]

> for example I think they made design mistakes

Curious to hear more.

[louthy]

Same here. For the record I think Rx is a lovely piece of work (as is LINQ btw). I can't think of anything I'd change in the bits of Rx that I've used so far.

[platz]

One criticism is a lack of ability to express things like "back-pressure" where consumers indicate to producers to slow down, stop, etc..

[louthy]

That implies a two way dispatch which is not in the remit of reactive surely? A system that's closer to Haskell's pipes is probably what you'd want.

I think ISubject<I,O> has the interface for a pipe, with IObservable being a Producer equivalent, and IObserver being a Consumer equivalent. So there may be some cunning that could be done with your own implementations [to create an Effect]. (This is just wild brainstorming without looking at the code, so take all of this with a large pinch of salt).

Working within the Rx system, there'd be two ways of doing this:

The Observable has a mechanism for slowing down, but obviously it can't get instruction from observers - so it would have to make a judgment on what is 'too much'; a slow down would affect all observers. Definitely (well probably) not what you want.

The other way is to use the various buffering functions in Rx on the subscription, or roll your own function that has some intelligence. That localises the 'backing up' on a per observer basis, but doesn't slow down the observable itself.

To 'Stop' you could switch your subscription to Observable.Never<T> until you're ready to receive messages. Obviously you'll miss messages generated on the other stream whilst you were not listening.

[platz]

Reactive = resilient + eventbased + responsive + scalable

I think it is relevant, what allows you to ignore the behavior of the system in favor of a component?

Dean wampler in a recent talk spoke of "Reactive Streams" which add this capability, but I have not seen it yet.

I have not seen anyone do this in Rx yet. Also ideally the back pressure is out of band to avoid starvation of that channel

[louthy]

I guess have an 'out of band' observable? Each observer that needs to communicate instruction back to the original observable can drop messages into an OoB observable, the original observable can subscribe to the OoB observable and then react to those messages as it sees fit.

Or do you think it should be an inherent feature of the stream itself? Isn't the point of IObservable to be the dual of IEnumerable, so calling Select on IEnumerable is a projection from A -> B, calling Select on IObservable is also a projection from A -> B, I think having an additional effect breaks that duality. So an Observable that has a side-channel or out-of-band stream wouldn't be an Observable, it'd be another category (which is why I suggested Pipes).

I totally understand why you'd want something like that, I'm just not sure it's fair to suggest Rx has design mistakes because of this though.

[haberman]

> Well, he kind of does.

If he has that much background I would expect him to know better than to give such a poor example when he's trying to make fun of a definition as "dilbert-esque."

Tongue-in-cheek is a fun style and I totally get that, but if you're taking unfair hyperbolic pot-shots I think it should be at your own expense, not other people's. But that's just me.