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

21–30 of 34 posts

Re: Introduction to Reactive Programming

#21

Post by tel »

amelius wrote: post #17
seanmcdirmid wrote: post #15

Earlier quoted context omitted.

You might want to check out Glitch, a programming model that attacks those problems head on with replay and rollback: http://research.microsoft.com/en-us/people/smcdirm/managedti... There is nothing in reactive programming that implies being incremental, but glitch does that anyways (in the sense that tasks whose dependencies haven't changed aren't replayed). On the other hand, glitch might replay tasks more than is…

> There is nothing in reactive programming that implies being incremental Yes there is. Because if it's not incremental, then you could replace any "reactive" program by one which just recomputes its outputs every time something changes, from scratch. Reactive programming solves this by only recomputing parts which change. PS: Thanks for the link, I'll look into it!

> then you could replace any "reactive" program by one which just recomputes its outputs every time something changes, from scratch. Reactive programming solves this by only recomputing parts which change.

I find that to be completely desirable. That behavior is exactly what I want... simply done more efficiently [0].

[0] Also modulo a whole bunch of local state. AFRP handles this well by having a good notion of what it means to "switch an arrow in" but it's been a challenge for applicative/monadic FRP. Rx programming (e.g. "not FRP") tends to solve this problem by ignoring its existence and just littering local state everywhere.

Re: Introduction to Reactive Programming

#22

Post by zerr »

dschiptsov wrote: post #14

