> The programming environment exhibits the same ruthless abbreviation as this hypothetical cooking show. We see code on the left and a result on the right, but it's the steps in between which matter most. The computer traces a path through the code, looping around loops and calling into functions, updating variables and incrementally building up the output. We see none of this.
I mean, this is a nice start, but we still have lots of work to do before we really understand what we are doing in this area.
Hancock solves this problem with live text in Flogo II, but all we know about it is from his dissertation (http://llk.media.mit.edu/papers/ch-phd.pdf). I observed the same phenomena when I did my Sueperglue work back in 2007 (http://research.microsoft.com/apps/pubs/default.aspx?id=1793...), but I never really bothered to follow up until now (with inspiration from Bret's work, of course).
I'm working in this very area too.
One other thing I can add is that, IMO, it's very valuable to be able to easily execute a subset of the entire program (the tool should do everything it can to make the process easy, you just supply the necessary inputs).
Sounds sort of like Bracha's stance.
I think we should just focus on making the feedback better over an entire program execution. And we could make defining unit tests easy, which would provide the context needed to test smaller parts of the program.
Cheers
theres a difference between creating pixel perfect polished marketing sites and showcasing an evolving prototyping tool
being able to change the parameters of animations/simulations and see the results in real time is pretty incredible.
