This is why it's so shortsighted to say things like: "computers are so fast nowadays that everyone should be using GC/dynamic-typing/etc." A person who says this is limiting their thinking to the way we do things now. Parsers may not be on the critical path of most compilers, but if you could run a parser/linter/static-analyzer on every keystroke, you could start doing things that weren't even possible before.
We'll always be able to find ways to use extra CPU cycles to make things more pleasant to use. We'll add more pixels or decrease response times or do deeper or more frequent analysis. There will never be a time when computers are "fast enough" that low level languages and programming for performance become obsolete.
I must have been unclear, because Eclipse is exactly what I am arguing against.
The developers of Eclipse made a choice to write Eclipse in Java. Java is a language that trades performance for developer productivity with features like memory safety, garbage collection, and machine-independent byte-code. Though I wasn't there, I would suspect the rationale for this choice is that computers are "fast enough" that this tradeoff is worth it.
The choice to use Java instead of C++ favored the productivity of the Eclipse developers over the run-time performance of Eclipse, and the effects of this choice are so painful that Eclipse has become the poster child of a sluggish desktop app.
What I am arguing for is the idea that computers aren't "fast enough" to make compromises like this. Data-intensive applications will continue to be written in low-level languages. Even if a higher-level language could provide basic functionality that is "fast enough," a lower-level language will free up CPU resources that can be spent making the application even more compelling to the end-user.
I hope this makes it clear why Eclipse is the antithesis of what I believe.
It's also breaking up our monolithic compilers, giving us incremental, modular Compiler As A Service, which is where the code annotations and feedback will ultimately come from.
You've got to have big ego to write, that Bret Victor's innovative ideas are not "entirely abstract art house visualization nonsense". BV's demos set the direction in which the whole field of working with ideas, including designers and programmers should be going. In 2012 programmers shouldn't have to be really good at running the code in their heads while writing it.
+1. I think many people feel threatened by these ideas, and the potential to open up programming to a whole cadre of non-professionals who won't need them.
The opportunity is that the professionals get/have to work on Real Problems.
A tangent, but I like the fact that more and more people are seeing BV's video and getting inspired by it. It's made a big impact for me, and I'm seing a steady stream of folks referencing it almost a month after it was given.
What is just as interesting is that I've also heard incredibly negative reactions to his talk, which is also telling.
I was disappointed by the lack of practicality in a lot of the presentation. In some ways there was more flash the substance. The ghost image/time rewind isn't realistic for any real game development. The movie making ipad app was a neat toy but totally impractical in a professional environment.
That said it was a great presentation because showing that flash gets the brain gears turning on realistic ways to increase iteration times.
I like how your handle reminds me of "forest for the trees" as it's pretty appropriate ;)
Really though, disappointed? These are prototypes for the next generation of interaction, most people aren't even close to doing just one of the 5 ground breaking ideas he presented, and you expect him to release fully baked products?
Ha. I don't expect fully baked products but the prototypes feel a little avant-garde. Cool to look at but not actually useful or practical. Given the amount of attention it's gotten I walked away disappointed.
"If you want to build a ship, don't drum up people to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea."
- Antoine de Saint Exupéry
Show people the flash and the substance will follow. As I've said previously, if seeing that demo pushes me to try and implement it because it's painful to code after having seen it; then theres certainly many able individuals working on it right now. (I am a novice programmer in most respects, I couldn't do it. But damn if I didn't try.)
EDIT: Push does not mean I actually tried. But I'm getting there. Every time I sit down to code it nags at me that I can't see the code the way I always wish I could see it when I'm debugging.
I love a lot of what he says, but a few things really frustrate me.
The great thing about people who try to "productize" their ideas, is that they have to confront all the embarrassing situations where their approach really doesn't work that well, because they have actual users they are responsible to.
If you don't want to do that, I think your influence can be directly negative: When other people try to step into that position, they will end up having to defend why they are screwing up a simple, beautiful idea, which is what invariably happens when theory meets reality.
I don't think this is a small problem; just in the talk and in the corresponding article, Bret himself will gladly insult the people who created the tools available today, for no other reason than not offering general solutions to support interactive development. And he does this without giving any indication that general solutions might exist. Competing for mind-share with something that doesn't have to actually exist can be pretty hard.
The honest truth is that the kinds of interactive tooling that Bret wants might be an "essential complexity" in the sense used in "No Silver Bullet": The tools will have to be handcrafted from situation to situation, with little potential for reuse. And in some cases, that tooling will probably be far more work than the nature of the problem requires. To paraphrase the classic warning about overuse of regular expressions:
Some people, when confronted with a problem, think "I know, I'll create an interactive model of the abstractions that could be involved."
Now they have a far, far greater problem.
I'm going to stop before I get into his description of people who "simulate computers in their head", because this is already starting to sound more negative than I want it to. I really did love both the talk and the article. But I feel Bret is going completely counter to the principles he described in the second half of the talk. Often the real moral choice is to be just another boring implementer.
Maybe it was an outlier, but a friend had a visceral reaction against the design aesthetics of his demos and thought the principle examples he gave were depressing. Overall, since I've evangelized in my humble ways the message from the talk, I've learned that not everyone believes that a principle based approach is the ideal path. Some are interested in solving hard problems for the sake of solving them, and others are interested in making lots of money. Nothing inherently wrong with either, but still a bit surprising for some reason.
The game demo Bret uses is based on time mechanic concepts developed in the 2009 game Braid by Jonathan Blow.
I am not a gamer but I downloaded the game over the weekend because of the talk, and highly recommend it, it's a real work of art with serious production values, and easy to download for Windows, Mac and Linux.
Am I the only one who feels like the game demo was so awesome that it overshadowed some of the other parts of the presentation, parts that were just as interesting yet probably more feasible? I would kill to have just the algorithm evaluator part become reality.
No, your not. Personally I think that on a much more practical level the algorithm evaluator would be a godsend. The animation app and the braid demo just seemed too narrow in their application to really be useful in the real world. The algorithm visualizer? I want it; now. It hurts to do code in my head after seeing that, to the point where I almost abandon hope and try to implement it.
Something I would love to have is a debugger for an interpreted language which visualises the program's state as a graph, say, and you can wind time forward and back. Then, as you make changes to the code the visualisation updates according to what the program's state would have been at this point in the program had it been running the updated code. To me that would feel like magic.
> Something I would love to have is a debugger for an interpreted language which visualises the program's state as a graph, say, and you can wind time forward and back.
This actually exists in the IDE for Inform7, a DSL for writing interactive fiction (text adventure) games. The feature is called "Skein", and it will graph all your playtests, and highlight in red which ones changed after you change your code. You can see it at 6:20 in this video: http://vimeo.com/4221277
I think this also has applicability to other domains where quick iterations can be extremely useful--for example, testing data modelling--unfortunately, a lot of codes are too computationally expensive to run in such an interactive fashion...
You type javascript on the left and get the result on the right. I use it myself all the time. You can type js right away or try the examples on the bottom to get a feeling for what its doing.
This is pretty nice. I wonder how hard it would be to import a minimal stats package. That and a table entry widget would make this a superb environment for a 1 semester probability and stats class.
We'll always be able to find ways to use extra CPU cycles to make things more pleasant to use. We'll add more pixels or decrease response times or do deeper or more frequent analysis. There will never be a time when computers are "fast enough" that low level languages and programming for performance become obsolete.