I found this to be a great introductory course to the topic (Eric Meijer is one of the instructors):
Introduction to Reactive Programming
11–20 of 34 posts
Re: Introduction to Reactive Programming
#12This appears to be perhaps describing "reactive programming" as that term is used in practice, but FRP is actually something significantly more constrained. The term was, to my understanding, invented by Conal Elliott shortly after his work with Fran. To his mind, FRP is defined as describing synchronous, continuous signals in a language with denotational semantics that clearly suggest those signals. "Events" are inc…
I think part of the problem is that if we restrict the usage of the term FRP to only include Elliott's work, then there is a void currently as to how to characterize all these derivative forms, and not many are offering an alternative classification.
This is why I appreciated Evan's talk in attaching labels to different portions of the space.
Re: Introduction to Reactive Programming
#13This appears to be perhaps describing "reactive programming" as that term is used in practice, but FRP is actually something significantly more constrained. The term was, to my understanding, invented by Conal Elliott shortly after his work with Fran. To his mind, FRP is defined as describing synchronous, continuous signals in a language with denotational semantics that clearly suggest those signals. "Events" are inc…
[deleted]
Re: Introduction to Reactive Programming
#14and 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?)
(define (sfilter f xs)
(cond ((snull? xs) '())
((f (scar xs)) (scons (scar xs)
(sfilter f (scdr xs))))
(else (sfilter f (scdr xs)))))
(define (smap f xs)
(if (snull? xs)
'()
(scons (f (scar xs))
(smap f (scdr xs)))))
Re: Introduction to Reactive Programming
#15The 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…
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 optimal.
Re: Introduction to Reactive Programming
#16> "Reactive Manifesto sounds like the kind of thing you show to your project manager or the businessmen at your company." > "FRP is programming with asynchronous data streams." So, is Akka reactive or not?
It's not functional reactive in the Elliott sense. It is reactive in the general meaning of reactivity, but that is also a spectrum (actors don't work well for UI, for example).
Re: Introduction to Reactive Programming
#17The 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…
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!
Re: Introduction to Reactive Programming
#18and 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".
Re: Introduction to Reactive Programming
#19This appears to be perhaps describing "reactive programming" as that term is used in practice, but FRP is actually something significantly more constrained. The term was, to my understanding, invented by Conal Elliott shortly after his work with Fran. To his mind, FRP is defined as describing synchronous, continuous signals in a language with denotational semantics that clearly suggest those signals. "Events" are inc…
I think part of the problem is that if we restrict the usage of the term FRP to only include Elliott's work, then there is a void currently as to how to characterize all these derivative forms, and not many are offering an alternative classification. This is why I appreciated Evan's talk in attaching labels to different portions of the space.
I agree and would like to see a proliferation of more well-designed technical terms. I think the rest of the space sort of lacks enough clustering/commonality/analysis to pick too many terms yet—the places which are well-defined already have names like RtFRP and AFRP.
Re: Introduction to Reactive Programming
#20Earlier 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!
Well then, functional reactive programming is not incremental, especially implementations based on pull (ie polling). Event stream based systems (like Rx) provides incrementally growing event streams, but that's it. I'm not even sure if they suppress event firing on value streams when a value matching the last comes in.
I mean, it seems like reactive computations should be incremental, ya, but you won't find many (any?) models that deliver on that. On the other hand, you have plenty of incremental models that aren't reactive (eg SAC). Glitch is designed to be reactive and incremental, so it does "replay when something changes" and is able to suppress change propagation if/when a change fizzles out.