Concurrency is the new normal (dataflow vs. FBP)

Skip to first unread message

Paul Tarvydas

Aug 3, 2021, 12:00:23 PM8/3/21
to Flow Based Programming
For discussion [re. dataflow PWL posted in the Slack group]:

1) It appears that dataflow is a subset of FBP.

Dataflow means nodes that are "fired" when all inputs are ready.

FBP, OTOH, allows nodes to choose inputs from specific ports and to defer reading data from ports at will.

2) This video states that dataflow has problems with loops.

Loop, Recursion and CALL/RETURN should be expunged from new programming languages.

Loops (and recursion and CALL/RETURN) are outdated concepts that are not meaningful in a network environment.

All new languages should be geared for programming networks.

Loops are the exception, not the rule.

Network nodes can form "loops" by sending messages to themselves.

3) Concurrency/FBP allows a node to consume input and to produce NO output in response.  [Nothing - no response at all].

Dataflow, as described in this video, does not allow this (easily).

This is a *huge* difference.

It's like 0 being added to the Natural Number system.

The concept of 0 appears to be a nothing-burger, but it's hugely important.

For example, double-entry bookkeeping is not even imaginable without 0.

Writing code for a server is harder if you have only functions and don't provide run-forever components.  Servers are not Functions, servers are Components that run forever.

Corollary: multitasking is easy if you don't have to express it in a synchronous notation, for example using synchronous low-level operations supported by "thread libraries" and synchronous languages where concurrency is but an after-thought.

Concurrency is the new normal.

Reply all
Reply to author
0 new messages