Stjepan Rajko wrote:
On Thu, Sep 4, 2008 at 8:24 PM, Herv? Br?nnimann <hervebronnimann@mac.com> 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.