Although I find Bret's talks inspirational as well, I see obvious limitations to his approach of direct feedback everywhere. Namely, our art hasn't always been made in this fashion - that's an easily disproven statement. Textiles, architecture, and, indeed, most live performance have grown planning-intensive aspects.
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.
The tools that Bret talks about are insanely awesome and innovative. However, I don't think they are the holy grail of development. I think they will have a significant impact in a few specific fields, but will not apply to overall design and development as well. Thanks to dom for bringing this to my attention.
Nor, I think, are they even the point of Bret's work. The strongest hint of which is the title of his first popular talk: "Inventing on Principle". The entire point of that talk was "this is the kind of tool you could make if you stepped back a bit". In the beginning, no one seemed to get that... everyone just kept asking for the download link as if the talk was about the tool itself. Chris Granger and his team eventually got that, but the rest of the world seems to still be waiting for them.
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.
> The entire point of that talk was "this is the kind of tool you could make if you stepped back a bit".
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".
I'll add a chorus to the voice of those who have been inspired by Brett. I'm a musician, and his ideas have led me to explore live improvisation in a 'duet' with the computer, where I can allow the computer to improvise, or guide it as I choose.
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.
Bret has been a huge inspiration for my work and life.
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.
These talks are amazing and his app looks fantastic. While it's easy to be creative in code, it's still easy to lose a huge amount of what we were aiming for while coding. It's exciting to see someone like Bret Victor working on problems like this so explicitly.
> it's still easy to lose a huge amount of what we were aiming for while coding
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.
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.
Didn't remember who he was until I saw the "Inventing on Principle" cover slide - that talk and what he was doing in it blew my mind. It just felt like some kind of breakthrough about how to think about and do things with tools that now make these crazy and useful things possible... with (it seems) lots of cool applications for more efficient and satisfying education/learning.
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.