Visualizing Code to Fail Faster
codinghorror.com
codinghorror.com
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.
That kind of thinking gave us Eclipse.
Microsoft is leading the way. http://msdn.microsoft.com/en-us/roslyn
And Clojure looks promising. http://blog.fogus.me/2012/03/27/compiling-clojure-to-javascr...
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.
The opportunity is that the professionals get/have to work on Real Problems.
What is just as interesting is that I've also heard incredibly negative reactions to his talk, which is also telling.
That said it was a great presentation because showing that flash gets the brain gears turning on realistic ways to increase iteration times.
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?
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.
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.
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.
http://en.wikipedia.org/wiki/Braid_(video_game) http://braid-game.com/
It is very inspiring to see such creativity and the courage to express it from people like Jonathan and Bret.
see "debugging backwards in time" by Bil Lewis (yes, one "L" in each word.) http://www.lambdacs.com/debugger/AADEBUG_Mar_03.pdf
Inform 7 is just awesome in general. The source code reads like English. Here's a code snippet: http://inform7.com/learn/eg/dm/source_14.html
http://tnlogy.github.com/tnlogy/
( over the number CTRL + Left Click )
https://github.com/tnlogy/live-coding (not linked from the demo)
I'm working on making it easier to share discoveries by powering the water project with a gist backend: http://enjalot.com/tributary/2165875/sinwaves.js
So many genius ideas in the first 15 minutes of that talk... people will be working for years to realize these things!
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.