Re: [boost] [review] Dataflow Library

Subject: Re: [boost] [review] Dataflow Library
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2008-09-05 07:30:14

Stjepan Rajko wrote:
> On Thu, Sep 4, 2008 at 8:24 PM, Herv? Br?nnimann
> <hervebronnimann_at_[hidden]> wrote:
>> Stjepan: I'm just curious, because my wife uses such a dataflow program for
>> interactive music performance.
>>
>> The program is called MAX and is distributed by a company named Cyclic74
>
> I really appreciate you bringing up MAX - it was actually my exposure
> to MAX that eventually lead me to write the Dataflow library. I had
> previously seen dataflow programming in LabVIEW, but it wasn't until
> MAX that I realized how easily people (with no formal programming
> training) did really cool things with such an environment.

This is some very interesting rationale that you hadn't previously 
shared with us ;-)

A question that had been forming in my mind was, "Who is this library 
for?".  Do you see this library useful primarily for people with no (or 
little) formal programming training?  If so, do you really think that 
Boost, or for that matter C++, is the right starting point?  Or perhaps 
you believe that the benefits that those people see would also apply to 
mainstream software developers?  Are you hoping that "regular C++ 
programmers like us" will start to use the dataflow style with the help 
of the library, or is there an existing body of dataflow programmers 
who currently use some other language who can be "converted"?

I also wonder how much of the benefit of a graphical environment like 
LabVIEW carry over into your textual dataflow description (even with 2D 
operator overloading).  It seems to me that one of the main benefits of 
a GUI is that the user is somewhat guided towards a "syntactically 
correct" program by the help of, for example, labelled parameter fields 
to fill in on the components.  That, and other aspects, are lost.

It may be significant that systems like LabView and MAX have not 
escaped from their niche application areas.  "Real programmers prefer 
text" perhaps.  Note that over the last couple of decades, chip design 
has almost entirely moved from GUI input (schematic capture) to textual 
input (hardware description languages).

And while thinking about hardware description languages, note also that 
they don't expose any sort of dataflow model even though the underlying 
circuit often has that sort of structure.  Similarly, when people were 
building "dataflow computers" back in the '80s they wrote compilers 
that hid the dataflow nature of the hardware behind a more conventional 
programming language (e.g. SISAL).

The closest to what you're proposing that I have seen is the stuff that 
the GNU Radio project is doing; I mentioned them on this list once 
before.  (They have been in the news recently after operating a GSM 
base station using their software radio at Burning Man.)  It would be 
really helpful if you could perhaps try to re-implement some of their 
stuff using your library, and see how it compares in terms of ease of 
coding, performance etc.  You could ask them to compare it themselves 
and submit reviews here.

I think you really need to justify to us why this library is useful, 
and to whom.

>> - can you create push networks with cycles?
>
> Yes, as long as the components are designed in such a way that doesn't
> propagate the signal in an infinitely recursive loop.

I am reminded here of the design of asynchronous circuits using 
handshake signalling.  You might like to have a look at Kees van 
Berkel's thesis, which seems to be visible at books.google.com.

Regards,  Phil.