Re: [boost] Flow-based programming library for Boost?

Subject: Re: [boost] Flow-based programming library for Boost?
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2012-12-08 22:02:16

Marcus Tomlinson wrote:

> Is there any interest out there for a library that allows you to create
> fast, efficient flow-based programs with an easy-to-use object-oriented
> interface? (http://en.wikipedia.org/wiki/Flow-based_programming)
> 
> I've created an open-source library that does this, called "DSPatch" (
> http://sourceforge.net/projects/dspatch) and would like to contribute it to
> the Boost Libraries.

I'm certainly interested in a Boost library that offers efficient 
flow-based multithreading with an interface that is as simple as 
possible. In fact I have some ideas of my own which I would gladly 
present to the mailing list when I find more time.

As has been pointed out by other people, there are lots of dataflow 
libraries out there, all offering similar functionality. I believe the 
reason for this is that it's hard to get right. In particular, it's 
hard to offer the functionality through an interface that is truly 
simple enough.

I think your proposal suffers from this same problem. As far as I'm 
concerned users should not need to inherit from a class in order to do 
flow-based programming, nor should they need to create a circuit 
object to provide wiring between the working components -- let alone 
have to invoke methods on said object for each worker /and/ for each 
connection. The connection methods have four arguments, which is too 
much.

On top of that I think a dataflow programming library can and should 
be more powerful. Your framework allows for many-to-many connections, 
but as far as I can tell from your documentation there are no standard 
facilities that handle generic patterns such as distributing worker 
output over multiple receivers. There doesn't seem to be a way to 
directly extract multiple values in succession from an input 
DspSignal(Bus). Polymorphism on the connections is handled by dynamic 
typing while it could be static. I suspect there are more limitations.

Finally I believe object oriented design offers no advantage for 
dataflow programming. It's not really in line with common Boost style 
either.

Concluding, while I fullheartedly agree with your intentions, I would 
vote against your library if you were to submit it for a formal 
review. I'm sorry to say this but I think Boost needs something that 
is both simpler and more flexible.

-Julian