What is 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.

[amouat]

To save others clicking through the article again, the SO question is here: http://stackoverflow.com/questions/1028250/what-is-functiona...

[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...

[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

[pjc50]

The spreadsheet, the one "graphical programming language" to make it into widespread use by nonexperts.

[throwaway283719]

Sounds excellent.

[taylodl]

That's what Lotus Improv did, twenty years ago. It was too radical for users at the time and so sales were pretty much nonexistent.

https://en.wikipedia.org/wiki/Lotus_Improv

[seanmcdirmid]

Scaling would be quite difficult. I'm sure you could hack maybe a Turing machine out of this paradigm, but it would be ugly and mostly an esoteric exercise.

[ggurgone]

Netflix uses reactive programming massively 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...

[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.

[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...

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

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

[cpr]

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.

[kybernetikos]

Pretty sure that's a mistake in the article. We're supposed to be in 2051 looking back at a sample of code written in 2021.

[willismichael]

...and mutable values by default.

[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/

Perhaps a more neutral description would be:

Reactive = Values are parameterised by the current time