
Towards Separation of Concerns in Flow-Based Programming (2015) [pdf] - 0_gravitas
http://orbit.dtu.dk/files/128046887/FBDSL_final.pdf
======
rectang
> _Flow-Based Programming (FBP) is a programming paradigm that models software
> systems as a directed graph of predefined processes which run asynchronously
> and exchange data through input and output ports._

"Flow-based Programming"/"FBP" is a subtype of "dataflow" programming as I
understand it. The distinguishing characteristic of "dataflow" is that the
program is represented as a directed graph, where data moves across arcs
connecting nodes.

From there we have "synchronous dataflow"/"asynchronous dataflow", "fine-
grained/coarse-grained" dataflow (nodes as machine-level instructions vs.
nodes as arbitrarily complex functions), and so on.

Going from the definition above, what distinguishes FBP within "dataflow" are
1) that the nodes are "processes", and 2) that execution is asynchronous.

I wish that "flow-based programming"/"FBP" advocates would place it
deliberately within the hierarchy of "dataflow". I appreciate the historical
forces which have prevented this, but it is confusing when you come to the
subject as an outsider.

For a nice writeup on dataflow see this 2004 paper, especially section 2.1
"The Pure Dataflow Model" on pages 3-4:
[http://www.cs.ucf.edu/~dcm/Teaching/COT4810-Spring2011/Liter...](http://www.cs.ucf.edu/~dcm/Teaching/COT4810-Spring2011/Literature/DataFlowProgrammingLanguages.pdf)

~~~
samuell
I've always been placing FBP under dataflow.

Regarding distinguishing features though, AFAIK, one of the more important
ones is that in FBP, connections between processes are done via named ports on
processes, and that the wiring of these connections is thus enabled to be done
_separately_ from the process implementation itself. Dataflow, AFAIK, does not
specify how the data network is specified.

We tried to describe this feature under the "Reusable component" with a figure
(fig 3) in this (open access) paper:
[https://academic.oup.com/gigascience/article/8/5/giz044/5480...](https://academic.oup.com/gigascience/article/8/5/giz044/5480570#134301289)
(link goes directly to the relevant section).

------
frumiousirc
In summary: they invent a language to describe a form of graph rewriting and
apply it to modify FBP graphs to introduce new "concerns" as overlayed
subgraphs.

The rewriting is limited to be performed in terms of a fixed set of patterns
called "advices". There are two fundamental advices ("observer": branching an
edge and "adapter": breaking an edge) and one special case ("collector": apply
an observer to each top level node in a composite node).

A Java implementation was developed.

