Simula was about Queues¶
The running joke in the FBP slack group is how everyone discovers FBP by implementing their own version first. Why is FBP replicated so many times ? Flow based principles are a platonic ideal.
According to Paul Morrison, It is probably yet another case of “steam-engine” i.e, when it is time for the steam engine to be invented, it will pop up all over!
I think Data Flow is more akin to physics than maths - fluid mechanics, air flow, molecule movements, electricity … that movement seems to be reflected in networks in general, like unit records or network packets.
In Simula co-routines were natively supported. Simula 1 vs Simula 67 is approximately like C (fork/exec + pipes) vs C++20 (class + co-routines). Javascript can be considered as a true successor to Simula because of the extensive co-routine support. Simula was about discrete event modeling using co-routines and queues, not just type hierarchies. In many ways Simula is the first event driven programming language. I would also call golang an event driven language along the lines of Simula. The presence of channels in golang makes it very easy to implement queues making it ideal for Data Flow based approaches. I believe this modeling is precisely possible because co-routines can easily simulate state machines and actors.
In many ways Data Flow and Von Neuman styles are inverse. Data Flow is about queues, whereas Von Neuman has mostly been implemented via stacks. Queues are more fundamental to programming than stacks and naturally enable asynchronous styles of programming common in many business use cases.
Uses of Queues
Managing Jobs
Data transformation - Pipelines are FIFO Queues
Event Broadcasting via a Bus - Multicast, Publish Subscribe, Point to Point
Stream Processing
Message Queues are easier to implement. Message queues with their routing, point-to-point and broadcast semantics probably solve some important use cases that you could use FBP for. The beauty of FBP is that it solves the most general case. Data Flow is most similar to Active Objects and Actor Model, however these systems model Nodes but not the connections. I think a combination of Messaging and Data Flow will complement each other nicely and help glue Data Flow on top of existing systems.
See Also,
http://www.fourmilab.ch/babbage/sketch.html
Record Units
Queue Automaton
https://fbp.twyoung.com/
GPSS
the E language
Types of Data Flow¶
Static Data Flow / Synchronous Data Flow: Unix Pipes, XML Processing, ETL, Batch Processing Systems, ML …
FBP
Dynamic Data Flow
In Data Flow models, actors begin execution (they are fired) when their required data inputs become available. SDF is a relatively simple case of Data Flow; the order in which actors are executed is static, and does not depend on the data that is processed (the values of the tokens that are passed between actors).
In Dynamic Data Flow the order in which the Actors are executed depends on the tokens themselves. BooleanSelect is an example of Dynamic Data Flow. Not only this, nodes can be created at Runtime. Dynamic Data Flow is a turing complete version of Data Flow.
FBP ~ Dynamic Data Flow > Static Data Flow in terms of expressive power.
Here is a short paper with useful references / diagrams
http://www.artist-embedded.org/docs/Events/2006/MoCC_Zurich/geilen-MoCC06.pdf
Visual Programming¶
FBP is different from - visual programming, workflow systems and Data Flow programming. I think its a very important difference. The litmus test for FBP vs Reactive done using the concat component.
State Machines¶
A typical Data flow Node has four states
start
processing or waiting
stop
crash
However in practice, you can have stateful nodes which make a Node instance as powerful as a stack automaton or like a Mealy Machine.
Thinking in terms of state machine is useful for things like error handling, status checking …