Bret Victor - Inventing on Principle

[Paulo Pinto]

On Tuesday, 20 November 2012 at 12:45:46 UTC, Regan Heath wrote:
> 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

The sad part is that many of these ideas were already available, 
to certain
extent, in the Smalltalk and Lisp environments.

Now, like with many other concepts, we are kind of rediscovering 
the principles.

--
Paulo