I keep thinking a lot of Bret's points are absolutely wonderful food for thought, but blur the line between tool and use of a tool so much that they will never be practical. It is as if he's taking the outcome and suggesting the language should have known the outcome, but the point of coding is to enable all kinds of possible outcomes, and that set is not quantifiable before the fact.
but is that helpful? i mean, i love lots of various reference sites, and have enjoyed autocomplete and inline "labeling" of functions in IDEs, but I keep thinking about his talk that went big a bit ago, and keep thinking of these things he's developing as just analytic or test harnesses to zero in on a goal that he's actually already programmed. so, to ask for our tools to have these qualities built in assumes it knows anything about the total picture. for instance, processing's language is a small subset, so maybe it isn't the best example, but someone new to programming in processing might not realize that specifying fill 30 times means that only the last one is the effective one for the subsequent drawing. anyway, there's a lot of uninformed things you can do with any language, and i don't know that blurring the lines between input and interface give us any new insights for the actual act of coding. i think it is great for analysis of coding after the fact, however. like a JIT compiler or other compile time optimizations are great, but it assumes a complete and observable solution that has been expressed already.
another example that is maybe in the neighborhood of a valid response to your reply is like the heap size in java. if i know i what i'm doing and why, i could set it rather high to achieve a goal, but mostly i don't mess with it because its a great reminder i'm making a bigger mess maybe than i should be for whatever problem i'm working with... however, it seems that victor's ideology is that the heap should always know how big it should be given anything i might want to express, and that somehow the halting problem wouldn't apply.
Regarding your fill() example, I believe his point was that uninformed decisions are a reflection of the interface exposed. Since the fill color is an implicit global variable, and not exposed anywhere in the interface, there is no way to discover its existence or behavior except via trial and error or reading the documentation. If the fill color were either exposed via the programming interface, or were explicit, then no meta-knowledge would be required to use it.
Similarly, the heap size limits in Java are global limits implicit to the system, not to the program being designed. His solution to the larger problem—data growing beyond available resources–might involve providing a better visualization of the data. Something more responsive than the feedback loop provided by heap limits. Getting an OutOfMemoryException doesn't help you to understand how the data grew beyond expectations; it is always followed by a heap dump. What if you could better understand the patterns of allocation during design instead?
This is a fascinating response to the Khan academy's curriculum. Some of the things he is raising here are faults of programming languages; I'm still against the idea of positional parameters. Khan Academy's curriculum is Android to Brett's iOS: you can copy some of the features, but it isn't a cohesive whole because the ideology was not as thoroughly internalized.
I think the goal was to show how _JavaScript_ (and by extension, Khan Academy) could do the things he's describing. He did show how languages like Smalltalk get something better via a sort of "named parameters".
1. Is Bret Victor now the Linus of cutting-edge programming environments?
2. I don't have enough experience with Light Table or the Khan Academy environment to know whether Khan is just a first step on the way to something like Bret's vision, or more of a diversion. I was fairly impressed with the Khan env in my limited time with it.
3. I HATE telling people they shouldn't speak their mind and/or say what they think is the truth, and I don't think Bret shouldn't have written anything. But it's difficult not to seem ungracious. Josh Resig clearly knows what he's doing, at least in the general sense, and he was gushing with praise for Bret, while this reply basically says John did everything wrong.
If Bret feels that way, I truly believe he should say it, but that doesn't make it fun. This is the essay equivalent of cringe humor I guess. Hilarious/Informative while making you feel bad.
1. I think Victor is the Engelbart of our generation
2. The Academy's program just makes "guess and check" easier, it does not fundamentally present additional information (intermediary computational state) to the user
3. He said that he had to respond because he was cited as the inspiration. It is as if I said "this post is inspired by gfunk911" and then filled it with things that you disagree with.
I don't see this as ungracious. It's not as if he's saying Khan Academy went in the wrong direction. He's just noting improvements that could be made on their current environment. Every new "beginner" programming environment that I've seen has similar flaws. Bret's just pointing them out.
> 1. Is Bret Victor now the Linus of cutting-edge programming environments?
Linus actually implements his solutions to things that he rants about, and releases his code, so that analogy isn't quite right. Bret gives us nice big-picture ideas and leaves the implementation for others.
I think many of the specific ideas mentioned by Bret will quickly fall apart when trying to actually implement something non-trivial. But that's okay, it's useful to have a really inspiring big-picture vision.
Light Table should be an interesting implementation to follow then. It seems to be guided by many of big-picture ideas of Bret Victor but at the same time has to somehow make money as a real product.
Or you could check out his site and notice "tangle - explorable explanations made easy", which is a Javascript library that implements the very sorts of interactions he's talking about.
Not to take away from Bret's ideas, because they're great, but here are my responses.
1. I'd say that there's a significant difference between Bret and Linus. Specifically, when Linus believes that developers need better tools, we get git. When Bret believes developers need better tools, we get... blog posts and videos showing faked functionality. Now, that's not to say this won't change in the future. But, as of right now, Bret is starting to look like an "idea guy" in a world of "doers."
3. The reason I'm irked by this post is that I'm under the impression that Bret was specifically asked by Khan Academy to consult on the project (I'm under this impression because this is what I was told). He chose not to consult. So, all of these things he's pointing out now, he had the opportunity to affect them and change them before they were ever released to the public. He had the opportunity to completely revolutionize how new developers learn and he chose to turn away from it. If he's so passionate about the topic, why would he turn it down? Regardless of the reason, to me, it's a "speak now or forever hold your peace." He had the chance to speak, he chose not to, turning around after the fact and saying what it could have been is him doing too little too late.
Linus needs his RMS and vice versa. Don't frame this as 'empty ideas' vs 'noble industry'. Both are necessary.
There are many reasons, none of which need to be justified to the public, as to why a person may turn down an opportunity.
His article made a short criticism of KA missing the forest for the trees and then provided a very long and detailed analysis of ways to improve it. For free. So everyone benefits.
I suspect the videos in his article were not dummies, mocks or faked, but actual working code. If you visit his website you will see a mind numbing amount of examples and demonstrations in the same vein and length as the article. The effort required to fake these would be truly enormous. Again, his reasons for not releasing code don't need to be justified to us.
The way to read this is not a neg on the Khan academy project but a push into what Bret sees as the absolute solution to the problem being solved. Ie. a new programming language, which is outside the scope of Khans project of teaching.
Bret mentions Rocky's boots at the end of his writeup.
When I was in Grade 5, I taught the kindergarteners how to use logic by running Rocky's Boots on an Apple II. It was an effective way to learn because the use of immediate, graphical feedback. The kids had fun learning.
Its a smartly written piece, but to me this just scratches the surface. A couple of issues:
1. If you are making the conceptual jump from 'text' to 'dynamically annotated text', why not go a step further and just let people draw a rectangle with visual tools entirely (like in Illustrator,Inkscape,etc.) and forget the textual representation?
2. The real difficulty comes with representing things as they may arise through a dynamic program, not with just the 'initialization' stage as this shows. This is where code really really gets complex, and also is much harder to add to with these visual systems.
[EDIT] To clarify further, relating to comments below - The OP's main intent is "how do we redesign programming?" [for all programmers] and my comments relate to this, not just to the use of such techniques for students as a step towards learning traditional code.
1. Because a big part -- perhaps the biggest part -- of "learning to program" is understanding how to move between the picture in your head and the text that makes it real. From both directions: "What does this code do?" and "What code do I need to write to make this happen?"
Purely visual programming are, IMO, noble lies.* You want to start with an environment that echoes the final state, not one that's totally dissimilar.
e.g., training wheels vs. computer bicycle simulator.
*: The exception to this is when you're teaching children ~13 or younger, in my experience. It's always a question of what mental models a student has at their disposal.
2. By the time a student is at this stage, they have more sophisticated, general models the teacher can rely on. In this essay Brett is working in a world where someone might not have the right mental model for assignment, variables, looping, etc.
1)Because that is not learning programming, which is entirely what this essay is about.
1.b) Learning programming is about learning to reason about problems. Not about learning to use different tools.
2) I think I agree that dynamic programs would be more challenging to do this with. On the flip side, this demonstration is so far beyond my reasoning that it doesn't mean much to me. It's all stunning.
A frequent question about the sort of techniques presented here is, "How does this scale to real-world programming?" This is somewhat like asking how the internal combustion engine will benefit horses. The question assumes the wrong kind of change.
Here is a more useful attitude: Programming has to work like this. Programmers must be able to read the vocabulary, follow the flow, and see the state. Programmers have to create by reacting and create by abstracting. Assume that these are requirements. Given these requirements, how do we redesign programming?
Thanks. This was my reading of the OP also and what I was responding to (its about changing programming paradigms for everyone, not just about learning for beginners). I've edited my above post to reflect this.
2)I think the examples with the various timelines, wrapping code in functions or for loops, and replacing constants with variables came a long way in that direction
The timelines are good, but what I mean by 'dynamic' is something with user input that affects objects. Its easy to show how a loop can draw the same shape in lots of different ways, but what happens if the loop might draw different things depending on what the user inputs while the program is running? This gets tricky.
As much as I love Bret Victor's ideas, I feel this is a bit harsh on Khan Academy. There's nothing wrong with criticism, but it shouldn't be your only kind of feedback. Even if Khan Academy did nothing right (which I think is clearly false) they should at least deserve praise for attacking the problem at all, when so many people are content to ignore it.
If you're trying to lead a revolution in programming, witholding praise from your strongest supporters isn't the way to go about it.
What I see is someone who cares very deeply about the message he is trying to get out. He cares so much that when someone falls short while citing his work as inspiration, he feels it's doing the world a disservice not to address the short comings.
Speaking as one of the interns that worked on the project, I don't really feel that this was too harsh.
Had he focused on all the things that were wrong with it and torn it to pieces, I would be inclined to agree, but he's provided a number of very specific ways in which the environment could be improved.
Some of these ideas were considered and not implemented for practical reasons, others were left out due to time constraints, and some we honestly just didn't think of.
On the particular note of practicality, we were trying to make the best thing we could make exist now. I hope that Khan Academy Computer Science in its current state looks laughable in a few years - both compared to what it becomes and compared to what other people have built.
As far as labeling function arguments, I've always used an IDE that supports some kind-of feature that gives me exactly that. In Eclipse, Java (JDT), C/C++ (CDT), Python (PyDev), Go (Goclipse) -- all support the little pop-up box that appears when you type the name of a function and shows docs related to that function. This feature is so crucial, I couldn't use a development environment without it.
He mentions the context being needed for a function call, more than once -- it makes me wonder, doesn't anyone use IDEs? (I don't know vim/emacs are so popular when they provide no context - much more crucial to me than editing power. There's a plug-in for vim that uses ctags to provide context, I hear, but I don't know of many that use it :/)
There's already two comments here about being "harsh" or "ungracious" towards Khan Academy which is ridiculous.
The usual HN article that contains criticisms is usually limited to that. Some rant that took 10 minutes to write and contains nothing constructive.
Bret Victor put an insane amount of time into this (I can only assume) and is truly advancing mindsets about programming tools and learning. We should all be thankful that he put this much effort into a "criticism" piece.
I agree, and would add that Brett Victor is pointing out what he perceives to be valid flaws with the method Khan Academny uses to teach programming (live coding environments, javascript, and processing languages, which other teaching products happen to use as well). He is not criticizing Khan Academy as a whole directly, as the quality or lack thereof of Khan Academy itself is never brought into question or even discussed.
> Brett Victor is pointing out what he perceives to be valid flaws
Where are the numbers? Where's the testing? Where's the proof that his proposed changes are more effective in teaching a new programmer? Validity comes through numbers, proof, and evidence.
This doesn't make sense, because the UI design of the iPhone WAS tested. They did a ton of research into their solutions. They did exactly the type of testing I'm advocating.
I often hear people talk up how the iPhone was never tested in usability labs with non-apple employees. Then I hear that the iPhone was heavily tested.
What actually happened? Does anyone know definitively whether or not it was tested by non-Apple employees before launch?
That's a positivist perspective on research and knowledge. While your perspective on validity might be fitting for quantitative research, for an exploratory expose and kinds of qualitative research some look for other measures of validity and quality. There is an enormous amount of research (papers) on this topic, just look for "qualitative research validity". As it is more a matter of perspective, there often seem some incommensurability creeping into these discussions.
In this case, I believe that a professional/experienced educator who has tried teaching introductory programming can, given their own experiences, relate, understand, and build on the concepts in the article to improve their own teaching and understanding of teaching/learning introductory programming. This is sometimes called communicative generalization (see Smaling: http://www.ualberta.ca/~iiqm/backissues/2_1/html/smaling.htm... ).
For example, to me, as a computer science teacher in high school, I recognize a lot of the issues discussed in the article. Reading the article I am able to link these issues and solutions to my experiences in class and decide to what extent it is credible and trustworthy. Furthermore, and more importantly, I can more easily apply results this kind of research in my daily practice than I can results of (rigorous) quantitative research as that almost always is taken out of context and ' clinically' due to fixing variables that aren't fixed in real life situations (i.e. the classroom, the students (holistic), environment).
I'm well aware of qualitative research, but he doesn't even have that. And, while I agree that you can translate and interpret the major themes, all you have done at that point is recognize that you have a similar problem and have formed a hypothesis that needs to be tested. You cannot assume that your method of fixing the identified problem will actually work until it is tested.
True. On the other hand, it allows the professional/expert to have a good idea if it might work. And, if so, if it is worth testing out or not. In my opinion the value of this kind of research and/or informed opinion pieces is local in scope and should be treated as such. Don't base your educational policy on this kind of research, for that you'd better look for quantitative and, preferably, longitudinal studies.
You can find proof in numerous publications from related fields like cognitive psychology and pedagogy. But don't expect the author to gather them for you. He already did amazing job.
I disagree with the idea that proof of those concepts translates perfectly across all situations. You have to test something before you know if it works or not.
It's amazing how many people have a problem with the idea of testing a solution. I'm simply saying that assumptions need to be challenged and assertions need data to back them up. I'm not saying any of this ideas are inherently wrong, I'm saying they're unproven.
If you down-vote simply because I believe a person should offer proof when they make a claim, you're falling victim to your own biases.
You are not being downvoted because "people have a problem with the idea of testing a solution". You are being downvoted because your tone suggests you categorically dismissed a groundbreaking project because its introductory article wasn't a scholarly work bristling with citations.
"Numbers, proof, evidence" tend to be marks of an excellent article. But an incredible amount of work clearly went into this article, and it presents powerful ideas in a novel and original light; it is highly valuable and fascinating in its own right, even if it is weak in certain areas that academic papers tend to be strong in.
Yes, citations would help tease apart questionable assumptions from reliable ones. Yes, thorough testing would help lend more credence many of the ideas. Yes, the article is imperfect and could be better in a multitude more ways. Still, the article is highly valuable and fascinating.
Have you heard of the term "strawman argument"? That's what you're doing when you say "It's amazing how many people [are completely unreasonable]". Most people are quite reasonable. If a large community is downvoting you, you should strongly consider the possibility that you, in fact, are the one being unreasonable.
First, this isn't Bret's introductory article on this topic. As far as I know, his first talk about this came in January of this year (watch the Inventing on Principle video on Vimeo). Granted, 7-8 months isn't a super long time, but he has never built/tested his ideas, yet asserts them as if they were proven facts.
Also, I know why I'm being down-voted. Bret is an inspiring person. His Vimeo talk, specifically, is very inspiring. He acts on principle, he believes strongly in his ideals, and there are many people who agree with him. So, the people who like Bret are people who align themselves with his ideals. So, when I challenge his vision by asking for data, people who read it feel like I'm challenging them, personally - like I'm challenging their beliefs (because, well, I am - I'm asking them to prove their beliefs). People respond to that kind of challenge in a negative way. It'd be like if you tried to argue the ideas of Steve Jobs with an Apple fan - they're just not going to listen to you, no matter how solid your arguments are.
I, myself, agree strongly with Bret's principles. He's right that developers need better tools and we need a better way to teach programming to people. However, I try to divorce myself from those emotions and still look for facts and evidence. If someone claims A is better than B, I will look for proof, even if my "gut instinct" tells me that they're right. I very well believe Bret could be right, but that doesn't mean we should all just assume he is without evidence.
My point here is that asking someone to give evidence for their arguments is completely acceptable. But, when you challenge the ideas of someone feel emotionally invested in (because their beliefs and ideals are being challenged), you receive negative feedback. Thus, the down-votes. It's actually a very interesting study in how people can be loyal to someone even without evidence of that person being right.
Russel your problem here is that we are looking at something that is about to change technology forever and you are taking the least productive path to discuss it. It's very clear to the majority of us that this is big! It's not tested simply because it's so new and innovative. We are fortunate enough to be the first ones to have this insight shared with. It's now our job to make amazing projects that put it to use and inherently test/prove it. That's what Brett is trying to do here.
I don't think you really do grasp the magic of what he has come up with. Yes you saw his video 8 months ago. But if you did truly grok what he is putting forth, you wouldn't make this generic rebuttal about whether its tested or not. That can be applied to anything.
We come to hacker news to get the kernels of the newest innovation that is happening around the world before anyone else. If you require ideas to be tested before you do anything with it, you will be late to the party. Your loss.
Now Russel can you please stop standing up for this point. It's unfortunately the first thread on this awesome piece and a waste of our energies to discuss.
Lets discuss how we are going to implement this watershed idea for innovation!!
I agree. There is a lot of constructive criticism in the article, and I'm sure Khan Academy would love this kind of feedback to help improve the platform. Hell, even I learned a couple of syntax usages just watching videos of the learning interface!
As Bret Victor says in his essay, live coding is not a new concept and he did not create it.
The current trend in live coding seems to have spawned from a discussion between two computer musicians (Fabrice Mogini and Julian Rohrhuber) in 2001, with masses of related prior art going back to Lisp machines, Self, Smalltalk, corewar etc.
Responsive live programming (not just code reload), which is closer to what Bret Victor is doing here, goes back to various visual languages of the 80s and 90s.
You didn't mention any VPLs. I would throw in a few...ThingLab, AgentSheets, LabView, Prograph, Fabrik, and so on. These were the original live languages.
But why do you think liveness requires visual programming? I see them as pretty much orthogonal.
Separately, when I see "visual programming language" I see "unusual programming language". When language features become normal (like 2D syntax in Python/haskell), then we stop calling them visual. A great deal of visual features are just alternative ways of structuring text, ways of constraining syntax, or ways of constructing high dimensional (and therefore non-visual) graphs. To a large extent, all programming languages are visual.
Why would you call Self a visual language? It has an IDE, but the language is most definitely textual. Its only when you throw in Morphic does the line begin to blur, but you are back to text again if you want to write any code. Many languages we think of as visual are more structured or graphical (graphics baked around text); compare ToonTalk to Scratch! Most languages fall somewhere in a spectrum between heavily visual and heavily textual, but this is my own classification system and there is hardly much consensus on the topic.
Liveness doesn't require visual, of course, but that's where liveness first shows up in history (SketchPad, along with directness). I go into some of the history in my own paper on the topic (http://lamp.epfl.ch/~mcdirmid/mcdirmid07dead.pdf).
I haven't actually used Self, but from reading the paper, discussion of embodiment, tangible objects, and direct manipulation makes it interesting from a visual perspective.
Personally I think all computer languages are textual by definition, and vary in the amount of extra visual support for syntax and more often secondary notation. The Reactable perhaps pushes beyond this limit by making proximity and orientation part of the syntax, but still is basically about composing textual symbols.
If we're doing that thing, I wrote a chapter on this in my thesis :) http://yaxu.org/thesis/
But that aspect of Self comes mostly from Morphic. Anyways, Self/Morphic were a huge inspiration on my own work. There are deeper distinctions between textual and visual; think a Van Goh painting vs. a book by Steven King. They say "a picture is worth a thousands words," but actually, the worths are not very comparable. Text is much better at expressing abstractions than visuals are, which is why most VPLs mixin some text (though their are pure VPLs like SketchPad and ToonTalk).
I skimmed your thesis a few months ago; lots of good work there! But I think we are a bit out of whack on our world views (arts vs. PL), which is why we might not be talking on the same page.
Thanks, I forgot about the DigitalLibrary link :p. If someone is just looking for related work, better to try http://lamp.epfl.ch/~mcdirmid/mcdirmid07dead.pdf (smaller download as it doesn't embed quicktime movies).
Yes we are probably talking past each other here a little, but I enjoy and respect your work on SuperGlue. Not having used Self I don't understand the distinction between it and Morphic.
There clearly is a distinction between textual and visual, but at the same time they support one another: text is made out of pictures, pictures can be described with text (e.g. svg). For me the aim of visual programming language research shouldn't be to disparage or get away from the composition of symbols, but to supplement that with mental imagery. As I see it, mental imagery and language are most valuable in combination.
I'll look into sketchpad and toontalk properly though, "truly" visual language is a fascinating area.
Self is a language, Morphic is a GUI toolkit/framework/library. You can play with Morphic implementation in some Smalltalks (I did it in Pharo) and even in JavaScript: http://www.chirp.scratchr.org/blog/?p=34
Yes. His approach presents a proper critique with a path forward. I love what KA is doing, but it is going to be iterative (I presume), and I'd hope they are listening to well thought out ideas like this.
I just found the analogy of a microwave with blank buttons turned me off as being an unnecessary rhetorical straw man. I know what fill means, and I know what ellipse means, and I know what numbers are. Discovering what those words mean in a different context is not analogous to blank buttons.
The comparison is still shallow. It is regrettable that most programming languages don't support named parameters, but it's fairly trivial to imagine a language and api:
DrawEllipse(x=50, y=25, width=32, height=5)
No real-time rendering and tracing of values required (I hope!). Furthermore, a decent IDE will bring in the method doc blurb, so the programer has a richer context to make an informed decision.
I appreciate the work Brett put into the article and I'm half way pre-convinced myself. At the end I was somewhat disappointed because most of the stuff he talks about is already present in a decent IDE, perhaps in a less polished form, but present nonetheless.
The deeper put-off is that the article seems to advocate not thinking, instead performing random walks using shiny tools. If someone can't think about their code, no amount of visualizations is going to help. That being said, the potential of enhancing one's thinking abilities by properly chosen visualizations is tantalizing, but I don't think the article makes a good case for it and I haven't yet seen a better approach than old school pen and paper.
It'll be interesting to read his subsequent comments on graphics state, as extending this example to draw arbitrary ellipses without coordinate changes could make for a simple visual demonstration of function composition, assuming the goal is not "Learn PostScript in floor(π^e - 1) Days."
Exactly! There are several levels of learning. At the master level one does his job using muscle memory. Graphics help at the early levels, but to be proficient one needs to master the domain. At that level graphics are slowing down the process, not helping it.
Building the right visualisations that hold at master level as well as at novice level holds the promise to expand one logical abilities far beyond what our current ones.
His argument really seems to be that the relationship between the input and output is not obvious, not that you don't understand the words themselves. The blank button is a fitting analogy to the uncertainty of the arguments.
I disagree. You know what buttons are, you know what a microwave is, you know you need to put the food inside and then push some buttons to indicate the time, then press a start button.
The thing that you don't know in the programming example is what those numbers do. I've written processing.js code before and I'd be half-guessing if you asked me what each parameter to elipse() does.
I found myself strongly agreeing with him about fill() specifically. Fill what? It's a verb that performs no action, and is really shorthand for setFillColor, which sets invisible global state. It's not at all obvious from the name what fill() actually does, nor what it's parameters are. Only through previous familiarity with graphics APIs and RGB triplets can I infer the meaning, and in a learning environment it's silly to expect that familiarity.
Here's my issue with the "advancement" that Bret is doing. It's all conjecture. He has no product. He has no users. He has theories. Theories that sound good to you and me, but, ultimately, theories that are untested and unproven. There's no evidence that any of these changes would actually help anyone learn to program any better. Who is to say that a person new to coding wouldn't be overwhelmed by the amount of information Bret's system is asking them to process? There's a pretty strong case for cognitive overload when you have lines of code, different code hints that appear not just over every line, but every function and number, a time bar with many different symbols on it, etc. But, again, no benefits or faults can be found with Bret's proposed approach because it's untested and unproven. Conjecture, hypotheses, and assumptions.
This is where Khan Academy exceeds. They have users. They have real people really trying to learn how to code. This means they can test their assumptions and modify their approach. An imperfect solution delivered today is better than a perfect solution delivered next week.
Khan Academy and Bret Victor are apples and oranges -- they're not even playing the same game. In order to make any major strides, we have to reconcile the need for PRODUCTS, NOW! with the conceptual, exploratory approach taken here.
Real world innovation often makes very small tweaks on proven formulae, whereas bold new ideas can have a long incubation period with seemingly little payoff at first. It's roughly the difference between business and research. While it's not possible to "test" these bare assertions in the sense you imply, they can certainly be argued for and against. And he makes a rather compelling case for it, certainly a more nuanced one than much of the criticism here on HN.
In any event, he's begun sharing some of his code (I believe) and products like Light Table are emerging that appear to draw from very similar inspiration, if not his work directly. It would appear these ideas are gaining some traction.
I disagree that real-world innovation isn't tested, iterated on, and improved. Look at flight and the Wright Brothers. They didn't just run numbers and present ideas. They built prototypes and tested their assumptions. That's what Bret needs to do. He needs to build, test, iterate, and improve upon his ideas.
I think you're misreading my reply. It's not that real world innovation isn't tested and iterated on, quite the opposite. The Wright Brothers are exactly that model and I don't dispute that at all.
What I'm drawing a distinction between is this approach to innovation, which is necessarily iterative and based on incremental improvements to prior art, and another approach which makes larger conceptual leaps and may not have obvious initial practicality. I described these two approaches as being roughly comparable to "business and research", although I admit that's a somewhat crude dichotomy. It is the latter camp that I think Victor falls in.
Both are relevant. For every Wright Brothers you also have a Tim Berners Lee, whose invention was developed in an international research laboratory (not a startup) and was largely ingored by the public for several years. It took the perfect storm of the late 90s Internet boom for the web to develop into the thing we recognize today.
In any case, it's not as though Victor has been doing nothing but writing papers and photoshopping mockups. If you look for them, you can find videos of him giving talks where he is demonstrating real, live software that implements his ideas. He has been refining them in practice for several years now, and others (such as Light Table's Chris Granger) are doing the same. The question is whether they will catch on, and the jury is still out as far as that's concerned.
You're right, I did misread your reply - I originally thought you said it was innovation that took laboratory time. Though, now that you've explained it further, I'm still not sure I agree with the concept. Pure research follows a specific method - you form ideas, form a hypothesis, create an experiment, and test your hypothesis, then revise and test again. There is nothing, ever, that is not tested. Though, you can certainly make the argument that a few of Bret's projects (such as Tangle) work as small-scale experiments for testing his larger ideas. I may actually concede that point; though it is not exactly the big picture he's talking about, it does test the tools he suggests using to achieve that big picture.
And, I have seen the talks where he demonstrates his software. I just wish he would make it available (open source, sell it, whatever) so that others could use it and test it. Wouldn't you like to try out those tools he shows?
you again, Russel ;). come on man. don't you get it: his point is to inspire the likes of us. It's up to you and I to do something with this. If you're not the one up to the task, fine, but stop putting forth a mindset that won't inspire others to do something with this, e.g. TEST IT!
also, the stuff will work. It's dead obvious that it's the future. Take a step back, take a breath, open your mind and stop trying to backup your initial point about "where's the evidence?" and just agree this is magical and some big things will come out of it.
if you can't see that, and can't allow yourself to be wrong for a second, then fine, you're a regular guy--not someone we expect to see making the amazing startups that will put Bret Victor's stuff to use.
You're reading an imagined reply no one is giving. No one is disagreeing that testing ideas is important. Until you test, you never know if there are problems with your ideas that never would have occurred to you no matter hard you thought about them, and that makes testing invaluable.
But sometimes some of the problems that testing would reveal, would also be revealed if you just thought and discussed your ideas more, and would cost vastly less time and effort (which is a very high bar when what you're testing is the efficacy of pedagogy for teaching people programming for the very first time). So presenting your ideas in a compelling way and opening up discussion can also be extremely valuable, and that's exactly what Bret Victor did.
If I were a developer from KA, I would be very grateful for this kind of crticism, no matter how harsh it is. Bret basically did a lot of free research work for them. Some of the ideas are hard to implement, but there are quite a few things that can easily be added to their products.
Inovative ideas are rare and fragile. We should be thankful someone sharing them.
Very powerful and insightful article. I'm not sure if I agree with everything, but it's very inspiring nonetheless and I hope that such a learning environment will be a reality by the time my kids are old enough to think about programming.
There is nothing new here. Before you downvote, this is actually a huge complement to Bret. As he's said before he is inventing on principle not inventing for you to download and install his latest hack. His principles have been consistent (and, imho, right), and this is another view into them. But, if this opened up some huge new insight for you then you haven't been paying close enough attention.
He's always been right and I hope he continues to have patience while he continues his conversation with the world as the world misunderstands his ideas. Unfortunately many people are going to latch on to the examples in his demo movies, and the important parts of the essay will fly over their heads. (The most important part of this essay being, of course, to read Mindstorms.)
All of his creative output points to the same core message: programming today is broken because it is not designed. His various essays, talks, and so on are just alternative "projections" of this thesis. This is a sign of clear thinking.
He's given us all the tools we need to solve this problem. These tools are the mental framework he lays out, not the specific concrete flavor he demoed in his latest talk or essay.
The hard part is not building IDEs or visualizations, it's having the guts to throw everything out and start over again, knowing it's going to be a mess for a long time and it will take years before things start to make sense again. It's convincing yourself that most of what you know is useless and that many of your assumptions are wrong.
Why do that when you can just download the latest whiz bang framework and start hacking shit together taking advantage of the life-long skill you've acquired at firing bullets with a blindfold on?
It's scary to be a newborn again, especially when you're in a place where few have been before (and those that have, are largely not around anymore.)
> His various essays, talks, and so on are just alternative "projections" of this thesis. This is a sign of clear thinking.
See http://vimeo.com/36579366 for a well-known presentation about "inventing on principle". Fast forward to the 10:45 or 23:00 mark to see some interesting examples of this principle he follows.
I don't understand what's wrong with people building on his ideas, taking the subset they think they can implement and, yes, sometimes bastardizing his lofty ideas into quick hacks because something is better than nothing. That's how ideas spread. That's how people get shit done.
Cool demos, but very long article for what I thought he was trying to express. Bunch of thoughts, I enjoy thinking about this, so would love some conversation around any of the points:
If programming is a way of thinking/problem solving, I'm not sure how supplying the context in line teaches you how to think -- as opposed to sitting down and figuring out a problem on your own.
My experience has been that the best way to learn to program is to try something out for yourself. Whether you write it from scratch or use example code to help you get started. It takes a bit of time, but you get better at it.
You need to be able to sit down and spend the time thinking to solve a problem. It's actually quite hard to teach this even in school -- I honestly believe that the main advantage to taking a CS degree over using the internet to learn is that you are actually are forced to group together and work on projects whereas a self study course would not enforce that.
Often the best way to make something more mainstream is to "dumb it down". I don't think it's because most people aren't intelligent enough, it's because it needs to have mass appeal, and therefore needs to interest a wide range of people. Doing this with programming is quite hard if programming is a way of thinking -- how can you "dumb down" a way of thinking to make it more appealing when a lot of programming is dealing with detail.
The thing about flow, if/for statements, is that you tend to master them very quickly. While the visualizations are cool, they have very little usage beyond the first 3 or 4 lessons.
Very interesting examples, but I don't see these examples helping out much more than other sites (I agree that sites that CodeAcademy aren't at all how the press/Mayor Bloomberg/TechCrunch makes them out to be).
I have to disagree ... there are a lot of folks who don't learn well being thrown in at the deep end of "mess around until you understand it", and for whom a Bretian visualization of data would be useful over and over again (especially for bugfinding). And what data needs to be visualized is different for different people; e.g., I can easily visualize most regex, but a lot of people love tools like Rubular because they can't. But I have a lot of trouble intuitively understanding functions like the graphical ones in Bret's examples.
As to "dumbing it down", I think programming can definitely have mass appeal, but there's a lot of "I had to learn closures uphill in the snow both ways" going on among seasoned programmers -- in the same way that current medical doctors often valorize their hours and hours of being on call as residents. A trial by fire may seem useful but in the end you just get a lot of burned people. But unlike MDs, there's no protective guild for programmers ...
As a newbie/wannabe programmer this completely resonates with me. It's not so much 'dumbing down' as about beginning with the end in mind and providing frameworks of thinking - it’s a lot easier to put the pieces of a puzzle together when you know what the picture is before you start.
I agree, there are a lot of people who don't learn that well like that. Visual programming makes it a bit more approachable but whether or not it helps learn beyond the first couple lessons (or is overkill) -- I'm not sure. With a lot of these early concepts I feel like just getting one or two reference points can start a snowball effect. Eg. Tell a philosophy student that object orientation is like Plato's Theory of Forms.
From personal experience however I still would argue that just building something is the surest way to go because it requires you to follow through.
After about 2 years of programming full time, I started to develop a sense of why and when things would go wrong up and down the stack, and I don't really think it's something you can teach. It's something you get from loads of accumulated practice -- eg. Oh that's how indices work in Oracle vs MySQL, dynamic proxies on Groovy methods don't work when called from Java, I just built this but now I see I can refactor and save tons of code next time, what are kwargs in python, etc.
I've tested out little one offs like try mongodb, try redis, or interactive js tutorials, but I forget what I've just learned until I need to build something on my own.
Programmers, by contrast, have traditionally worked in their heads, first imagining the details of a program, then laboriously coding them.
I don't think this describes most real work done by programmers. Rather, what he says we should do,
To enable the programmer to achieve increasingly complex feats of creativity, the environment must get the programmer out of her head, by providing an external imagination where the programmer can always be reacting to a work-in-progress.
Is exactly what most programmers already do. We usually don't have a nice, interactive environment to do so; it's usually a combination of coding, inspecting results, thinking some more about new issues, coding, inspecting results, on up until the problem is solved.
In other words, I think that programmers do tend to solve problems by "pushing paint around." I rarely start with a full appreciation of the problem. But in order to gain that understanding, I have to start trying to solve it, which means starting to write some code, and usually looking at results. As I go through this process, the domain of the problem comes into focus, and I understand better how to solve it.
We already do what Bret is talking about, but not at the granularity he is talking about it. For beginners, I can understand why this difference is important. But I certainly solve problems by pushing paint around.
In general, I think this is a fantastic piece for teaching programming, but I don't think (so far) that all of it carries over to experienced programmers. The examples of having an autocomplete interface that immediately shows icons of the pictures they can draw is great for people just learning. But that's too fine-grained for experienced programmers. Chess masters don't need to be shown the legal moves on a board for a bishop; their understanding of the problem is so innate at that point that they no longer play the game in such elementary terms. Similarly, experienced programmers develop an intuition for what is possible in their programming environment, and will solve problems at a higher level than "I need to draw something." That is the reason we put up with existing programming environments.
And the more abstract your knowledge and understanding, the harder it becomes to visualize. It's relatively easy to visually explain classical mechanics, but not so for quantum mechanics.
Bret has written an amazing article, but the world he inhabits is soooooooooo far away I can't ever imagine getting there in my lifetime. As it stands, programming is barely 2-3 levels of abstraction above shoving bits in registers...sometimes even those few layers are slowing us down and we have to resort to bit shifting operators and native code every once in a while. Whereas he is talking about 20-30 layers of abstraction. He wants to visually depict code, and then visualize functions, visualize data structures, visualize the connections between functions, and actually visualize how the program is running while its running !!! Whereas the practical programmer of 2012 is still buried neck-deep in textual stack-traces.
This is what he is suggesting for learning to program. I don't think he is suggesting that general purpose programming languages be built with these aids ...only an idealized learning language
As a counterexample to shoving bits I can point to two things mentioned by Bret: Morphic and Smalltalk. It just so happens that Morphic (referenced in it's original, Self implementation) was ported to/implemented in Smalltalk (Squeak, Pharo). These are things that exist and work today, I had a pleasure to work with them and have to say they live up to expectations. It's worth trying them out.
Another curious example is Erlang, which lets you update the code responsible for some behavior (I mean of an object) live, without any hassle at all. Then there's ClojureScript, which lets you do the same in browser (I think, don't know it very well).
Foundations of what Bret says are not new, and they are not purely theoretic either. The programmer of 2012 could have been using them for years if he wanted to.
I think Bret is right when he writes that technical possibilities are not a problem - programmers mentality is. Both Lisp and Smalltalk programmers would welcome - I imagine - Bret ideas without a shred of hesitation, because they are working in a similar way since times immemorial. It's just that there are so few of them and Bret wants to influence programming at large - that's why it seems to be difficult or novel.
Bret has written an amazing article, but the world he inhabits is soooooooooo far away I can't ever imagine getting there in my lifetime.
True, he doesn't seem afraid to take big leaps. Brilliant, visionary essay. But I don't think it's unrealistic. In my day to day (game dev) I spent very little time optimizing (and very rarely need to write any sort of bit shifting), but instead a huge chunk of development is spent slingshotting variables through loops into abstracted rendering directives. The hardest part in my job is by far understanding and visualizing program flows in my head. From the essay:
Wait. Wait a minute. Were you trying to answer those questions by doing arithmetic in your head? The computer somehow drew that picture, so the computer must have calculated all those scaleFactors itself. Are you seriously recalculating them in your head?
Sadly, yes, very often I am. Depending on the mood I also use a convoluted combination of notebook + pencil, breakpoints, printf statements, and/or isolating the problem by working on a separate program with the problem simplified. And having aids - like some of the great solutions suggested like the timeline and other state/flow displays - would give me tremendous gain today, if they could be integrated in my toolset. I'll give you that I imagine it being quite a bit more challenging technically to make it work with my C/C++/Objective-C environment, but with other more dynamic languages - like Javascript or as suggested: Clojure - I imagine it to be much easier.
This article is by the way, most likely the best argument I've heard so far for me to move to a higher level language. I like how Bret Victor talks about language (and API - see the autocomplete argument) choices as enablers to better environments; I think we instead usually think of language choice as something that mitigates how hard this work is to begin with with the tools we have (see the time and energy we spend in in this community on language choice). If I had access to tools offering this level of abstraction but had to adopt a language that I didn't particularly like, I think the latter would then become be the least of my concerns.
I don't think that Bret is advocating that this is the way all programming should be. That would be strictly impossible, as some functions have totally non-linear effects on their output, so you couldn't easily connect one to the other with handy arrows and highlighted stuff.
The geometry example is chosen because it's easy to make a mapping between the space of function inputs and visual outputs. And each parameter is independent of each other.
Khan Academy has already implemented some of this for JavaScript, running right in the browser.
Try clicking on the coloration functions to see previews, or sweeping with the mouse to change the values.
As for the more advanced features, many languages exist today which make this quite possible, at least for teaching tools. Even well-commented Java has the kind of typing and documentation culture that would allow you to implement a lot of this today.
Java's documentation, while allowing to document each parameter, still doesn't make the actual result of changing a parameter obvious to a program.
In Bret's video, where hovering over a parameter would show what exactly would change – that requires either machine-readable metadata (i.e. x position of top-left corner of the shape) or additional programming to make available. Javadoc as it exists is just a semi-structured and very thin wrapper around HTML. Not really much a computer could do anything with.
The general problem I see with Bret's approach, while it works very well for restricted programming environments intended for beginners and learners, it falls short for more complex things. But then again, those of us who know half the language framework by heart anyway won't probably need as much guidance or fiddling around. Still, it requires augmenting each and every function with a piece of visualisation code or enough metadata so a development environment can apply the visualisation itself.
he's suggesting we as tech startup entrepreneur type guys go out and imagine the actual solutions that can work across a number of problems based on the examples he's provided.
I'm absolutely so surprised by the lack of imagination here at HN. This is startup ideas gold right here, and none of you seem to have the mental capabilities to dig it out and do something with it. You all want to find something wrong with it.
Ever since I've been tracking Bret Victor, my head has been spinning with tons of practical ideas we can implement today to make us more productive at programming. Light Table is a fantastic start. What's the problem here, guys! You guys just don't want to admit the way you've been coding thus far will soon be obsolete and you've been wasting your time. Yes, your skills will eventually be worthless.
Sidenote: Dan Ingalls seems to praise Victor's work on making programming easier: "How I think computers should work and why, said beautifully. Bret Victor - Inventing on Principle" https://twitter.com/daningalls/status/211630799550812160
Something bothers me about Bret's writings: He is very big picture (which isn't bad by any means), but then he often talks in absolutes without substantiating many of his claims. I suppose speaking in absolutes may be for rhetorical reasons, something wishy washy is probably less persuasive. He certainly has some good ideas and a talent for presenting them though.
>Programming is a way of thinking
If teaching programming is meant to teach a way of thinking, how do we ensure that it transfers to other areas? David Perkins discusses this in his book "Outsmarting IQ" (pg 224, http://books.google.com/books?id=kNbSvy4dQEUC&q=papert#v...). Latin was once thought to be a language that taught people how to think, but the studies didn't show any transfer between learning Latin and other skills. Obviously, programming isn't Latin, and I'm actually in support of the idea of teaching programming as a way to teach thinking skills, but any effort to do is going to have to address the problem of transfer. One way to potentially do this is motivation, I think Vygotsky advocated showing children why they could write (and how they might already be attempting to do so), which would then give them motivation to learn writing. They'd already understand a reason for using it...
> Alan Perlis wrote, "To understand a program, you must become both the machine and the program." This view is a mistake, and it is this widespread and virulent mistake that keeps programming a difficult and obscure art. A person is not a machine, and should not be forced to think like one.
There are cases where this is true, but putting it another way, "A teacher is not a student, and shouldn't be forced to think like one". Any time where a mind is trying to communicate some concept, there has to be some level of dialogue or shared context. One could argue that learning programming could help people understand that others may interpret what they say in a different way (and why that may occur). I think that is a pretty important concept.
Finally, the US military has funded a lot of research on intelligent tutoring systems. One of the things a lot of the successful programs have is a means of getting the user to think more like an expert. The tutor programs often do this in two ways: by prompting the trainee for a response and then getting them to compare to something an expert would do, and by providing feedback/hints (at the right level) as needed. Vygotsky discussed the latter in "Mind in Society", sometimes all a person needs is a little assistance at the right time, and then they'll understand why and how to do something. As far as computer based training systems, "Development of Professional Expertise" has some interesting papers, though it may not be the best source.
A lot of these are really neat ideas, but as I read them, I thought: I'd never have bothered learning programming if all that was available to me was what he's describing. I like the separation between the problem I'm working on and the background information I need so I can understand and solve it; having the problem and background information presented together neither appeals to nor aids me.
That may be because I've grown accustomed to learning from documentation and applying it to my work, but I don't think so; I think there's something deeper going on that may have something to do with the way my mind organizes information. I wonder if Bret Victor, if he were being honest with himself, would prefer to learn his way, or the way he actually did.
Back in the 80's, when you turned your computer on, you were thrown into a programming environment (usually Basic).
I started learning to program at age 8, I just had no idea that the thing I was doing even had a name - I just typed commands and the computer responded (no compile, link, run steps).
Took me a while to figure out what the 'for' did (I was drawing grids one line at a time). I still remember what it felt when I finally figured it out.
An educational programming environment should be installed in every machine. You never know who's going to get interested on it.
I think this article raises some brilliant points, and is very well written, but I also feel that it falls short of the mark Bret was aiming for.
As he himself alludes to, most of what he is teach is not programming - it is individual actions. Just as being taught the meaning of individual words does not teach you to write, being taught what certain functions or statements do does not teach you to program.
What is important is not spelling, but grammar - the shape of a program. His parts on Loops and Functions are better on this - the timeline showing loop instruction order is pretty awesome. However, it's still not perfect. At no point is the user instructed what a 'function' is, and how to use it. How do they know that they should be using it? I agree with other commentators who have suggested that it looks too much like he knows what he is aiming for, and the tool is designed to aid that.
In fact, my strongest criticism is in regards to his rebuttal to Alan Perlis:
> Alan Perlis wrote, "To understand a program, you must become both the machine and the program." This view is a mistake, and it is this widespread and virulent mistake that keeps programming a difficult and obscure art. A person is not a machine, and should not be forced to think like one.
I'm sorry Bret, but Alan is right. You do need to be able to think like a machine. Not necessarily an x86 machine, but an abstract turing machine, or a state machine, or a lambda calculus machine. If you cannot think like the machine, you cannot outwit the machine. This is incredible important if you are relying on the machine to give you feedback on what the system is doing.
In all his examples, very simple things happen, and never go wrong more than drawing in the wrong place. What happens if he starts causing an infinite loop? Or creates cycles in a linked list (and remember, sometimes he may in fact want cycles).
In "Godel, Escher, Bach", Douglas Hofstadter suggests that one of the key ingredients for intelligence is being able to go 'up' a level of abstraction. Bret's comment about a circle being made up of small steps, and hence integrating over a differential function, is part of it. A human can recognise that sequential steps with a consistently changing angle can be viewed as a circle. A human can realise that certain relationships are iterative, recursive, self-referential, in a way that (currently) a computer cannot. This is what needs to be taught, and I fear that what Bret has shown here would not help in that element.
However, it's still going to be a better intro than anything we have currently, so I think that in regards to getting people to dip in and try, it will be a vast help. I just hope that Bret keeps thinking about bridging the chasm between setting down series' of instructions, and programming.
> I'm sorry Bret, but Alan is right. You do need to be able to think like a machine.
I would like to bring in another Alan Perlis quote: "You cannot move from the informal to the formal by formal means."
Programming is the art of formalizing things to a point where they are executable. Executable by what is the point of contention here. I think you are saying (and I somewhat agree) that ultimately your programs and ideas have to execute on a real machine, and as a programmer you need to understand and model that machine.
OTOH, perhaps what Bret is arguing is that we should make better machines and software abstractions.
I dont think it needs to be a real machine in the sense of a physical one, just in the sense of an execution environment.
What worries me about Bret's tools is that it looks like they make it easier for someone to produce something without knowing why. When you learn maths at school, you're normally taught to show your working - getting the answer isn't enough, you need to understand the process. Having so many sliders and timelines to pull around is fine, but at the end of the day we need to teach people functions and variables and recursion and combinators and so forth, and I'm not sure how one does that in this system. In a sense, it is skipping the architecture stage - working not just how to build, but what to build in the first place.
192 comments
[ 3.6 ms ] story [ 211 ms ] threadanother example that is maybe in the neighborhood of a valid response to your reply is like the heap size in java. if i know i what i'm doing and why, i could set it rather high to achieve a goal, but mostly i don't mess with it because its a great reminder i'm making a bigger mess maybe than i should be for whatever problem i'm working with... however, it seems that victor's ideology is that the heap should always know how big it should be given anything i might want to express, and that somehow the halting problem wouldn't apply.
Similarly, the heap size limits in Java are global limits implicit to the system, not to the program being designed. His solution to the larger problem—data growing beyond available resources–might involve providing a better visualization of the data. Something more responsive than the feedback loop provided by heap limits. Getting an OutOfMemoryException doesn't help you to understand how the data grew beyond expectations; it is always followed by a heap dump. What if you could better understand the patterns of allocation during design instead?
1. Is Bret Victor now the Linus of cutting-edge programming environments?
2. I don't have enough experience with Light Table or the Khan Academy environment to know whether Khan is just a first step on the way to something like Bret's vision, or more of a diversion. I was fairly impressed with the Khan env in my limited time with it.
3. I HATE telling people they shouldn't speak their mind and/or say what they think is the truth, and I don't think Bret shouldn't have written anything. But it's difficult not to seem ungracious. Josh Resig clearly knows what he's doing, at least in the general sense, and he was gushing with praise for Bret, while this reply basically says John did everything wrong.
If Bret feels that way, I truly believe he should say it, but that doesn't make it fun. This is the essay equivalent of cringe humor I guess. Hilarious/Informative while making you feel bad.
2. The Academy's program just makes "guess and check" easier, it does not fundamentally present additional information (intermediary computational state) to the user
3. He said that he had to respond because he was cited as the inspiration. It is as if I said "this post is inspired by gfunk911" and then filled it with things that you disagree with.
Linus actually implements his solutions to things that he rants about, and releases his code, so that analogy isn't quite right. Bret gives us nice big-picture ideas and leaves the implementation for others.
I think many of the specific ideas mentioned by Bret will quickly fall apart when trying to actually implement something non-trivial. But that's okay, it's useful to have a really inspiring big-picture vision.
http://worrydream.com/#!/Tangle
1. I'd say that there's a significant difference between Bret and Linus. Specifically, when Linus believes that developers need better tools, we get git. When Bret believes developers need better tools, we get... blog posts and videos showing faked functionality. Now, that's not to say this won't change in the future. But, as of right now, Bret is starting to look like an "idea guy" in a world of "doers."
3. The reason I'm irked by this post is that I'm under the impression that Bret was specifically asked by Khan Academy to consult on the project (I'm under this impression because this is what I was told). He chose not to consult. So, all of these things he's pointing out now, he had the opportunity to affect them and change them before they were ever released to the public. He had the opportunity to completely revolutionize how new developers learn and he chose to turn away from it. If he's so passionate about the topic, why would he turn it down? Regardless of the reason, to me, it's a "speak now or forever hold your peace." He had the chance to speak, he chose not to, turning around after the fact and saying what it could have been is him doing too little too late.
There are many reasons, none of which need to be justified to the public, as to why a person may turn down an opportunity.
His article made a short criticism of KA missing the forest for the trees and then provided a very long and detailed analysis of ways to improve it. For free. So everyone benefits.
I suspect the videos in his article were not dummies, mocks or faked, but actual working code. If you visit his website you will see a mind numbing amount of examples and demonstrations in the same vein and length as the article. The effort required to fake these would be truly enormous. Again, his reasons for not releasing code don't need to be justified to us.
Bret mentions Rocky's boots at the end of his writeup.
When I was in Grade 5, I taught the kindergarteners how to use logic by running Rocky's Boots on an Apple II. It was an effective way to learn because the use of immediate, graphical feedback. The kids had fun learning.
1. If you are making the conceptual jump from 'text' to 'dynamically annotated text', why not go a step further and just let people draw a rectangle with visual tools entirely (like in Illustrator,Inkscape,etc.) and forget the textual representation?
2. The real difficulty comes with representing things as they may arise through a dynamic program, not with just the 'initialization' stage as this shows. This is where code really really gets complex, and also is much harder to add to with these visual systems.
[EDIT] To clarify further, relating to comments below - The OP's main intent is "how do we redesign programming?" [for all programmers] and my comments relate to this, not just to the use of such techniques for students as a step towards learning traditional code.
Purely visual programming are, IMO, noble lies.* You want to start with an environment that echoes the final state, not one that's totally dissimilar.
e.g., training wheels vs. computer bicycle simulator.
*: The exception to this is when you're teaching children ~13 or younger, in my experience. It's always a question of what mental models a student has at their disposal.
2. By the time a student is at this stage, they have more sophisticated, general models the teacher can rely on. In this essay Brett is working in a world where someone might not have the right mental model for assignment, variables, looping, etc.
2) I think I agree that dynamic programs would be more challenging to do this with. On the flip side, this demonstration is so far beyond my reasoning that it doesn't mean much to me. It's all stunning.
A frequent question about the sort of techniques presented here is, "How does this scale to real-world programming?" This is somewhat like asking how the internal combustion engine will benefit horses. The question assumes the wrong kind of change.
Here is a more useful attitude: Programming has to work like this. Programmers must be able to read the vocabulary, follow the flow, and see the state. Programmers have to create by reacting and create by abstracting. Assume that these are requirements. Given these requirements, how do we redesign programming?
2)I think the examples with the various timelines, wrapping code in functions or for loops, and replacing constants with variables came a long way in that direction
The timelines are good, but what I mean by 'dynamic' is something with user input that affects objects. Its easy to show how a loop can draw the same shape in lots of different ways, but what happens if the loop might draw different things depending on what the user inputs while the program is running? This gets tricky.
If you're trying to lead a revolution in programming, witholding praise from your strongest supporters isn't the way to go about it.
What I see is someone who cares very deeply about the message he is trying to get out. He cares so much that when someone falls short while citing his work as inspiration, he feels it's doing the world a disservice not to address the short comings.
Had he focused on all the things that were wrong with it and torn it to pieces, I would be inclined to agree, but he's provided a number of very specific ways in which the environment could be improved.
Some of these ideas were considered and not implemented for practical reasons, others were left out due to time constraints, and some we honestly just didn't think of.
On the particular note of practicality, we were trying to make the best thing we could make exist now. I hope that Khan Academy Computer Science in its current state looks laughable in a few years - both compared to what it becomes and compared to what other people have built.
Imagine a piece of code like
What context or popups can you display for the positional parameters of a function call that is only resolvable at runtime?If you do take some effort, you end up with something like:
http://emacsrocks.com/e11.html
The usual HN article that contains criticisms is usually limited to that. Some rant that took 10 minutes to write and contains nothing constructive.
Bret Victor put an insane amount of time into this (I can only assume) and is truly advancing mindsets about programming tools and learning. We should all be thankful that he put this much effort into a "criticism" piece.
Where are the numbers? Where's the testing? Where's the proof that his proposed changes are more effective in teaching a new programmer? Validity comes through numbers, proof, and evidence.
Some times you have to show people what they want. And then when they see, they would know how awesome things are.
Not all projects are started after research and data. That way many projects would never start.
What actually happened? Does anyone know definitively whether or not it was tested by non-Apple employees before launch?
In this case, I believe that a professional/experienced educator who has tried teaching introductory programming can, given their own experiences, relate, understand, and build on the concepts in the article to improve their own teaching and understanding of teaching/learning introductory programming. This is sometimes called communicative generalization (see Smaling: http://www.ualberta.ca/~iiqm/backissues/2_1/html/smaling.htm... ).
For example, to me, as a computer science teacher in high school, I recognize a lot of the issues discussed in the article. Reading the article I am able to link these issues and solutions to my experiences in class and decide to what extent it is credible and trustworthy. Furthermore, and more importantly, I can more easily apply results this kind of research in my daily practice than I can results of (rigorous) quantitative research as that almost always is taken out of context and ' clinically' due to fixing variables that aren't fixed in real life situations (i.e. the classroom, the students (holistic), environment).
If you down-vote simply because I believe a person should offer proof when they make a claim, you're falling victim to your own biases.
I hope you have a study to backup that assertion.. :p
(Hint: not all knowledge is empirical)
"Numbers, proof, evidence" tend to be marks of an excellent article. But an incredible amount of work clearly went into this article, and it presents powerful ideas in a novel and original light; it is highly valuable and fascinating in its own right, even if it is weak in certain areas that academic papers tend to be strong in.
Yes, citations would help tease apart questionable assumptions from reliable ones. Yes, thorough testing would help lend more credence many of the ideas. Yes, the article is imperfect and could be better in a multitude more ways. Still, the article is highly valuable and fascinating.
Have you heard of the term "strawman argument"? That's what you're doing when you say "It's amazing how many people [are completely unreasonable]". Most people are quite reasonable. If a large community is downvoting you, you should strongly consider the possibility that you, in fact, are the one being unreasonable.
Also, I know why I'm being down-voted. Bret is an inspiring person. His Vimeo talk, specifically, is very inspiring. He acts on principle, he believes strongly in his ideals, and there are many people who agree with him. So, the people who like Bret are people who align themselves with his ideals. So, when I challenge his vision by asking for data, people who read it feel like I'm challenging them, personally - like I'm challenging their beliefs (because, well, I am - I'm asking them to prove their beliefs). People respond to that kind of challenge in a negative way. It'd be like if you tried to argue the ideas of Steve Jobs with an Apple fan - they're just not going to listen to you, no matter how solid your arguments are.
I, myself, agree strongly with Bret's principles. He's right that developers need better tools and we need a better way to teach programming to people. However, I try to divorce myself from those emotions and still look for facts and evidence. If someone claims A is better than B, I will look for proof, even if my "gut instinct" tells me that they're right. I very well believe Bret could be right, but that doesn't mean we should all just assume he is without evidence.
My point here is that asking someone to give evidence for their arguments is completely acceptable. But, when you challenge the ideas of someone feel emotionally invested in (because their beliefs and ideals are being challenged), you receive negative feedback. Thus, the down-votes. It's actually a very interesting study in how people can be loyal to someone even without evidence of that person being right.
I don't think you really do grasp the magic of what he has come up with. Yes you saw his video 8 months ago. But if you did truly grok what he is putting forth, you wouldn't make this generic rebuttal about whether its tested or not. That can be applied to anything.
We come to hacker news to get the kernels of the newest innovation that is happening around the world before anyone else. If you require ideas to be tested before you do anything with it, you will be late to the party. Your loss.
Now Russel can you please stop standing up for this point. It's unfortunately the first thread on this awesome piece and a waste of our energies to discuss.
Lets discuss how we are going to implement this watershed idea for innovation!!
https://vimeo.com/36579366 http://ejohn.org/blog/introducing-khan-cs/
The current trend in live coding seems to have spawned from a discussion between two computer musicians (Fabrice Mogini and Julian Rohrhuber) in 2001, with masses of related prior art going back to Lisp machines, Self, Smalltalk, corewar etc.
But why do you think liveness requires visual programming? I see them as pretty much orthogonal.
Separately, when I see "visual programming language" I see "unusual programming language". When language features become normal (like 2D syntax in Python/haskell), then we stop calling them visual. A great deal of visual features are just alternative ways of structuring text, ways of constraining syntax, or ways of constructing high dimensional (and therefore non-visual) graphs. To a large extent, all programming languages are visual.
Liveness doesn't require visual, of course, but that's where liveness first shows up in history (SketchPad, along with directness). I go into some of the history in my own paper on the topic (http://lamp.epfl.ch/~mcdirmid/mcdirmid07dead.pdf).
Personally I think all computer languages are textual by definition, and vary in the amount of extra visual support for syntax and more often secondary notation. The Reactable perhaps pushes beyond this limit by making proximity and orientation part of the syntax, but still is basically about composing textual symbols.
If we're doing that thing, I wrote a chapter on this in my thesis :) http://yaxu.org/thesis/
[ For the benefit of any others, here's a link to Sean's preprint: http://lamp.epfl.ch/~mcdirmid/mcdirmid07live.pdf ]
I skimmed your thesis a few months ago; lots of good work there! But I think we are a bit out of whack on our world views (arts vs. PL), which is why we might not be talking on the same page.
Thanks, I forgot about the DigitalLibrary link :p. If someone is just looking for related work, better to try http://lamp.epfl.ch/~mcdirmid/mcdirmid07dead.pdf (smaller download as it doesn't embed quicktime movies).
There clearly is a distinction between textual and visual, but at the same time they support one another: text is made out of pictures, pictures can be described with text (e.g. svg). For me the aim of visual programming language research shouldn't be to disparage or get away from the composition of symbols, but to supplement that with mental imagery. As I see it, mental imagery and language are most valuable in combination.
I'll look into sketchpad and toontalk properly though, "truly" visual language is a fascinating area.
"ellipse" and numbers are only hints, just as blank buttons and dials are only hints.
Programmers rely a lot on IDE support now to see the parameters...which is exactly what Bret is talking about!
DrawEllipse(x=50, y=25, width=32, height=5)
No real-time rendering and tracing of values required (I hope!). Furthermore, a decent IDE will bring in the method doc blurb, so the programer has a richer context to make an informed decision.
I appreciate the work Brett put into the article and I'm half way pre-convinced myself. At the end I was somewhat disappointed because most of the stuff he talks about is already present in a decent IDE, perhaps in a less polished form, but present nonetheless.
The deeper put-off is that the article seems to advocate not thinking, instead performing random walks using shiny tools. If someone can't think about their code, no amount of visualizations is going to help. That being said, the potential of enhancing one's thinking abilities by properly chosen visualizations is tantalizing, but I don't think the article makes a good case for it and I haven't yet seen a better approach than old school pen and paper.
Most of the article tries to make the point that if someone can't visualize what their code is doing, they can't think; they can't reason about it.
Building the right visualisations that hold at master level as well as at novice level holds the promise to expand one logical abilities far beyond what our current ones.
The thing that you don't know in the programming example is what those numbers do. I've written processing.js code before and I'd be half-guessing if you asked me what each parameter to elipse() does.
This is where Khan Academy exceeds. They have users. They have real people really trying to learn how to code. This means they can test their assumptions and modify their approach. An imperfect solution delivered today is better than a perfect solution delivered next week.
Real world innovation often makes very small tweaks on proven formulae, whereas bold new ideas can have a long incubation period with seemingly little payoff at first. It's roughly the difference between business and research. While it's not possible to "test" these bare assertions in the sense you imply, they can certainly be argued for and against. And he makes a rather compelling case for it, certainly a more nuanced one than much of the criticism here on HN.
In any event, he's begun sharing some of his code (I believe) and products like Light Table are emerging that appear to draw from very similar inspiration, if not his work directly. It would appear these ideas are gaining some traction.
What I'm drawing a distinction between is this approach to innovation, which is necessarily iterative and based on incremental improvements to prior art, and another approach which makes larger conceptual leaps and may not have obvious initial practicality. I described these two approaches as being roughly comparable to "business and research", although I admit that's a somewhat crude dichotomy. It is the latter camp that I think Victor falls in.
Both are relevant. For every Wright Brothers you also have a Tim Berners Lee, whose invention was developed in an international research laboratory (not a startup) and was largely ingored by the public for several years. It took the perfect storm of the late 90s Internet boom for the web to develop into the thing we recognize today.
In any case, it's not as though Victor has been doing nothing but writing papers and photoshopping mockups. If you look for them, you can find videos of him giving talks where he is demonstrating real, live software that implements his ideas. He has been refining them in practice for several years now, and others (such as Light Table's Chris Granger) are doing the same. The question is whether they will catch on, and the jury is still out as far as that's concerned.
And, I have seen the talks where he demonstrates his software. I just wish he would make it available (open source, sell it, whatever) so that others could use it and test it. Wouldn't you like to try out those tools he shows?
also, the stuff will work. It's dead obvious that it's the future. Take a step back, take a breath, open your mind and stop trying to backup your initial point about "where's the evidence?" and just agree this is magical and some big things will come out of it.
if you can't see that, and can't allow yourself to be wrong for a second, then fine, you're a regular guy--not someone we expect to see making the amazing startups that will put Bret Victor's stuff to use.
But sometimes some of the problems that testing would reveal, would also be revealed if you just thought and discussed your ideas more, and would cost vastly less time and effort (which is a very high bar when what you're testing is the efficacy of pedagogy for teaching people programming for the very first time). So presenting your ideas in a compelling way and opening up discussion can also be extremely valuable, and that's exactly what Bret Victor did.
Inovative ideas are rare and fragile. We should be thankful someone sharing them.
He's always been right and I hope he continues to have patience while he continues his conversation with the world as the world misunderstands his ideas. Unfortunately many people are going to latch on to the examples in his demo movies, and the important parts of the essay will fly over their heads. (The most important part of this essay being, of course, to read Mindstorms.)
All of his creative output points to the same core message: programming today is broken because it is not designed. His various essays, talks, and so on are just alternative "projections" of this thesis. This is a sign of clear thinking.
He's given us all the tools we need to solve this problem. These tools are the mental framework he lays out, not the specific concrete flavor he demoed in his latest talk or essay.
The hard part is not building IDEs or visualizations, it's having the guts to throw everything out and start over again, knowing it's going to be a mess for a long time and it will take years before things start to make sense again. It's convincing yourself that most of what you know is useless and that many of your assumptions are wrong.
Why do that when you can just download the latest whiz bang framework and start hacking shit together taking advantage of the life-long skill you've acquired at firing bullets with a blindfold on?
It's scary to be a newborn again, especially when you're in a place where few have been before (and those that have, are largely not around anymore.)
See http://vimeo.com/36579366 for a well-known presentation about "inventing on principle". Fast forward to the 10:45 or 23:00 mark to see some interesting examples of this principle he follows.
If programming is a way of thinking/problem solving, I'm not sure how supplying the context in line teaches you how to think -- as opposed to sitting down and figuring out a problem on your own.
My experience has been that the best way to learn to program is to try something out for yourself. Whether you write it from scratch or use example code to help you get started. It takes a bit of time, but you get better at it.
You need to be able to sit down and spend the time thinking to solve a problem. It's actually quite hard to teach this even in school -- I honestly believe that the main advantage to taking a CS degree over using the internet to learn is that you are actually are forced to group together and work on projects whereas a self study course would not enforce that.
Often the best way to make something more mainstream is to "dumb it down". I don't think it's because most people aren't intelligent enough, it's because it needs to have mass appeal, and therefore needs to interest a wide range of people. Doing this with programming is quite hard if programming is a way of thinking -- how can you "dumb down" a way of thinking to make it more appealing when a lot of programming is dealing with detail.
The thing about flow, if/for statements, is that you tend to master them very quickly. While the visualizations are cool, they have very little usage beyond the first 3 or 4 lessons.
Very interesting examples, but I don't see these examples helping out much more than other sites (I agree that sites that CodeAcademy aren't at all how the press/Mayor Bloomberg/TechCrunch makes them out to be).
As to "dumbing it down", I think programming can definitely have mass appeal, but there's a lot of "I had to learn closures uphill in the snow both ways" going on among seasoned programmers -- in the same way that current medical doctors often valorize their hours and hours of being on call as residents. A trial by fire may seem useful but in the end you just get a lot of burned people. But unlike MDs, there's no protective guild for programmers ...
From personal experience however I still would argue that just building something is the surest way to go because it requires you to follow through.
After about 2 years of programming full time, I started to develop a sense of why and when things would go wrong up and down the stack, and I don't really think it's something you can teach. It's something you get from loads of accumulated practice -- eg. Oh that's how indices work in Oracle vs MySQL, dynamic proxies on Groovy methods don't work when called from Java, I just built this but now I see I can refactor and save tons of code next time, what are kwargs in python, etc.
I've tested out little one offs like try mongodb, try redis, or interactive js tutorials, but I forget what I've just learned until I need to build something on my own.
I don't think this describes most real work done by programmers. Rather, what he says we should do,
To enable the programmer to achieve increasingly complex feats of creativity, the environment must get the programmer out of her head, by providing an external imagination where the programmer can always be reacting to a work-in-progress.
Is exactly what most programmers already do. We usually don't have a nice, interactive environment to do so; it's usually a combination of coding, inspecting results, thinking some more about new issues, coding, inspecting results, on up until the problem is solved.
In other words, I think that programmers do tend to solve problems by "pushing paint around." I rarely start with a full appreciation of the problem. But in order to gain that understanding, I have to start trying to solve it, which means starting to write some code, and usually looking at results. As I go through this process, the domain of the problem comes into focus, and I understand better how to solve it.
We already do what Bret is talking about, but not at the granularity he is talking about it. For beginners, I can understand why this difference is important. But I certainly solve problems by pushing paint around.
In general, I think this is a fantastic piece for teaching programming, but I don't think (so far) that all of it carries over to experienced programmers. The examples of having an autocomplete interface that immediately shows icons of the pictures they can draw is great for people just learning. But that's too fine-grained for experienced programmers. Chess masters don't need to be shown the legal moves on a board for a bishop; their understanding of the problem is so innate at that point that they no longer play the game in such elementary terms. Similarly, experienced programmers develop an intuition for what is possible in their programming environment, and will solve problems at a higher level than "I need to draw something." That is the reason we put up with existing programming environments.
Another curious example is Erlang, which lets you update the code responsible for some behavior (I mean of an object) live, without any hassle at all. Then there's ClojureScript, which lets you do the same in browser (I think, don't know it very well).
Foundations of what Bret says are not new, and they are not purely theoretic either. The programmer of 2012 could have been using them for years if he wanted to.
I think Bret is right when he writes that technical possibilities are not a problem - programmers mentality is. Both Lisp and Smalltalk programmers would welcome - I imagine - Bret ideas without a shred of hesitation, because they are working in a similar way since times immemorial. It's just that there are so few of them and Bret wants to influence programming at large - that's why it seems to be difficult or novel.
True, he doesn't seem afraid to take big leaps. Brilliant, visionary essay. But I don't think it's unrealistic. In my day to day (game dev) I spent very little time optimizing (and very rarely need to write any sort of bit shifting), but instead a huge chunk of development is spent slingshotting variables through loops into abstracted rendering directives. The hardest part in my job is by far understanding and visualizing program flows in my head. From the essay:
Wait. Wait a minute. Were you trying to answer those questions by doing arithmetic in your head? The computer somehow drew that picture, so the computer must have calculated all those scaleFactors itself. Are you seriously recalculating them in your head?
Sadly, yes, very often I am. Depending on the mood I also use a convoluted combination of notebook + pencil, breakpoints, printf statements, and/or isolating the problem by working on a separate program with the problem simplified. And having aids - like some of the great solutions suggested like the timeline and other state/flow displays - would give me tremendous gain today, if they could be integrated in my toolset. I'll give you that I imagine it being quite a bit more challenging technically to make it work with my C/C++/Objective-C environment, but with other more dynamic languages - like Javascript or as suggested: Clojure - I imagine it to be much easier.
This article is by the way, most likely the best argument I've heard so far for me to move to a higher level language. I like how Bret Victor talks about language (and API - see the autocomplete argument) choices as enablers to better environments; I think we instead usually think of language choice as something that mitigates how hard this work is to begin with with the tools we have (see the time and energy we spend in in this community on language choice). If I had access to tools offering this level of abstraction but had to adopt a language that I didn't particularly like, I think the latter would then become be the least of my concerns.
The geometry example is chosen because it's easy to make a mapping between the space of function inputs and visual outputs. And each parameter is independent of each other.
Khan Academy has already implemented some of this for JavaScript, running right in the browser.
http://www.khanacademy.org/cs/drawing-bonus-rotation/9064481...
Try clicking on the coloration functions to see previews, or sweeping with the mouse to change the values.
As for the more advanced features, many languages exist today which make this quite possible, at least for teaching tools. Even well-commented Java has the kind of typing and documentation culture that would allow you to implement a lot of this today.
In Bret's video, where hovering over a parameter would show what exactly would change – that requires either machine-readable metadata (i.e. x position of top-left corner of the shape) or additional programming to make available. Javadoc as it exists is just a semi-structured and very thin wrapper around HTML. Not really much a computer could do anything with.
The general problem I see with Bret's approach, while it works very well for restricted programming environments intended for beginners and learners, it falls short for more complex things. But then again, those of us who know half the language framework by heart anyway won't probably need as much guidance or fiddling around. Still, it requires augmenting each and every function with a piece of visualisation code or enough metadata so a development environment can apply the visualisation itself.
I'm absolutely so surprised by the lack of imagination here at HN. This is startup ideas gold right here, and none of you seem to have the mental capabilities to dig it out and do something with it. You all want to find something wrong with it.
Ever since I've been tracking Bret Victor, my head has been spinning with tons of practical ideas we can implement today to make us more productive at programming. Light Table is a fantastic start. What's the problem here, guys! You guys just don't want to admit the way you've been coding thus far will soon be obsolete and you've been wasting your time. Yes, your skills will eventually be worthless.
>Programming is a way of thinking
If teaching programming is meant to teach a way of thinking, how do we ensure that it transfers to other areas? David Perkins discusses this in his book "Outsmarting IQ" (pg 224, http://books.google.com/books?id=kNbSvy4dQEUC&q=papert#v...). Latin was once thought to be a language that taught people how to think, but the studies didn't show any transfer between learning Latin and other skills. Obviously, programming isn't Latin, and I'm actually in support of the idea of teaching programming as a way to teach thinking skills, but any effort to do is going to have to address the problem of transfer. One way to potentially do this is motivation, I think Vygotsky advocated showing children why they could write (and how they might already be attempting to do so), which would then give them motivation to learn writing. They'd already understand a reason for using it...
> Alan Perlis wrote, "To understand a program, you must become both the machine and the program." This view is a mistake, and it is this widespread and virulent mistake that keeps programming a difficult and obscure art. A person is not a machine, and should not be forced to think like one.
There are cases where this is true, but putting it another way, "A teacher is not a student, and shouldn't be forced to think like one". Any time where a mind is trying to communicate some concept, there has to be some level of dialogue or shared context. One could argue that learning programming could help people understand that others may interpret what they say in a different way (and why that may occur). I think that is a pretty important concept.
Finally, the US military has funded a lot of research on intelligent tutoring systems. One of the things a lot of the successful programs have is a means of getting the user to think more like an expert. The tutor programs often do this in two ways: by prompting the trainee for a response and then getting them to compare to something an expert would do, and by providing feedback/hints (at the right level) as needed. Vygotsky discussed the latter in "Mind in Society", sometimes all a person needs is a little assistance at the right time, and then they'll understand why and how to do something. As far as computer based training systems, "Development of Professional Expertise" has some interesting papers, though it may not be the best source.
That may be because I've grown accustomed to learning from documentation and applying it to my work, but I don't think so; I think there's something deeper going on that may have something to do with the way my mind organizes information. I wonder if Bret Victor, if he were being honest with himself, would prefer to learn his way, or the way he actually did.
This kind of symbiose between IDE and program code isnt just usefull for teaching, nor large scale software development....
It seems extremely usefull for "explorations" of data. There is a brilliant application idea hiding behind these ideas.
I started learning to program at age 8, I just had no idea that the thing I was doing even had a name - I just typed commands and the computer responded (no compile, link, run steps).
Took me a while to figure out what the 'for' did (I was drawing grids one line at a time). I still remember what it felt when I finally figured it out.
An educational programming environment should be installed in every machine. You never know who's going to get interested on it.
As he himself alludes to, most of what he is teach is not programming - it is individual actions. Just as being taught the meaning of individual words does not teach you to write, being taught what certain functions or statements do does not teach you to program.
What is important is not spelling, but grammar - the shape of a program. His parts on Loops and Functions are better on this - the timeline showing loop instruction order is pretty awesome. However, it's still not perfect. At no point is the user instructed what a 'function' is, and how to use it. How do they know that they should be using it? I agree with other commentators who have suggested that it looks too much like he knows what he is aiming for, and the tool is designed to aid that.
In fact, my strongest criticism is in regards to his rebuttal to Alan Perlis:
> Alan Perlis wrote, "To understand a program, you must become both the machine and the program." This view is a mistake, and it is this widespread and virulent mistake that keeps programming a difficult and obscure art. A person is not a machine, and should not be forced to think like one.
I'm sorry Bret, but Alan is right. You do need to be able to think like a machine. Not necessarily an x86 machine, but an abstract turing machine, or a state machine, or a lambda calculus machine. If you cannot think like the machine, you cannot outwit the machine. This is incredible important if you are relying on the machine to give you feedback on what the system is doing.
In all his examples, very simple things happen, and never go wrong more than drawing in the wrong place. What happens if he starts causing an infinite loop? Or creates cycles in a linked list (and remember, sometimes he may in fact want cycles).
In "Godel, Escher, Bach", Douglas Hofstadter suggests that one of the key ingredients for intelligence is being able to go 'up' a level of abstraction. Bret's comment about a circle being made up of small steps, and hence integrating over a differential function, is part of it. A human can recognise that sequential steps with a consistently changing angle can be viewed as a circle. A human can realise that certain relationships are iterative, recursive, self-referential, in a way that (currently) a computer cannot. This is what needs to be taught, and I fear that what Bret has shown here would not help in that element.
However, it's still going to be a better intro than anything we have currently, so I think that in regards to getting people to dip in and try, it will be a vast help. I just hope that Bret keeps thinking about bridging the chasm between setting down series' of instructions, and programming.
I would like to bring in another Alan Perlis quote: "You cannot move from the informal to the formal by formal means."
Programming is the art of formalizing things to a point where they are executable. Executable by what is the point of contention here. I think you are saying (and I somewhat agree) that ultimately your programs and ideas have to execute on a real machine, and as a programmer you need to understand and model that machine.
OTOH, perhaps what Bret is arguing is that we should make better machines and software abstractions.
What worries me about Bret's tools is that it looks like they make it easier for someone to produce something without knowing why. When you learn maths at school, you're normally taught to show your working - getting the answer isn't enough, you need to understand the process. Having so many sliders and timelines to pull around is fine, but at the end of the day we need to teach people functions and variables and recursion and combinators and so forth, and I'm not sure how one does that in this system. In a sense, it is skipping the architecture stage - working not just how to build, but what to build in the first place.