[adamnemecek]

I'm not quite sure what problem is this solving. What exactly does dataflow programming allow me to do that is not possible with non-data flow programming? It appears that the single components are still text, and data flow is only used to hook up these components. So how is this different than say an IDE with definition and reference lookup?

I've used Pure Data (which they mention) a little bit and here is an example of a somewhat advanced program. http://i.imgur.com/NRtG8Ai.jpg [1]. For Pure Data, dataflow somewhat makes sense (considering the problem domain) but if I had to pick between debugging the schema above and debugging text code, I think that I'd choose the latter.

[1] Image is from here http://www.spazioclang.org/eventi/live-electronics-con-pure-...

EDIT: Lol, here's an example of another PD program I found. http://i.imgur.com/Flwviol.jpg Now imagine that you inherit a legacy codebase that looks like that.

[rits]

Flow chart can be beautiful or ugly just as a textual code can be beautiful or ugly. Also shape of nodes and connectors as important as indentation in text. Look for example of some graph from Nuke - http://www.spaille.be/dev/wp-content/uploads/2010/10/works_n...

[rainforest]

> Now imagine that you inherit a legacy codebase that looks like that.

I wager that every codebase beyond a few years of churn looks like that, you just don't look at the CFG to see how much of a mess it is.

There's a key to their approach in that abstraction can be used - the nodes aren't statements as they are in PD, but chunks of code. This means the low-level stuff is hidden from you and you see how higher-level components integrate (if you take the time to tell it what the high level components are, presumably).