
What is reactive programming? - outdooricon
http://paulstovell.com/blog/reactive-programming
======
tel
The linked Stack Overflow answer by Conal Elliott does a much better job
explaining FRP. It has less to do with "linking" as via this destiny operator
and more to do with manipulating values of "entire histories and futures" all
at once. In other words, the heart of FRP is not in the operators, but the
nouns. And not in an OO sense tied to ambient mutation, but instead as
concrete, immutable values.

~~~
throwaway283719
I knew it was by Conal before I got to the end, as soon as I saw the phrase
"denotational semantics" ;)

I should really learn what that means one day...

~~~
chriswarbo
Denotational semantics: code is a meaningful artefact.

This fits well with the functional paradigm, where values are immutable and
therefore 'timeless'.

In contrast, imperative code, if it has any actual semantics at all, tends to
be operational:

Operational semantics: the "meaning" of code is how it affects the behaviour
of the machine that's interpreting it.

The problem with operational semantics is exactly that of imperative code: in
order to understand what some code will do, you need to know everything which
'happened before' (ie. the current state of the machine).

~~~
ollysb
>> The problem with operational semantics is exactly that of imperative code:
in order to understand what some code will do, you need to know everything
which 'happened before' (ie. the current state of the machine).

Wouldn't knowledge of everything within the current scope be sufficient?

~~~
ef4
No, because every function you call could be depending on hidden state that's
not in your scope.

------
kazinator
This gives me an great idea. What if we put these variables into a grid
displayed on the screen? Then you will be able to enter some values into some
of the cells, and the dependent ones update themselves automatically. The
elements of the grid could be regarded as array elements indexed by
coordinate, and use relative or absolute addressing to refer to each other's
coordinates, making it easy to replicate dependency rules across rows and
columns, to generate entire tables which update themselves.

~~~
kyllo
What a novel idea!

