https://medium.com/@andrestaltz/why-i-cannot-say-frp-but-i-just-did-d5ffaa23973b https://stackoverflow.com/questions/5875929/specification-for-a-functional-reactive-programming-language/5878525 https://stackoverflow.com/questions/5385377/the-difference-between-reactive-and-functional-reactive-programming/5386908#5386908 http://conal.net/blog/posts/early-inspirations-and-new-directions-in-functional-reactive-programming https://stackoverflow.com/questions/1028250/what-is-functional-reactive-programming/1030631#1030631 https://github.com/conal/talk-2014-bayhac-denotational-design#why-continuous-time-matters https://github.com/conal/talk-2015-essence-and-origins-of-frp
On a fateful day in late 2014, I read The Future of DOM MV* by David Nolan. It mentioned a new JavaScript library out of Facebook that everybody was making fun of. I read on. My mind was blown. ReactJS was a revalation!
Ever since then, I've been enamored with FRP. Yet in many places on the internet and with a few in person friends, I've was told that the FRP of React, the FRP I know, is not true FRP. It's somehow less-than. There's this work from the 90s that is the real FRP.
I didn't like to hear this. I loved the FRP I knew. If "real FRP" is different, maybe I don't need it.
But I was constantly re-assured that it was worthwhile, so I gave it a go and started reading Conal. It made no sense to me. I read and re read and re read his papers (over the course of a year) but they didn't click. I all but gave up when one day it all fell into place in my head and I saw the light.
Here the tragedy: now I too am one of those assholes that goes around telling people their React-based notions of FRP aren't "real." I've been bitten by the FRP zombies and I must spread my disease.
However, I don't want to others to have to struggle as much as I did, so this is a tutorial for "real FRP" which I will henceforce refer to as DCTP (Denotative Continuous Time Programming).
Let's start with an analogy. What's the difference between bitmap graphics and SVG? If you zoom in a bitmap graphic, it will get all pixelated, but it will zoom smoothly in an SVG. If you make a circle in a bitmap, it immediately becomes pixels and then zooming breaks. If you add a circle in an SVG, the computer always remembers it's a circle and thus will be able to show it at whatever resolution you want. SVG is resolution-independent.
Here's another way to put it: SVG graphics retains all the relevant info until the last moment when the computer finally has to put the picture on the screen; then it turns your circle into a bunch of pixels.
Let's describe this mathmatically: bitmap graphics relate a point in 2-d space to a color value. But what kind of 2-d space? The x-axis and y-axis are integers in bitmap graphics. This means that you can count the pixels one by one. There are no pixels in between two ajacent pixels. This is why we have trouble zooming in - we must create more pixels than we had before so we just duplicate them blidnly and that's why it lokos pixelated.
The mathmatical descriptipn of SVG is similiar, but instead of a mapping from a pair of integers to a color, it maps from a pair of real numbers to a color. This means that between any two points in an SVG there are an INFINITY of points. It wouldn't even make sense to discuss adjacent points because you could always find more points in between any two points. This is why they scale so well. SVG graphics know the values of inifinitely many points so it's very flexible.
This might feel like a shocking claim. How can we store an infinity of points?! It's easy: just use math.
Here's a very simple SVG description that describes an infinitiy of points. For all points, the color is black. Boom infinity tackled.
Here's another: a circle with radius 1, centered at (0,0), with a border width of 1, and a border-color of green. Boom. That describes an ininity of points along that circle
So how does this analogy apply to DCTP / FRP? We improved images by going from discrete integers to smooth real numbers. We smoothed out 2D space. How about we improve our reactive systems (systems that evolve over time) by smoothing out time?
Boom. Is your mind blown yet?
There are two ways time shows up in programming and both are discrete: 1) time is represented as one line after the other or 2) time is a explicit variable of integers.
The limitations of this are similar to the limitations of SVG: what if we wanted to speed up time or slow it down or reverse it? TODO add more reasons why you'd want to do this
The real reason to use continuous time is for compositionality, WHen you go to approximations too early you have to propogate them. Stay in ideal land as long as possible and only at the end will the computer "rasterize" to discreteness for you.
move is x = t
circle is x= cos t, y=sin t
- DAG
- mutation
- discrete time