I'm not nearly to the point where this is useful for learning, but here's my opaque, sloppy, experimental interpretation so far: explain1. The UI is made primarily in HTML5 Canvas, because I'm interested in drawing more than I am in dancing around the DOM, and because I would like to have the editor UI be constructed from the same tools available to the user.
Suggested self-guided tour (feel free to go off tutorial at any time):
- Click the "circle" button, drag the resulting node off of the button bar by its title bar (this is the poor man's auto-arrange). A red circle should appear on the small canvas on the right.
- Click the white box labelled "size" on the circle node. This should turn red and "30" should appear in the input box at the top of the page. Change this to 50 and press enter to commit, the circle should now be larger, and the "size" box should be white again. You have changed a constant argument.
- Click the "wave" button, drag the new wave node somewhere. This should have no visible effect on the canvas.
- Click and drag from the white square marked "osc" on the wave node to "y" on the circle node. This should draw a blue line between the two, and when you're done the circle should start bouncing. You've changed the y argument from a fixed value to a function computed by the wave node.
- You should be able to edit the "period" argument of the wave node from 1000 to 500 as in step 2.
There's a lot more than can be done even with the few options I've provided, but you can see how you quickly get to the point where the editor window fills up, and the code isn't very good. I want to be able to have the user edit the code and have this impact the flowchart as well, but I have not decided quite what the nature of this relationship should be. Ultimately I want it to be possible to design the editor interface and program translator within the interface that I am providing, but that may be some time off. It'll be coming together on github.
The system is called "explain" because I want it to be able to explain why textual, imperative code works the way it does, how a competent programmer would assemble it from some other paradigm (data flow, functional, …?). I won't try to simulate a competent programmer, though, so a big part of this is going to rely on annotations; comments giving hints as to how the JS maps to a graph (including graph node coordinates, likely), animated walkthroughs created with the system itself, etc.
P.S. – I began this writeup with the intention of publishing something in 2012, though it wound up a bit more involved. It's a bit after midnight where I'm writing (New Jersey) but still 2012 where I wrote the last post (Texas) and where I lived most of the time in between (California).