Seriously though, Angular gives you the ability to do this in the browser,
here's an example of how to implement an Excel-like spreadsheet using Angular:
[http://thomasstreet.com/blog/legacy/spreadsheet.html](http://thomasstreet.com/blog/legacy/spreadsheet.html)

~~~
sehr
It's not really unique to Angular is it?

~~~
kyllo
No, I think the other major client-side MVC frameworks (Backbone, Ember,
React) are also geared toward this reactive paradigm.

------
ggurgone
Netflix uses reactive programming massively
[https://www.youtube.com/watch?v=XRYN2xt11Ek](https://www.youtube.com/watch?v=XRYN2xt11Ek)

~~~
charlespwd
Interesting talk. Thanks for sharing!

------
davexunit
I've been slowly implementing my own functional reactive programming system
over for a game engine I'm writing. A few months ago, I wrote a short blog
post on the topic that includes a screencast to see how it all works. Maybe it
will help someone understand (F)RP a bit better.

[http://dthompson.us/functional-reactive-programming-in-
schem...](http://dthompson.us/functional-reactive-programming-in-scheme-with-
guile-2d.html)

~~~
Vaskivo
Thanks. I've been reading about FRP, and I think games or GUI centric
applications are a great use-case for it.

------
ef4
The "destiny" operator is just function definition. It might seem different if
you're only used to languages where function calls and variable accesses are
syntactically distinct.

~~~
throwaway283719
Not true. Consider the following snippet -

    
    
        a = 10
        b = function() { return expensive_computation(a) }
    

Now, even if you can call b without parens, it still has to redo the expensive
calculation every time you access it (because a _might_ have changed... even
if it hasn't).

The "destiny" operator is more like

    
    
        a = 10
        b = function() {
                persistent cached_value = null
                if is_null(cached_value) or has_changed(a) {
                    cached_value = expensive_computation(a)
                }
                return cached_value
            }
    

but instead of that, you get to write (in this totally fictional programming
language)

    
    
        a = 10
        b <- expensive_computation(a)
    

and have the compiler take care of the caching and updating for you.

~~~
Sharlin
Plus the real power of reactivity is that it is _push_ , not _pull_. The
changes are propagated without ever needing to poll for the new value manually
- for instance, you could display the value of b in a UI and have it change
whenever the value of a changes.

~~~
restalis
Isn't the _push_ strategy an expensive one? Maybe not all of the dependencies
are needed right away, why bother with dispatching a new value though all of
them? ...and more, considering that distinct dependency updates may require
different (and admittedly expensive) computations, won't _the push way_ be an
overkill?

~~~
taeric
I'm not sure pull is any better in this regard. Simply stated, naive push and
pull are both bad. You wind up putting a fair bit of heuristics on top of
either to make them good.

Pull has the major downside that you never know when you need to pull a new
value. Which is a pretty major downside.

And really, this does just feel like we baked some new semantics onto the
observer pattern.

~~~
Sharlin
It depends on your point of view. From one perspective, the observer pattern
is simply a way to implement reactive values in the OO paradigm - indeed, a
somewhat arrogant FP aficionado would describe many of the GoF design patterns
as clumsy OO emulations of things a functional language would be able to
express much more elegantly.

In the Rx-style reactive model the big thing is making the event _streams_ ,
in addition to the events, first-class objects, so they can be composed and
manipulated with the usual FP subjects like map/filter/reduce. This makes, for
instance, throttling to optimize the propagation of changes almost trivial
compared to the situation where you only have individual events without
context.

~~~
taeric
Yeah, I've read some of the papers. I was even heavily swayed for a time.
However, I'm not entirely sure that Streams are an automatic win in
abstraction. Often combining streams is just a very clumsy way of saying "add
this and that."

More specifically, I think things are a lot easier when you can work way above
those abstractions. As soon as you get into the weeds, all of the abstractions
suck.

I also think this is specifically why people like angular so much. For many
use cases, you are just setting values and having the UI present said values.
Note, setting values, not appending to streams.

Now, do I expect that angular's internals would benefit from the streams
metaphor? I certainly suspect so. Don't know, though.

------
michaelsbradley
I enjoyed the post, but I think the proposed scope of reactive programming is
a bit limited. What the author describes is, I think, more related to the
concerns of "bidirectional programming"[1] and lenses[2]. Granted, I think
those concerns do fit broadly under the umbrella of reactive programming.

Below is Prof. David Harel's (the inventor of statecharts, formalized as UML
State Machines) general characterization[3] of a reactive system; reactive
programming would then be any programming methodology, language or environment
which aims to service those characteristics.

* It continuously interacts with its environment, using inputs and outputs that are either continuous in time or discrete. The inputs and outputs are often asynchronous, meaning that they may arrive or change values unpredictably at any point in time.

* It must be able to respond to interrupts, that is, high-priority events, even when it is busy doing something else.

* Its operation and reaction to inputs often reflects stringent time requirements.

* It has many possible operational scenarios, depending on the current mode of operation and the current values of its data as well as its past behavior.

* It is very often based on interacting processes that operate in parallel.

[1] [http://www.cs.cornell.edu/~jnfoster/papers/jnfoster-
disserta...](http://www.cs.cornell.edu/~jnfoster/papers/jnfoster-
dissertation.pdf)

[2] [http://www.cis.upenn.edu/~bcpierce/papers/lenses-
etapsslides...](http://www.cis.upenn.edu/~bcpierce/papers/lenses-
etapsslides.pdf)

[3]
[http://www.wisdom.weizmann.ac.il/~harel/reactive_systems.htm...](http://www.wisdom.weizmann.ac.il/~harel/reactive_systems.html)

------
cpr
[https://gist.github.com/staltz/868e7e9bc2a7b8c1f754](https://gist.github.com/staltz/868e7e9bc2a7b8c1f754)
is an excellent introduction to reactive programming.

------
RyanMcGreal
Wait, we're still using semicolon line terminators in 2051?

Sigh.

~~~
willismichael
...and mutable values by default.

~~~
VLM
... and single character ASCII non-UTF-8 variable names.

... and no types. So if a and b are strings in a "mostly string-ish language"
then the value of b is "101" halfway thru and "111" at the end, right?

(I'd cut them a break if they used a single expressive and meaningful kanji
even ifs only one glyph, although I'm struggling to think of a kanji that
implies type and a compiler smart enough to understand the type embedded in
the kanji... although it could happen)

------
factorialboy
Reactive = Responding to (often asynchronous) events

~~~
chriswarbo
The words "responding" and "asynchronous" seem to imply a particular execution
model, in particular one which seems to contradict the original definition of
Function Reactive Programming

[http://conal.net/papers/icfp97/](http://conal.net/papers/icfp97/)

Perhaps a more neutral description would be:

Reactive = Values are parameterised by the current time

