The thing that you don't know in the programming example is what those numbers do. I've written processing.js code before and I'd be half-guessing if you asked me what each parameter to elipse() does.
"ellipse" and numbers are only hints, just as blank buttons and dials are only hints.
Programmers rely a lot on IDE support now to see the parameters...which is exactly what Bret is talking about!
DrawEllipse(x=50, y=25, width=32, height=5)
No real-time rendering and tracing of values required (I hope!). Furthermore, a decent IDE will bring in the method doc blurb, so the programer has a richer context to make an informed decision.
I appreciate the work Brett put into the article and I'm half way pre-convinced myself. At the end I was somewhat disappointed because most of the stuff he talks about is already present in a decent IDE, perhaps in a less polished form, but present nonetheless.
The deeper put-off is that the article seems to advocate not thinking, instead performing random walks using shiny tools. If someone can't think about their code, no amount of visualizations is going to help. That being said, the potential of enhancing one's thinking abilities by properly chosen visualizations is tantalizing, but I don't think the article makes a good case for it and I haven't yet seen a better approach than old school pen and paper.
Most of the article tries to make the point that if someone can't visualize what their code is doing, they can't think; they can't reason about it.
Building the right visualisations that hold at master level as well as at novice level holds the promise to expand one logical abilities far beyond what our current ones.