The Misunderstood Roots of FRP

First, a couple of old talks on the topic -

- "Functional thinking" - Brings together some of the thinking I've applied in a few areas - http://sriku.org/blog/2015/08/11/talk-functional-thinking-fo... .

- "Beta abstraction for bottom-up theory building" - Shows how beta abstraction can be applied to systematically become denotational - http://sriku.org/blog/2016/02/06/beta-abstraction-for-bottom...

Systems -

- In "muvee Reveal", an automatic video production system, the styles are written in a Scheme-dialect called "muSE"[1] in which stuff needed to represent stylistic elements are built. The editing styles DSL [2] and documentation show how this stuff can be represented well removed from implementation details. (Disclaimer: I used to work for muvee, but no longer do so stuff may have changed.)

In particular, video and animations were not modeled as functions of time to Image, but functions of a time interval [t,t+dt] to Image. The reasoning was that the interval information is critical to render motion blur. You could argue that the "dt" is a detail that can be passed on later at render time, but it didn't take away much from the API's simplicity.

- Steller[3] - a library for declaratively composing dynamic temporal structures, useful (and used) for music and synchronized animations.

- elm-anima[4] - a concept demo of structuring animations in Elm. This was pre-18 and so doesn't use subscriptions. Here, animations are conceived of as processes rather than functions over time. I've described the thinking in a post [5]. Elm fell out of favour for me as there were many APIs I needed to work with that I couldn't use it with and the portion that needed Elm was small in the systems I was working with.

[1]: https://github.com/srikumarks/muSE

[2]: https://srikumarks.github.io/muvee-style-authoring/

[3]: https://github.com/srikumarks/steller

[4]: https://github.com/srikumarks/elm-anima

[5]: http://sriku.org/blog/2015/12/13/towards-reactive-animation-...

They weren’t beautiful, but both methods worked fine for the rare cases they proved necessary.

"It's awkward as hell to use and takes way to many brain-cells to achieve simple results."

> Even I find the above [react.js FRP] code hard to read, despite having written it! While this could be seen as a downside of the denotative approach, I see it as a mismatch between the denotative approach and textual syntax. There’s been interesting work visualizing streams, which I hope to build on. Currently, I’m in the mockup phase, but I hope to build a developer tool experience that will automatically generate a live visualization.

My understanding is that right now it certainly does require too much brain to do anything in FRP, but that isn't a downfall of FRP as a concept ("FRP kinda sucks") but rather that making FRP convenient is still today an open research question.

"That if you have some real world problem that involves state, that you want to model that using virtual state and not the high-order time-varying continuous functions that FRP uses."

> Denotative languages better convey the global structure of a program. We can fully understand an expression by its subexpressions, and their subexpressions, recursively. There are no spooky action-at-a-distance side-effects that can manipulate things from afar. We don’t have to read the entire codebase to ensure we understand a single piece; we must merely read its subexpressions, recursively. This allows us to quickly rule out what we do and do not need to read, saving us a lot of time in large codebases.

I don't disagree that using concrete, non-abstracted state is a simpler way to model state-related problems, but this isn't about modeling and solving state-related problems, it's about solving them in a way that's maintainable. It's easy to argue for simplicity now (i.e. when first approaching a problem) and we have many, many tools for using state for that, like ipython notebooks, or pen and paper. But let's point out that simplicity of these initial concrete-state-minded approaches tend to grow into entangled messes, messes that are arguably solved by encapsulation and patterns. Regardless of whether they do solve the problem, having to understand things like inheritance and all their related problems kind of defeats the purpose of using state to make the problem simpler to understand in the long run. Which is what FRP purports to solve. Except we don't have the pen and paper for FRP yet.

"The great irony is that nobody on the planet thinks of spreadsheets as time-varying continuous functions."

True. No one thinks that. The author doesn't think that. Probably not even the folks who made the neat stats-oriented spreadsheet[0] thinks that, and that's data as continuously varying as you can get.

All of this kind of props up the title which is that FRP is grossly misunderstood.

[0] https://news.ycombinator.com/item?id=18785371