This overall theme became even more apparent in these last two talks and I think he'll make it explicit in his last talk (scheduled for May 28).
I predict that we are on the verge of a transformation in thinking about the role of programming. In short:
Phase I: Code -> Artifact
Phase II: Code -> Tools -> Artifact
Phase III: Code -> Tool -> Tools -> Artifact
In Phase III, programmers will work on creating ways to make the kind of tools THEMSELVES that Bret shows as easy to create as the artifacts that those tools create. In other words: code creates metatools. I wouldn't be at all surprised if this is the punch line to Bret's final talk.
That's not the entire point at all. It was fundamentally about having a personal principle about what you feel is important and following this principle in all of your work. Why do you think it was called "Inventing on Principle"?
Everybody obsesses about the ideas for tools he had but the talk was about inspiring people to create and follow their own principles. It wasn't about developers copying a better way.
He could have just made it a talk about his own very great ideas but he didn't, he told you a way of thinking about "your work".
An MIT prof after my talk: "It's as if you showed us how to climb Everest, and then at the end you say, 'We need to go to the moon.'"
He changed his Twitter bio to say "to the moon."
This is something that I've been working on a lot. A lot of the time you have an idea about how something should be working, but then you look at the code and it turns out it'll be a bunch of work and refactoring to get what you want... at which point, you might start to think of "cheaper" solutions...
Sure, sometimes the cheaper solution is really great, but most of the time you're letting your own implementation difficulties get in the way and cloud your design vision.
I really like Bret Victor and he's been really inspiring, not only with the kind of things I want to build, but also how I go about building.
I've started building my own touch interfaces and incorporating visual programming environments to work alongside the text based code that it is built on.
http://moonbase.com - visual programming environment demo http://williamcotton.github.io/nox - a touch interface exploratory demo
Moonbase started as exploration and became a product, although development on this specific codebase has halted.
Nox is still in exploration mode, but plans to eventually take up where Moonbase left off and is my attempt to have my design and interaction side take precedence. Right now it is just a simple exploration of a touch-and-hold graphical menu.
BTW, I know Bret hates visual programming metaphors like "boxes and noodles", but they do make sense for some sorts of things, especially audio and image filtering. I'm quite a big fan of both MaxMSP and Quartz Composer.
We need to use things like recursion and iteration in order to properly express our ideas and I have yet to see an abstraction of these concepts that makes perfect sense to the untrained and unexperienced mind. Who knows, maybe we'll get there.
In the same way that he considers it dangerous to rely on code or other "action at a distance" mechanisms for art, I consider it dangerous to believe that immediacy is the most worthwhile pursuit. It expands the playful space of thought, but that's not the only space we can work from. Deductive frameworks, for example, aren't playful at all.
I'm planning to create an interactive album based on this concept, where the listener can explore a 'sound world' at their own pace through gestures.
I think the main takeaway message from the last two talks is to show how by creating tools, one can enable working in fundamentally different ways, and the creation of fundamentally different things that wouldn't have been practical to create otherwise.