and streams are.. (define-syntax scons (syntax-rules () ((_ x expr) (cons x (delay expr))))) (define scar car) (define (scdr xs) (force (cdr xs))) (define snull? null?) and filter for streams is, OMG.. (define (sfilter f xs) (cond ((snull? xs) '()) ((f (scar xs)) (scons (scar xs) (sfilter f (scdr xs)))) (else (sfilter f (scdr xs))))) and of course.. (define (smap f xs) (if (snull? xs) '() (scons (f (scar xs)) (smap f…

To follow that line, all of the users of electronic spreadsheets were/are doing RP :) (not completely a joke actually)

Re: Introduction to Reactive Programming

#23

Post by dschiptsov »

reikonomusha wrote: post #18
dschiptsov wrote: post #14

and streams are.. (define-syntax scons (syntax-rules () ((_ x expr) (cons x (delay expr))))) (define scar car) (define (scdr xs) (force (cdr xs))) (define snull? null?) and filter for streams is, OMG.. (define (sfilter f xs) (cond ((snull? xs) '()) ((f (scar xs)) (scons (scar xs) (sfilter f (scdr xs)))) (else (sfilter f (scdr xs))))) and of course.. (define (smap f xs) (if (snull? xs) '() (scons (f (scar xs)) (smap f…

That has no notion of time or distance between "events".

So they have "ticks" in a stream? OK, one more cond clause.)

Re: Introduction to Reactive Programming

#24

Post by chipsy »

platz wrote: post #9
ericHosick wrote: post #8

How similar is this to Flow Based Programming by Paul Morrison?

If fbp is a form of dataflow programming, I think you could say it is reactive.. I would try to separate data flow from the FRP style that reifies the time step into first-class values .e.g. w/ "signals" or "behaviors", or from the "arrowized" forms of FRP

I've studied "fbp" in more depth than "frp" but my conclusions were that they do achieve very similar things with vastly different semantics and terminology.

One of the interesting aspects of FBP and many dataflow systems is that it can also be defined as a schema for actor-model messaging. i.e. you still have the general actor model as the low level abstraction, but then you assume actors to be archetypal and immutable between runs of the network, existing only to implement a finite, typed, addressable number of "in" and "out" queues on each actor instance, which are subsequently configured into the final network. An explicit model of time is not used - "all messages delivered" is the standard termination state, but if one breaks the Morrison model to add local actor state again, it becomes trivial to defer message delivery across runs of the network.

Re: Introduction to Reactive Programming

#25

Post by platz »

chipsy wrote: post #24
platz wrote: post #9

Earlier quoted context omitted.

If fbp is a form of dataflow programming, I think you could say it is reactive.. I would try to separate data flow from the FRP style that reifies the time step into first-class values .e.g. w/ "signals" or "behaviors", or from the "arrowized" forms of FRP

I've studied "fbp" in more depth than "frp" but my conclusions were that they do achieve very similar things with vastly different semantics and terminology. One of the interesting aspects of FBP and many dataflow systems is that it can also be defined as a schema for actor-model messaging. i.e. you still have the general actor model as the low level abstraction, but then you assume actors to be archetypal and immuta…

Nice - I've been waiting to find a spot to jump into dataflow style and the combination with actors you describe is interesting

Re: Introduction to Reactive Programming

#27

Post by wyager »

zerr wrote: post #22
dschiptsov wrote: post #14

and streams are.. (define-syntax scons (syntax-rules () ((_ x expr) (cons x (delay expr))))) (define scar car) (define (scdr xs) (force (cdr xs))) (define snull? null?) and filter for streams is, OMG.. (define (sfilter f xs) (cond ((snull? xs) '()) ((f (scar xs)) (scons (scar xs) (sfilter f (scdr xs)))) (else (sfilter f (scdr xs))))) and of course.. (define (smap f xs) (if (snull? xs) '() (scons (f (scar xs)) (smap f…

To follow that line, all of the users of electronic spreadsheets were/are doing RP :) (not completely a joke actually)

> all of the users of electronic spreadsheets were/are doing RP

I think you are absolutely right. One of the popular examples of where RP is useful is in implementing a spreadsheet program.

Re: Introduction to Reactive Programming

#28

Post by seanmcdirmid »

tel wrote: post #21
amelius wrote: post #17

Earlier quoted context omitted.

> There is nothing in reactive programming that implies being incremental Yes there is. Because if it's not incremental, then you could replace any "reactive" program by one which just recomputes its outputs every time something changes, from scratch. Reactive programming solves this by only recomputing parts which change. PS: Thanks for the link, I'll look into it!

> then you could replace any "reactive" program by one which just recomputes its outputs every time something changes, from scratch. Reactive programming solves this by only recomputing parts which change. I find that to be completely desirable. That behavior is exactly what I want... simply done more efficiently [0]. [0] Also modulo a whole bunch of local state. AFRP handles this well by having a good notion of what…

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 dimension (add a new time point to the program, you don't have to recompute the program for previous time points), but we really want more than that (don't recompute parts of the program execution that are not affected by changes in the time point).

It isn't clear to me that arrowized FRP is incremental. I think some of the less pure FRPs are (like Flapjax) given that they do a topological sort of the signal graph to repair it (if they were going to redo everything, the sort wouldn't be necessary).

Re: Introduction to Reactive Programming

#29

Post by dmitrig01 »

Very interesting. One thing I notice about this architecture is that in the example given, the fourish features (loading suggestions, displaying suggestions, reloading all, reloading one) are pretty tightly complected together (especially further on, for example in the combineLatest area). Is this necessarily the case? Is there some better way of accomplishing this?

Re: Introduction to Reactive Programming

#30

Post by tel »

seanmcdirmid wrote: post #28
tel wrote: post #21

Earlier quoted context omitted.

> then you could replace any "reactive" program by one which just recomputes its outputs every time something changes, from scratch. Reactive programming solves this by only recomputing parts which change. I find that to be completely desirable. That behavior is exactly what I want... simply done more efficiently [0]. [0] Also modulo a whole bunch of local state. AFRP handles this well by having a good notion of what…

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 causal AFRP and bounded history AFRP which are nice terms to think about a computation (if sort of obvious). Then, the efficient implementations (of causal AFRP) themselves are incremental for efficiency.

Post reply on HN