5 ms·

On the topic of dataflow programming I found the book "Dataflow and Reactive Programming Systems: A Practical Guide to Developing Dataflow and Reactive Programm

by tbirdz 12y ago

On the topic of dataflow programming I found the book "Dataflow and Reactive Programming Systems: A Practical Guide to Developing Dataflow and Reactive Programming Systems" by Matt Carkci [0] to give a pretty good overview of the different types and implementations of dataflow programming systems. I think that flow-based programming sounds incredibly cool, but I haven't found any project where I could use it well... yet! [0] https://leanpub.com/dataflowbook https://leanpub.com/dataflowbook

amelius 12y ago
I think the biggest problems with flow based or reactive programming are the occurrence of glitches, and, more importantly, the problem of how to compute updates without performing unnecessary work. I wonder if these problems have been successfully addressed somewhere.
- seanmcdirmid 12y ago
  My work [1] addresses glitches head on (hence the system is called "Glitch") by tolerating glitches and at least making the extra work functionally benign (via logging and rollback, like a transaction). Glitch is not based on data flow, however, but somewhere in between even if still very reactive. I've built a few data flow systems in the past (my dissertation work [2] was based on one), but I decided to tolerate rather than avoid glitches early on because I found that way to be more resilient. Flapjax [3] avoids glitching via a topological sort, which I rather see as an optimization (to reduce unnecessary work) rather than as a correctness issue. [1] http://research.microsoft.com/apps/pubs/default.aspx?id=226574 http://research.microsoft.com/apps/pubs/default.aspx?id=2265... [2] http://research.microsoft.com/pubs/179366/mcdirmid06superglue.pdf http://research.microsoft.com/pubs/179366/mcdirmid06superglu... [3] http://cs.brown.edu/~sk/Publications/Papers/Published/mgbcgbk-flapjax/paper.pdf http://cs.brown.edu/~sk/Publications/Papers/Published/mgbcgb...
  - amelius 12y ago
    Interesting. Do you know of any work that computes a data flow graph as the program runs (i.e. data flow is implicit in the source code), which performs then reactively?
    - seanmcdirmid 12y ago
      Ya, that is exactly how Glitch works, except I just call the data flow graph as a dependency graph :). Computing the dependency graph dynamically obviously leads to a lot more flexibility. I'm not really sure what you mean by "reactively" here: if you mean does it reactively update computations as state (and even code, if you want to get Bret Victor about it) changes, then ya. Data flow by itself isn't necessarily reactive; actually the way it was originally defined to work very lazy push things through. Continuous interpretations where changes were propagated non-lazily didn't come until much later.

by tbirdz 12y ago

amelius 12y ago

I think the biggest problems with flow based or reactive programming are the occurrence of glitches, and, more importantly, the problem of how to compute updates without performing unnecessary work. I wonder if these problems have been successfully addressed somewhere.

seanmcdirmid 12y ago
My work [1] addresses glitches head on (hence the system is called "Glitch") by tolerating glitches and at least making the extra work functionally benign (via logging and rollback, like a transaction). Glitch is not based on data flow, however, but somewhere in between even if still very reactive. I've built a few data flow systems in the past (my dissertation work [2] was based on one), but I decided to tolerate rather than avoid glitches early on because I found that way to be more resilient. Flapjax [3] avoids glitching via a topological sort, which I rather see as an optimization (to reduce unnecessary work) rather than as a correctness issue. [1] http://research.microsoft.com/apps/pubs/default.aspx?id=226574 http://research.microsoft.com/apps/pubs/default.aspx?id=2265... [2] http://research.microsoft.com/pubs/179366/mcdirmid06superglue.pdf http://research.microsoft.com/pubs/179366/mcdirmid06superglu... [3] http://cs.brown.edu/~sk/Publications/Papers/Published/mgbcgbk-flapjax/paper.pdf http://cs.brown.edu/~sk/Publications/Papers/Published/mgbcgb...
- amelius 12y ago
  Interesting. Do you know of any work that computes a data flow graph as the program runs (i.e. data flow is implicit in the source code), which performs then reactively?
  - seanmcdirmid 12y ago
    Ya, that is exactly how Glitch works, except I just call the data flow graph as a dependency graph :). Computing the dependency graph dynamically obviously leads to a lot more flexibility. I'm not really sure what you mean by "reactively" here: if you mean does it reactively update computations as state (and even code, if you want to get Bret Victor about it) changes, then ya. Data flow by itself isn't necessarily reactive; actually the way it was originally defined to work very lazy push things through. Continuous interpretations where changes were propagated non-lazily didn't come until much later.