On Tuesday, 20 November 2012 at 12:45:46 UTC, Regan Heath wrote:
On Tue, 20 Nov 2012 00:50:42 -0000, Walter Bright
<[email protected]> 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
