Just to add some grist to the mill, I wonder if Bret Victor's demo is not so much about visual programming but more about responsive programming. When he manipulates the java script code and the graphics on the other side of the page change he is not working visually, he is working textually and seeing the graphical results synchronously. Visual programming is more like the Scratch language where the manipulation of objects or icons results in constructing a program. What Bret's demo shows might be thought of more as visual debugging or responsive programming. The main idea that I see behind Bret's work is that the gap between the program and the result become as narrow as possible. The largest gap is seen in a compiled language where a program is submitted and the result returned later. A change is made and the entire program is resubmitted to see the results that return. The advantage of this is that there can be a great deal of efficiency built into the program since it all laid out in advance. The next step is interpreted programs such as J which provide their responses at then press of a return key, although there still remains an opportunity to build scripts so that larger programs can be refined and stored. This is a bit of the best of both worlds, but the continuum does not stop there. Next are Bret's examples which I think more of responsive programming. As the variables in the coding are manipulated using a graphical user interface including sliders and other input elements, the results can be seen in real time immediately.
In Bret's case the output is largely visual in the form of games, but this could be done almost as easily with sound, and in fact our model may not be writers who are becoming painters, but engineers who are becoming players. There would not be many musicians outside of the Baroque masters such as Bach who would survive in a world where the music needed to be compiled before it was heard. Compiling becomes writing a symphony; although the music may be tested out on an instrument for tune and harmony, it would only be heard when performed by the entire group. Interpreted languages such as J, as it currently exists, seem to me to be more like the early music composition programs, when you did not directly play the music but instead were required to graphically move the notes and then have them played back to you. The music programming world did not stop here for long since it already had instruments that allowed immediate response to the actions of the player and we now have interface s such as GarageBand on the iPad where you can tap the drums on your screen or strum the strings of your virtual guitar and have the music and its notation recorded acoustically and textually. Of course most of us have not developed our skills to the point where we can play a program the way a jazz musician plays their instrument but this may be the next step, if we can develop the interface. What makes this so exciting is that this bridge can be built using the new materials that fast processing speeds and better graphical interfaces afford. A good video to watch is Alan Kay's 'Extracting Energy from the Turing Tarpit' where he discusses the ideas behind Bret's demo. http://amturing.acm.org/acm_tcc_webcasts.cfm Cheers, bob On 2013-01-12, at 6:38 PM, Raul Miller wrote: > I believe that a distinction between a "text tool" and a "visual tool" > is a false dichotomy. We use our eyes to perceive text. And the > concept of a language can certainly be used in visual presentation. > > That said, "visual tools" typically have abandoned or concealed the > generality of language in various contexts. > > -- > Raul > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
