Visual Programming: NoFlo and Flow-based Programming

Moritz Maxeiner via Digitalmars-d digitalmars-d at puremagic.com
Fri Apr 14 02:58:37 PDT 2017


On Friday, 14 April 2017 at 08:31:02 UTC, davidvm wrote:
> Hello everyone,
>
> I just want to share this thought with you:
>
> I think a great way that could maybe help popularize the use of 
> D, could be by developing a Flow-based programming (FBP) 
> implementation for NoFlo and Flowhub.
>
> [...]
>
> What do you think? Please comment if you think this is a good 
> idea.

The primary advantage of FBP systems imho is the ability to 
switch out logic of individual data processors without having to 
make changes to the data flow semantics, or other processors. The 
cost, of course, is that the overhead of modeling the data flow 
is generally not negligible (-> information buffers). The 
tradeoff seems to work well for environments with live changes 
(the best example imho being I/O redirection/piping in UNIX 
shells), but in a statically compiled language such as D you 
can't switch out internal parts of the application live anyway 
(you need to recompile), so I'm not convinced that it's worth it 
to have it baked in.
The way I've been using FBP is this:
- Data flow is modeled via either sockets, pipes, or whatever I/O 
scheme your OS supports
- Data processors are modeled as OS processes that communicate 
with the chosen I/O scheme
This way you have maximum decoupling of data flow and data 
processors and all you generally need to agree on between data 
processors is the serialization of data; it also happens to be 
what OS's are usually tuned to be extremely good at in terms of 
performance.

In summary: Well tested, performant and usually simple (complain 
to your OS vendor if not) ways to construct FBP systems have 
existed for several decades and I think the ROI for creating 
custom language solutions is far too low to justify the costs.


More information about the Digitalmars-d mailing list