If you have not watched the talk (http://vimeo.com/36579366), I highly,
highly recommend it. It's a very worthwhile and inspiring hour. In it
Bret Victor (http://worrydream.com) discusses living life according to an
overriding principle. For him, that principle is that creative tools
should offer immediate feedback. He demonstrated a number of software
tools to that effect: creating computer art, games, algorithms,
electrical circuits and animations by seeing the effects in real-time
as you code them. The link is an implementation of one of his demos.
But more important than his particular example is the general theme.
Having a principle, which is a specific, actionable thing wrong with
the world (other examples from the talk: Larry Tesler and modal computing,
Richard Stallman and non-free software) is what allows you to have the
biggest impact. It's being able to look at something in the world and ask
yourself: does this match my principle, and if not, how can I fix it?
My favorite (paraphrased from audio) quote from presentation specific to principle of immediate feedback:
"I can make these changes as I think of them. That is so important to creative process. If there is any delay in that feedback loop between thinking about something and building on it, there is this whole world of ideas that will just never be. These are ideas that we can't think."
This principle is one of the best things about learning CSS with modern tools (Firebug, Web Inspector etc): if you wonder why something works, or how it could work given different values, you can just change the values live and see what happens. Firebug allows you to click in any value in CSS, and use up/down arrows to continuously vary it (for non-numeric properties, this scrolls through all possible values).
This enables a style of self-guided learning involving forming a mental model of how particular bits of CSS work, playing with them until they break in expected ways (validating the model) or unexpected ways (prompting more experimentation or a visit to documentation, and subsequent improvement of the model).
I can also attest to the fact that live web page prototyping is a fun way to impress non-coders/non-web-developers :)
Comparing creative works built using a slow-feedback model versus a fast-feedback model is also interesting. With music, fast feedback would be playing an instrument directly; slow feedback would be putting together the output with a sequencer or drum machine, or writing it on paper to be played by an orchestra. The fascinating bit comes when you get sufficiently advanced practitioners of the art of slow feedback - for instance, composers who can hold an orchestral score in their head and imagine how it will sound, essentially having built a sufficiently advanced mental model that they gained a fast-feedback loop within their imagination. Does this suggest that for any given domain, even if there are obstacles in the way of fast feedback, that someone will eventually always be able to transcend the domain's limitations... or does it suggest that if we had better ways of communicating an entire orchestral score in realtime to an orchestra, that composers would generate even better works?
I had the same reaction, the talk was amazing. And for me, it finally made it clear how someone can do something as hard as a startup and not give up: it takes belief in a (time invariant) principle.
Does Bret Victor write all those things himself? They are staggeringly awesome. I am now suffering from a major inferiority complex! This totally lit a fire under my ass.
I'm getting over my abject hate of skeuomorphism. I'm coming 'round to the idea that it can help give users confidence that they'll be able to use your product.
Probably because the editor demo'd in the talk did as well. (But that still doesn't explain it.) Perhaps it's to make it friendlier and less an "intimidating code editor".
What I don't get is why the output is on the left and the code on the right (again as in Victor's talk). For left-to-right language users, a left-to-right flow of input to output makes more sense. It's not a huge issue, but still puzzling.
Well, since the code is left-to-right, and the editor is presumably as wide as the longest line, the content will tend to be skewed to the left. By putting the editor pane on the right, you reduce the average distance between the code and the output.
I suppose, though I'd rather it be resizable and let me take full advantage of a monitor. I've been experimenting with this sort of live code preview with http://padhacker.net/ (target platform primarily tablets) and resizing has worked out pretty well. (When it does work. Shrinking the iframe gets sticky.)
I was amazed watching the video of Bret V. using a tool like this, but even given those expectations I'm impressed with how cool this is to use. Thank you very, very much for showing us this.
(Only such a beautiful specimen deserves such nitpicking, but: it's not a _genius_ talk, it's an _ingenious_ talk. _Ingenious_ is the adjective form of the noun _genius_.)
I disagree with your nitpick: "ingenious" merely means clever, and is much fainter praise than "genius". You probably think "genius" can only be used as a noun since it's use as an adjective is fairly recent (a decade, maybe?). If you insist on a "real" adjective, probably "brilliant" is a better fit.
Sadly, ctrl on a mac means you right-click instead of left-click. It then gets stuck editing anything you click near :/ (edit: ah, I see they've added alt support. fantastic, works a lot better now)
The setup is awesome though, and it does a great job demonstrating what all the values do. I'll have to watch the talk now.
I implement something like this for any sufficiently large (game) project I work on. I can tune the location/size/color/etc of any object on the screen in real time, just by scrolling my mouse left to right. The time saving is invaluable.
Field (http://openendedgroup.com/field) is a development environment that embraces the ideas of "code space as canvas" and experimentation through instant feedback; I was immediately reminded of it while watching Victor's talk. Values are editable with GUI elements embedded inside the code, almost identically to this demonstration (see https://vimeo.com/3001412 for an example).
Very glad to see our work (Field) mentioned in the context of Victor's talk — he's really nailed the essence of an important argument, and it's nice to see these ideas get some play in the broader programming community. If anybody is looking for some more live coding in JavaScript, we have that too — http://vimeo.com/31452523 (Canvas) and http://vimeo.com/31452523 (WebGL).
You guys might want to think about working on it together. His version includes the introspection on an item in the canvas as well as some other great things like inline, as you type JSLinting.
Very nice! I just discovered the talk and demo today. I noticed though that the rendering of the editor seems to vary across web browsers. The figure looks smaller and is positioned in the top-left in Firefox. But it's centered and looks otherwise normal in Chrome.
If you're on a Mac, take at look at Latexian [1]. It has a live preview pane, which works by recompiling the tex file in the background (incl. bibtex). And despite the ugly icon, the UI is pretty nice (if you run it in fullscreen, put the preview pane on the right side, turn off the toolbar and choose a nice font).
But more important than his particular example is the general theme. Having a principle, which is a specific, actionable thing wrong with the world (other examples from the talk: Larry Tesler and modal computing, Richard Stallman and non-free software) is what allows you to have the biggest impact. It's being able to look at something in the world and ask yourself: does this match my principle, and if not, how can I fix it?