Interesting how this could tie into the diagrams coming out of the dataflow paradigm (flumejava, flink, millwheel, naiad, and Frank McSherry's rust timely-dataflow). All of which can be succinctly diagrammed out, but I like the rigor of this. People in this thread have mentioned Max/MSP (it's precursor puredata/pd) are really interesting visually, but they often feel write only. Some of the rules of drakon could be attempted in a max patch, but the shortest path nature and lack of jump labels could foil the idea.
At any rate, some food for thought when it comes to trying to ideate programs away from a computer or at least away from a repl or IDE.
It looks to me like Drakon is more of a control flow paradigm than a data flow paradigm. What flows along the wires, other than the "program counter"? How is data represented?
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.
Drakon can describe data too. From the Drakon website:
What is ERIL? ERIL is a graphics language for representing data model. It is based on entity-relationship and class diagrams. Thus the name, Entity-Relationship and Inheritance Language.
ERIL is a counterpart for DRAKON. The DRAKON language describes algorithms and behaviour. It is an improved version of flowcharts. DRAKON introduces some rules that make flowcharts more human-eye-friendly.
At any rate, some food for thought when it comes to trying to ideate programs away from a computer or at least away from a repl or IDE.