Reactive Programming in FOAM

Video: https://www.youtube.com/watch?v=-fbq-_H6Lf4

Slides: http://foam-framework.github.io/foam/foam/index.html?model=foam.demos.empire.Preso3#position=16

In 2007 I saw a presentation on a "functional reactive programming" system called flapjax. When it came time to design FOAM, I borrowed the concept.

Here's an interesting quote from the Flapjax docs, which is interesting and just as applicable to FOAM: Source: http://www.flapjax-lang.org/tutorial/

The Spreadsheet Grew Up

Spreadsheets are a good idea. Not in the sense that it's fun to spend all day crunching numbers arranged in rows and columns; rather, in the sense that they let you express dependencies between cells, then automatically perform the ``heavy lifting'' of propagating these dependencies. They are, in some respect, the ultimate kind of declarative programming language, but without any associated religious cult.

Behaviors are essentially the natural extension of the spreadsheet model, generalized in two respects:

You can program over arbitrary data, not just numbers and a few other impoverished datatypes. You don't have to write everything in a grid and use an unscaleable naming convention. Instead, expression A depends on the value of expression B if B is a sub-expression of A (which includes B being an argument to a method and A being the method invocation, or even B being an expression in a method that A invokes). If you do need to name an expression, you can employ the naming power of JavaScript, which includes not only variable names but also array indices, objects fields, and so forth. Just pick the one that works best for your needs. That said, behaviors are still in the spreadsheet mould of expressing dependencies and letting the language sort out the propagation of values. Like most spreadsheets, Flapjax has optimizations to avoid wasteful computation; unlike most spreadsheets, Flapjax has mechanisms to handle quite sophisticated dependencies including mutual references (which often arise in programming visual user interfaces). One way of view Flapjax, then, is that it tries to reconcile two important programming styles that have needlessly been in conflict: declarative and imperative programming. Imperative programs often put too much book-keeping burden on the programmer; where the programmer fails, the program generates errors owing to inconsistencies. In contrast, traditional declarative programming forces programmers into a straightjacket that sometimes even ignores the presence of imperative effects in real-world data and systems. In contrast to both of these, Flapjax fully embraces mutation—behaviors are entirely built around the existence of mutation—but encourages programmers to describe their systems declaratively, pushing the burden of propagating these changes through the declarative specification onto the language. In short, Flapjax programs tend to be declarative specifications over imperative data.