Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introduction to Reactive Programming

gist.github.com

Post reply on HN
Print view View original

31–34 of 34 posts

Re: Introduction to Reactive Programming

#31

Post by 21echoes »

amelius wrote: post #10

The problem I always run into with reactive programming is that of glitches, and stuff being recomputed more often than necessary. Glitches can appear when, for example, two inputs of a certain "functional box" change almost at the same time. When input 1 changes, the output changes, and then when input 2 changes, the output changes again, thus resulting in lots of superfluous computation in the chain that follows th…

1) Is "the chain that follows this output" pulling the data, or is the data being pushed to it? If you used a pull model rather than a push model, then inputs 1 and 2 could change a million times but no computation would be executed until the "chain that follows this output" requested the latest value.

2) If you need a push model, couldn't you just use .throttle / .debounce? I feel like FRP has plenty of tools to tackle this problem.

If your worry about recomputation is about efficiency, then admittedly FRP is probably not your best choice of paradigm. FRP consistently chooses reduced code complexity at the expense of efficiency (with the assertion that mutable state / imperative code is inherently more complex in a complex system than .flatMap.throttle.etc, which is obviously debatable).

Re: Introduction to Reactive Programming

#32

Post by seanmcdirmid »

tel wrote: post #30
seanmcdirmid wrote: post #28

Earlier quoted context omitted.

Just to note, many definitions of "reactive" are not based on recomputation (just react to those events dammit, whatever that means), while even those that are based on recomputation, there are many other issues to consider vs. incremental performance, like state preservation in a stepped recomputation, or implicit state that arises from aggregating over an event stream (FRP). Note that FRP is incremental in the time…

To be clear, I'm trying to state that a (nice) recomputation semantics is desirable because it means it's possible to reason about your program ignorant of time. Obviously, an implementation is preferable if it can speed things up via incremental computation and that ought to be nice as well AFRP is a good example here. AFRP semantics are easily stated in a recomputational way. It makes it necessary to talk about cau…

Do you have an citations about AFRP implementations being incremental. I haven't been able to find much in my own literature survey.

Re: Introduction to Reactive Programming

#33

Post by tel »

seanmcdirmid wrote: post #32
tel wrote: post #30

Earlier quoted context omitted.

To be clear, I'm trying to state that a (nice) recomputation semantics is desirable because it means it's possible to reason about your program ignorant of time. Obviously, an implementation is preferable if it can speed things up via incremental computation and that ought to be nice as well AFRP is a good example here. AFRP semantics are easily stated in a recomputational way. It makes it necessary to talk about cau…

Do you have an citations about AFRP implementations being incremental. I haven't been able to find much in my own literature survey.

Perhaps I'm not understanding the terminology, but every implementation I've ever seen consumes input incrementally. E.g.

    data (i ~> o) =           A (i -> (o, i ~> o))
    data (i ~> o) = forall s. A (i -> s -> (o, s))
in each case, the inputs are consumed sequentially, the outputs returned immediately, and the local state updated for the next time around.

If you're referring to the ability for a new event to update the signal network only partially (in Elliott's terminology, "push" semantics) then there's Amsden's TimeFlies library.

Re: Introduction to Reactive Programming

#34

Post by candeira »

platz wrote: post #4

> "FRP is programming with asynchronous data streams." Maybe, if you drop the F. For clarification on FRP there was a great talk at strangeloop this year: http://www.youtube.com/watch?v=Agu6jipKfYw

Thanks so much. This is one of the best talks I've seen in a long time.
Post reply on HN