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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk