Definitely control flow not data flow, but the data is defined at each step of the graph in variables like normal. In Frank McSherry's Rust stuff and the Naiad stuff they seem to have a basic data structure of progress and "data to process". Where progress is handling the time step of the process. The dataflow isn't anything more than a variable being passed around and inputs and outputs. So the control structure is the important part.

This is sort of rambly, but in pd/max/msp you end up with at least 2 types of data flow rates (common in musical stuff like supercollider as well) for musical sample rates (aka 44.1khz or whatnot) and 'control flow' rates (like an LFO wub at 120bpm half notes). Those are all still wired up with the same "lines" in pd so it can end up being confusing if you put a control rate into a sample rate or vice versa. I'm sure current MaxMSP has ways to separate and handle those (along w/ "bangs" which are one off messages), but the beauty of something like drakon is that it is just control flow. The data is explicitly defined in the boxes. So even though dataflow is the phrase google and microsoft are throwing around, the real art is in the control flow. Look at the scopes and contexts from the naiad paper: http://www.frankmcsherry.org/dataflow/naiad/2014/12/29/TD_ti... I think that drakon would be an interesting way to draw that diagram out. Not one hundred percent sure, but it's a thought.