Bret Victor - Inventing on Principle

[Regan Heath]

On Tue, 20 Nov 2012 00:50:42 -0000, Walter Bright  
<newshound2 at digitalmars.com> wrote:

> On 11/19/2012 6:26 AM, Regan Heath wrote:
>> Hope no-one minds..
>>
>> I stumbled across this video which I thought was pretty darn cool:
>> http://www.youtube.com/watch?v=PUv66718DII
>
> Can you give us a summary or synopsis?

Sorry, I really should have done that.  As bearophile says it's hard to  
summarise, but as Andrei mentioned it's well worth watching.

It is essentially about making it easier to "create" things.  Finding  
areas where the process of creating something is difficult and analysing  
why.  In most of the cases he shows the problem is a detachment between  
the method of creation and the result.

Like code for example, we write code but get no immediate feedback of our  
changes.  Instead we have to compile, <insert steps for  
copy/installing/etc the result>, then run the program to see the results.   
He shows an interactive IDE which displays the program output side by side  
with the code, in this case a game with a character that jumps about the  
place.  He can click on a variable and alter it's value with a slider and  
see immediate feedback.  There are also some neat tools for manipulating  
time allowing you to see the result of changes over time and tweak values  
to exactly those values you want/need.  (This example reminded me of the  
game Braid).

Another example is of defining a new algorithm.  In this example the IDE  
asks for example input values, and then it shows the variables of the  
algorithm at each stage as the programmer defines them.  It shows the  
values for each iteration of a loop, and allows the coder to test various  
input and actually "see" the results rather than having to imagine them  
all in their head.

Both of these are examples of where creation is hindered by the programmer  
having to visualise the result as they design - something all good  
developers can do well, sure, but why force ourselves to pretend to be a  
computer when we have a computer sitting in front of us which is  
infinitely better at it than we are?

How many times have we sat there and written the content of a string out  
on paper, labeled the indexes, drawn pointers to characters, etc in order  
to design an algorithm that deals with strings.  I still do this fairly  
frequently, even when I'm confident sure I've got it right, simply to  
verify my work and check for edge cases.

One further example shows him designing an animation in the conventional  
way using key frames and then again using a new system of touch based  
commands.  This example was born out of the frustration he experienced  
spending a whole day animating a leaf falling from a tree in a natural way  
(using key frames) - a task he accomplishes in less than 2 minutes as you  
watch using his new system.

A killer IDEA like those shown should be doable in D, for D.  We have a  
debugger (or code that can debug D) and the compile time speed of D is  
such that on-the-fly compile and display shouldn't be prohibitively slow.   
All it needs is someone motivated and perhaps easier/better linking  
between the required parts i.e. D front end, compiler, debugger, GUI  
toolkit..

Regan

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/