7 ms·

What is reactive programming?

67 points by outdooricon 12y ago

davexunit 12y ago
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-scheme-with-guile-2d.html http://dthompson.us/functional-reactive-programming-in-schem...
- Vaskivo 12y ago
  Thanks. I've been reading about FRP, and I think games or GUI centric applications are a great use-case for it.
ef4 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      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 12y ago
        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 12y ago
        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.
        12y ago
ggurgone 12y ago
Netflix uses reactive programming massively https://www.youtube.com/watch?v=XRYN2xt11Ek https://www.youtube.com/watch?v=XRYN2xt11Ek
- charlespwd 12y ago
  Interesting talk. Thanks for sharing!
tel 12y ago
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 12y ago
  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 12y ago
    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).
    - taeric 12y ago
      What, then, is the problem with denotational semantics?
      - AnimalMuppet 12y ago
        In order to understand how it's actually going to play out on a real machine in real time, you have to be able to simulate the execution (and perhaps the compiler), either experimentally or in your head.
        12y ago
factorialboy 12y ago
Reactive = Responding to (often asynchronous) events
- chriswarbo 12y ago
  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
kazinator 12y ago
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.
- throwaway283719 12y ago
  Sounds excellent.
  - meowface 12y ago
    Clever.
- seanmcdirmid 12y ago
  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.
- pjc50 12y ago
  The spreadsheet, the one "graphical programming language" to make it into widespread use by nonexperts.
  - VLM 12y ago
    And in practice "use relative or absolute addressing" is resolved via random number generation. Any later problems resulting from confusing the two can just be fixed by filing tickets with IT. Also used as the corporate standard database management system and as what boils down to a mail merge client, and although this appears to outsiders as bad standup comedy, it is unfortunately merely factual. Possibly one of the quickest ways to measure the dilbertian level of rot of an organization is to propose a small database and ask what tool they'd use to hold that information. Mysql, OK. Postgresql, eh, OK. Oracle, ummm. Excel, find the exit door and start running. Microsoft Word, Cthulhu take us to end the agony. I've seen all of the above. And survived. Barely. Perhaps not with my sanity intact. edited: spreadsheets fit into the design pattern of jokes where you got a problem to fix, so you try to implement a spreadsheet to fix it, now you got two problems to fix. This is probably funnier in its original regex and perl and web framework variants.
RyanMcGreal 12y ago
Wait, we're still using semicolon line terminators in 2051? Sigh.
- willismichael 12y ago
  ...and mutable values by default.
  - VLM 12y ago
    ... 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)
- kybernetikos 12y ago
  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.
michaelsbradley 12y ago
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-dissertation.pdf http://www.cs.cornell.edu/~jnfoster/papers/jnfoster-disserta... [2] http://www.cis.upenn.edu/~bcpierce/papers/lenses-etapsslides.pdf http://www.cis.upenn.edu/~bcpierce/papers/lenses-etapsslides... [3] http://www.wisdom.weizmann.ac.il/~harel/reactive_systems.html http://www.wisdom.weizmann.ac.il/~harel/reactive_systems.htm...
cpr 12y ago
https://gist.github.com/staltz/868e7e9bc2a7b8c1f754 https://gist.github.com/staltz/868e7e9bc2a7b8c1f754 is an excellent introduction to reactive programming.

67 points by outdooricon 12y ago

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-scheme-with-guile-2d.html http://dthompson.us/functional-reactive-programming-in-schem...

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

ef4 12y ago

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 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      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 12y ago
        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.
        12y ago

ggurgone 12y ago

Netflix uses reactive programming massively https://www.youtube.com/watch?v=XRYN2xt11Ek https://www.youtube.com/watch?v=XRYN2xt11Ek

charlespwd 12y ago
Interesting talk. Thanks for sharing!

tel 12y ago

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 12y ago
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 12y ago
  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).
  - taeric 12y ago
    What, then, is the problem with denotational semantics?
    - AnimalMuppet 12y ago
      In order to understand how it's actually going to play out on a real machine in real time, you have to be able to simulate the execution (and perhaps the compiler), either experimentally or in your head.
      - 12y ago

factorialboy 12y ago

Reactive = Responding to (often asynchronous) events

chriswarbo 12y ago
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

kazinator 12y ago

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.

throwaway283719 12y ago
Sounds excellent.
- meowface 12y ago
  Clever.
seanmcdirmid 12y ago
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.
pjc50 12y ago
The spreadsheet, the one "graphical programming language" to make it into widespread use by nonexperts.
- VLM 12y ago
  And in practice "use relative or absolute addressing" is resolved via random number generation. Any later problems resulting from confusing the two can just be fixed by filing tickets with IT. Also used as the corporate standard database management system and as what boils down to a mail merge client, and although this appears to outsiders as bad standup comedy, it is unfortunately merely factual. Possibly one of the quickest ways to measure the dilbertian level of rot of an organization is to propose a small database and ask what tool they'd use to hold that information. Mysql, OK. Postgresql, eh, OK. Oracle, ummm. Excel, find the exit door and start running. Microsoft Word, Cthulhu take us to end the agony. I've seen all of the above. And survived. Barely. Perhaps not with my sanity intact. edited: spreadsheets fit into the design pattern of jokes where you got a problem to fix, so you try to implement a spreadsheet to fix it, now you got two problems to fix. This is probably funnier in its original regex and perl and web framework variants.

RyanMcGreal 12y ago

Wait, we're still using semicolon line terminators in 2051? Sigh.

willismichael 12y ago
...and mutable values by default.
- VLM 12y ago
  ... 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)
kybernetikos 12y ago
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.

michaelsbradley 12y ago

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-dissertation.pdf http://www.cs.cornell.edu/~jnfoster/papers/jnfoster-disserta... [2] http://www.cis.upenn.edu/~bcpierce/papers/lenses-etapsslides.pdf http://www.cis.upenn.edu/~bcpierce/papers/lenses-etapsslides... [3] http://www.wisdom.weizmann.ac.il/~harel/reactive_systems.html http://www.wisdom.weizmann.ac.il/~harel/reactive_systems.htm...

cpr 12y ago

https://gist.github.com/staltz/868e7e9bc2a7b8c1f754 https://gist.github.com/staltz/868e7e9bc2a7b8c1f754 is an excellent introduction to reactive programming.