"Controlling Time and Space: understanding the many formulations of FRP" by Evan Czaplicki

Functional Reactive Programming (FRP) is becoming an increasingly common way to structure event- driven code, but the term "FRP" actually refers to a large body of increasingly diverse work. This talk will quickly cover the basics of FRP, and then go into a couple different formulations of FRP that people are beginning to use. We will explore how these formulations fit together historically and theoretically.
Finally, we will see how the particular variation of FRP used in Elm makes it easy to implement hot- swapping and Elm's Time Traveling Debugger.
by Evan Czaplicki (@czaplic) - Prezi
I am a functional programmer at heart, and my broad goal is to provide the tools and learning resources to make functional languages common in industry. I develop Elm 's compiler, tools, and community to make it great for projects within Prezi and in industry in general.

[@CarlosSaltos]

Thank you for sharing !! ... After all this years is still very important to know about these different choices

[@statebased]

A nice talk. The last question from the audience is most tricky: how to model and implement prioritization. You can try to argue you do not need to implement prioritization as a separate concept. In fact, if you have enough hardware, you parallelize the streams of computation of different priorities, to then bring these signals back to together following the prioritization scheme. The problem is that the different paths of computation take different amount of times and waiting to synchronize these parallel streams is most often not acceptable. This makes it all complicated… Also missing from this talk is the notion of the higher order of sequentiality, and related to that the notion of hierarchical streams holding a dual relation to hierarchical state machines.

[@HenkPoley]

I think work on fq_codel & CAKE network packet schedulers, or Linux process scheduler, showed that you may also just segment things by origin and de-prioritize 'elephant streams', and prioritize origins that relatively rarely send data. By giving some kind of push-back signal that things are not delivered/processed as quickly as it was sent, the sender can react by changing it's usage patterns / expectations. This does not require any explicit priority levels, except maybe a flag that shows that the request can be dropped under load. This is paradoxically different from the (supposedly) optimal strategy in real-time systems, where you prioritize larger workloads, but they promise to finish on time.

[@ChristopherOkhravi]

Damn interesting. Thank you very much for making this!

[@danielbarlow6220]

There is a transcript of this talk at github.com/strangeloop/StrangeLoop2014/blob/master/transcripts/Czaplicki-ControllingTimeAndSpaceFRP.txt (not my work, I'm just drawing attention to it)

[@SplogMan]

Good stuff. He is using the *hell* out of Prezi, lol. Great work and great presentation. Can't wait to start playing with *Elm*.

[@SchellScivally]

Great talk!

[@JeremyGluckStuff]

When he hot-swapped code and the debugger recalculated past values I was like "holy shit!"

[@LePomologue]

This was very interesting, thank you

[@nXqd]

very nice talk. Thanks

[@NiklasThorne]

Nice talk. Thank you!

[@mariusraducan1348]

My question is, can we use second order arrows to look at the wold, an arrow that can implement ArrowAply for exemple, we know these arrows are equivalent to monads, the way haskell looks at the world. Can arrows in FRP be used for more then structuring the cod?

[@Will-tb8qm]

Values changing over time, and how Signals abstract that, REALLY reminds me of calculus, specifically integration. A signal is the values integrated w.r.t. time. Will that help or hinder my understanding of FRP?

[@HenkPoley]

I think a problem with comparing it to mathematical integration/differentiation is that in there some information is removed or added (for example the '+C'), which might be hard to map to software programming. But it's certainly a term that floats around in the 'harder' computer science areas. It would be good to think about what it would imply.

[@ctrpapa]

So all Elm programs with Signals start and then run out of memory without doing anything? I start the mario debug example and wait 20 minutes then jump and wait 2 days then jump again. All the time doing nothing must be recorded somehow whether the Signal value is changing or not (in order to rewind through the state). I'm having trouble finding any articles explaining why this isn't an issue. Any inks would be appreciated.

[@ctrpapa]

+Evan Czaplicki -- is it that Elm is so efficient it can store hundreds of years of complex state before making even an iPhone run out of memory?

[@c0ntag10n]

+Dave Alger The last question I think answers yours: 39:58

[@ctrpapa]

c0ntag10n thanks - I figured Signals only store delta changes / timestamp so if there is no user input for an hour the memory footprint basically stays constant.

[@Insipidont]

I would assume that the debugger is doing the recording. The app without the debugger does not keep a record of the state history (unless of course you implement it as a feature, in a similar way as the debugger app does).

[@mechadense]

27:00 The point is made that the haskell library "netwire" is an arrowized FRP library that is not meant to take signals from the outside world (e.g. no mouse position). Does that mean it is not meant for graphic interactive applications like the one presented here: kzbin.info/www/bejne/gIWZZ6mlrpt1qtU