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.
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.
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.
First off, rather than just saying Khan Academy missed the point, Mr. Victor goes over in extreme detail with full examples with ideas on how to do it better.
Second, he really went into some detail about how to think about things. Not just the solutions but ideas and ways of thinking to come up with better solutions.
Third, he's set the bar for critiques higher than I've ever seen. Next time I want to critique something I'm going to feel at least some responsibility to give good and clear examples of both what I think is wrong and what I think would be better with reasons.
Fourth, even if I never write software to help learning programming or help programming advance in general I'll certainly be influenced in my API and system designs by this post.
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.
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.
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!
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.
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.
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.
Sometimes becoming able to hold the 'invisible state' in memory is the skill to learn.
Consider the 'dual N-back' drilling which seems to improve working memory, and then also (by some studies) other testable fluid intelligence. The whole point is holding more and more hidden state in your mind. (To 'show the state' would defeat the purpose of the game.)
Similarly, sometimes struggling with the material is the best way to internalize it.
Consider some studies that show noisy, hard-to-read text (as on a poorly-printed copy) is better remembered by readers than clean typography. Apparently, the effort of making out messy printing also strengthens the recall.
So I'd be interested in seeing comparative testing of the vivid 'Victor' style, and other styles that are more flawed in his analysis, to see which results in the most competence at various followup dates.
We might see that the best approach is some mix: sometimes super-vivid interactivity, for initial explanation or helping students over certain humps, but other times intentionally-obscurantist presentations, to test/emphasize recall and the ability to intuit/impute patterns from minimal (rather than maximal) clues.
Having an environment such as one Victor styled for big systems (big as in millions of lines of code), would prove unfeasible (hell auto-complete has a hiccup when lines start getting into hundreds of thousands).
Those tools he proposes seem to be very beginner and RAD oriented (even if he claims otherwise). I've seen IDE's choke on smaller code bases and this not only has auto-complete, auto-update but also state/frame/time tracking built into. There is no way in hell it can work for existing languages. Maybe some kind of VM that remembers all it's previous states, all function call times, orders and then updates them as programmer changes them.
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.
> 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.
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.
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.
I really enjoyed Bret's article. I don't necessarily agree with all of it but the main argument is quite sound.
Bret writes: "People understand what they can see." which is true for some people but not true for all people. I've got one daughter who is very verbal, one very visual. They learn differently. This in a minor nit though, his exploration of the 'code' / 'example' model is good.
I particularly liked the commentary on something like:
ellipse(60, 50, 50, 100)
\ \ \ \
\ \ \ +- What does this mean?
\ \ +----- Or this,
\ +-------- Or this,
+----------- Or this?
(We'll see how that comes out in the formatting)
TOPS-20 had a really interesting macro language for programming commands, it was the inspiration for a lot of self-describing command line interfaces like the ones made popular on Cisco gear. Basically you could write it like
DRAW ellipse AT X=60 Y=50 THAT IS 50 HIGH, 100 WIDE
But all of the 'fill text' was really unnecessary for the parser so if you wrote:
ellipse 60 50 50 100
It would be just as intelligible. The point being that the training wheels got out of your way when ever you wanted them too, and if you were ever stuck you could type ? and it would tell you what your choices were.
Not enough learning environments put this sort of dynamically sizing help into the system where it is needed such that it helps novices and doesn't slow down experts.
In some languages like perl, there's a named parameter form that's becoming more common. If I were to rewrite the example in perl, it would look like this:
ellipse(x=>60, y=>50, height=>50, width=>100);
Yes, it is more typing, but you don't need fancy auto-complete to give you hints when reading.
There's also nothing from stopping us from making a "training wheels" interface in javascript:
Ah, but doesn't this have the same problems all NLP systems have? It gives illusion of flexibility that gets shattered every time user allows himself to believe in it. What if I prefer to write them in different order? Or if some version of named parameters is in use, what if I like some other synonym for height? Strict syntax is a good thing as long as it is also brittle.
Now, an IDE that generates a training text like that on the fly and allows you to fill in the values without actually storing the training text would be nice. Something like intellisence popups, but inline and expanded.
The problem with making the "training wheels" optional, is people will leave them off. All of a sudden your code is not useful or readable to anyone unfamiliar with your code. Even yourself. Sure you might know what the parameters in `ellipse 60 50 50 100` do right now, but what if you haven't worked on drawing code for 6 months?
It seems to me like what he's talking about is less a bicycle with training wheels than it is a self-balancing segway. A bicycle with training wheels is annoying to anyone but a beginner... what he's talking about is something that isn't annoying to a pro... even if they don't lean on it as much.
As far as learning is concerned, I think this is a wonderful idea. I say this in part because I myself learned on Logo before I taught people everything from Java to Scheme, and even the simplest visualization tools could help immeasurably. For example, we had a tool called the Replacement Modeller that would visualize evaluation and substitution in pure-functional Scheme snippets, which was great for stepping through complex code and showing a student what was happening, and it was rocks-and-sticks next to the things Victor is proposing here.
I'm interested, though, in what the ramifications are for advanced, complex programming. I am personally a Haskeller, and advanced Haskell regularly deals with incredibly abstract, difficult-to-visualize structures. Monads are infamous in this regard, and monads are embarrassingly trivial next to, say, comonads or iteratees. I have difficulty imagining this sort of model expanded beyond elementary visualization techniques, and certainly cannot imagine how one might represent and interact with these code structures.
Victor seems to believe that visual, interactive systems such as these should become standard for all programmers, c.f. the section 'These Are Not Training Wheels.' The idea seems powerful, but: how?
I'm toying in build a new language (more in the "find ideas" than really doing it), and tough: Why I can't have events on functions? ie: Why I can't attach listener to the entry/exit of a function, in a transparent way (from https://gist.github.com/3777791, where is still ugly as hell):
def startDef:
self.cache['start'] = now
def endDef:
performance.register(self.function.__name,'time', now - self.cache['start'])
hook(sample,pre = startDef, post = endDef)
Now with that ability, is possible to log with a graph the flow of the data in the program, in realtime. Still will lack the instant play but is a good start...
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.
This is nothing but prejudice, and, ironically, it is contrary to how we work as human beings. In any field, we celebrate sympathy between an expert and the matter of his or her expertise. If we say that a pianist "becomes" the piano; we do not regret the dehumanization of the pianist. If we say that a rider has learned to "think like" a horse, we do not believe the rider has become less intelligent thereby. If we say a fireman thinks like a fire, it's a compliment, not a statement that his mind can be modeled by simple physical laws. Sympathy is an expansion of one's understanding, not a reduction. For example, the wonderfully named "Mechanical Sympathy" is a blog that will improve your grasp of the connection between performance and hardware architecture without dehumanizing you one bit. Heck, here's a guy who says he has to "think like a maggot," and he doesn't seem ashamed or degraded in the least: http://www.bbc.co.uk/news/uk-england-17700116
Is it reasonable to ask a programmer to think like a machine? Of course. We find it natural and admirable for people working with pianos, horses, fires, or maggots to identify themselves with the subject of their expertise, and there's no reason why we should make an exception for computers. It's true that when it comes to usability, for a long time we've known we have to take very strong negative emotions into account. It isn't an overstatement to say that some people loath and fear computers. However, as a general principle, it seems to me that any educational philosophy grounded in the assumption that the learners find the subject uniquely distasteful or unworthy is unlikely to be effective. If someone learning programming finds computers so inherently distasteful that they are put off by the idea of achieving a more intimate sympathy with them, then the long-term plan should be to overcome their aversion, not to try to teach them to understand and control something they are fundamentally alienated from. Human beings just don't work that way. Alienation and understanding don't mix.
Computers are programmable. Pianos, horses, fires are not. Some (lower level) tasks absolutely require the programmer to think like a machine. Most do not.
We have the power to make it easier for ourselves, and lower the barrier of entry for others. They might develop that sympathy you speak of later on, but there's no reason why that should be a prerequisite.
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.)
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.
> 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.
If such an environment ever existed, it would be amazing.
But I can't think of any way that such an environment could exist without having to program a new environment for every problem. Not from scratch, of course, a lot of core concepts could be abstracted out, but even with all the abstractions in place, and all the libraries presenting a standard interface, I'd imagine few thousand lines for the features described just for the environment which is limited to 2d graphics.
You could need a new "plugin" for the environment for every different kind of problem. You would run into two problems: first, how could these be composed in a usable way, you don't usually solve problems that are just about 2d graphics or just about parsing text, you're working with 4 or 5 of these at once; second, the whole idea behind this is to enhance imagination, but doesn't the dependence on existing tooling to help you solve a specific set of problems limit you not by the extent of your imagination, but by the power of your tools? Currently our imaginations aren't getting much help, but they're our only limit (that and the speed of the computer of course).
I'd rather the only real limit to what I can design be myself, not my tools.
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.
> A live-coding Processing environment addresses neither of these goals. JavaScript and Processing are poorly-designed languages that support weak ways of thinking, and ignore decades of learning about learning. And live coding, as a standalone feature, is worthless.
Woah come on Bret, we're getting there give them a break! I distinctly remember that this was the work of a couple of interns with the help of Resig.
A couple of things - I still don't have live coding for the vast majority of my programming environments - so that little text box is about 10x better than the vim/eclipse + run loop with print statements that most of us use.
Second javascript is brilliant - lazy ways of thinking are brilliant - you will not believe how motivating it is to just get shit on the screen as a learner. I myself have wasted inordinate amounts of time setting up compilers, interpreters, environments, graphics/audio etc. when all I want to do is bloody program the thing in my head. Who cares where the files are? Who cares where the images are? The environment should be designed to get out of my way - not the other way around.
Most importantly of all - javascript is the most forgiving language I have ever seen - and this is gold. There's a reason Google started with python, Twitter with rails, and Facebook started with PHP - no one gives a shit about "strict thinking" or "brutal languages" - that stuff should come way - way later when you actually need it.
Strict languages for learners are a case of premature optimisation. My little brother absolutely loves the new Khan Academy coding environment/system because of the fact that it isn't strict.
This is really neat. It does paint a far too optimistic picture, however. The mini-IDEs that he presents are highly problem specific. That's great when you are teaching programming and you control exactly what the problem is and what the IDE does for that problem. But this is presented as a solution for programming in general (see the section "These are not training wheels", e.g. "Maybe we don't need a silver bullet. We just need to take off our blindfolds to see where we're firing.").
The control flow visualisation works great for toy problems when learning programming, but quickly breaks down in the real world. The iteration counts become too big to see anything. If you are working with functions that can be sensibly plotted when the iteration counts get too large that's great, but 99.9% of code is not like that. You're working with billions of seemingly random integers, or with strings, or even more complex data structures. How are you going to visualize that over time? Probably for each problem you can come up with an adequate mini-IDE, but that doesn't really help because implementing that mini-IDE is more work than solving the original problem in the first place. To make this practical you need general purpose tools with easily customisable visualisations (and IDE interactions in general).
Another example is the UI for the bouncing ball. Displaying the trajectory of the ball faded out like that works great for an animation or a very simple game where a single thing change over time, but how about a more complicated game where the entire screen changes every frame (as in most 3d games and even side scrollers). That's not even considering GUI applications!
This type of visualisation is also highly specific to single imperative loops, yet the author agues against that. How do you visualize a program structured functionally? You can try to do something with an unfolded expression tree, but that quickly gets out of hand too.
All the examples in the post fall into the category "drawing a very simple 2d scene with at most a singly nested loop". How big a subset of the field of programming is that? It's also no accident that the author chose that subset: it is the easiest case for this kind of visual interaction. Don't fall into the trap of extrapolating the results to all of programming, and thinking we are almost there and the problems lies just in implementing this kind of IDE. While this is superb work, 99% is still to be discovered.
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.
This article is quite thought-provoking. However, I disagree with the notion that there's something wrong with "unlabeled" programs outside a learning environment. To learn a language, you need to associate unfamiliar words with concepts. A text written in French isn't broken because the words aren't all labelled with their English translations, much as that might be a nice UI for people learning the language. Nor do you think in a language by translating each word into English first.
We do a lot of programming using API's we're not yet fluent in (and may never be), and that's why IDE's can be so helpful and this isn't black and white. But at some point you do need to get some core concepts into your head and communicate them in a reasonably terse language.
"In Processing... There are no strong metaphors that allow the programmer to translate her experiences as a person into programming knowledge. The programmer cannot solve a programming problem by performing it in the real world."
We all learn to read at a very early stage in our lives. What is a real world metaphor for a letter? For a syllable? Or, taking an example from the article, what's the metaphor for a timeline? Or for time itself for that matter. I'm sceptical that having a metaphor matters that much.
Also, I yet have to see any evidence that kids who start with Smalltalk learn programming faster than those who start with basic, or pascal, or anything else. There is frustratingly almost no case studies in this area.
Imagine if the microwave encouraged you to randomly
hit buttons until you figured out what they did.
I don't have to imagine, because that's precisely what I did when I was a child. As a result, at 6 years old I was the only one in my family able to configure a video player.
Of course, I've lost my patience since then and I rely more and more on already known concepts, but that's one reason why children learn faster than grownups - because they start with a blank slate, they have no preconceptions, no biases, have no fear of experiments and of failure. You only need to watch a child learn how to ride a bike, then compare it with a grown-up doing the same.
Parents are also privileged to watch their children learn how to use everyday language. The most marvelous thing happens right before your eyes - as your child does not need to learn the grammar rules, or to read from a dictionary or to take lessons from a tutor. And during this time all they are doing is listen, then trying out words by themselves to see how you behave.
And you really can't compare a microwave with a programming language. A microwave is just a stupid appliance with a bunch of buttons for controlling a state machine. A programming language on the other hand is a language that can describe anything. And I don't know what the best method is for teaching programming, but we could probably take some hints from people that learn foreign languages, especially children.
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.
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.
[+] [-] scott_s|13 years ago|reply
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.
[+] [-] dxbydt|13 years ago|reply
[+] [-] alisey|13 years ago|reply
[+] [-] greggman|13 years ago|reply
First off, rather than just saying Khan Academy missed the point, Mr. Victor goes over in extreme detail with full examples with ideas on how to do it better.
Second, he really went into some detail about how to think about things. Not just the solutions but ideas and ways of thinking to come up with better solutions.
Third, he's set the bar for critiques higher than I've ever seen. Next time I want to critique something I'm going to feel at least some responsibility to give good and clear examples of both what I think is wrong and what I think would be better with reasons.
Fourth, even if I never write software to help learning programming or help programming advance in general I'll certainly be influenced in my API and system designs by this post.
Thank you Mr. Victor
[+] [-] adambratt|13 years ago|reply
[+] [-] bretthopper|13 years ago|reply
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.
[+] [-] AdamFernandez|13 years ago|reply
[+] [-] chj|13 years ago|reply
Inovative ideas are rare and fragile. We should be thankful someone sharing them.
[+] [-] marcioaguiar|13 years ago|reply
https://vimeo.com/36579366 http://ejohn.org/blog/introducing-khan-cs/
[+] [-] everlost|13 years ago|reply
[+] [-] russelluresti|13 years ago|reply
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.
[+] [-] mattmcknight|13 years ago|reply
[+] [-] yaxu|13 years ago|reply
[+] [-] joelhooks|13 years ago|reply
[+] [-] gojomo|13 years ago|reply
Sometimes becoming able to hold the 'invisible state' in memory is the skill to learn.
Consider the 'dual N-back' drilling which seems to improve working memory, and then also (by some studies) other testable fluid intelligence. The whole point is holding more and more hidden state in your mind. (To 'show the state' would defeat the purpose of the game.)
Similarly, sometimes struggling with the material is the best way to internalize it.
Consider some studies that show noisy, hard-to-read text (as on a poorly-printed copy) is better remembered by readers than clean typography. Apparently, the effort of making out messy printing also strengthens the recall.
So I'd be interested in seeing comparative testing of the vivid 'Victor' style, and other styles that are more flawed in his analysis, to see which results in the most competence at various followup dates.
We might see that the best approach is some mix: sometimes super-vivid interactivity, for initial explanation or helping students over certain humps, but other times intentionally-obscurantist presentations, to test/emphasize recall and the ability to intuit/impute patterns from minimal (rather than maximal) clues.
[+] [-] Ygg2|13 years ago|reply
Those tools he proposes seem to be very beginner and RAD oriented (even if he claims otherwise). I've seen IDE's choke on smaller code bases and this not only has auto-complete, auto-update but also state/frame/time tracking built into. There is no way in hell it can work for existing languages. Maybe some kind of VM that remembers all it's previous states, all function call times, orders and then updates them as programmer changes them.
[+] [-] gfunk911|13 years ago|reply
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.
[+] [-] aaronblohowiak|13 years ago|reply
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.
[+] [-] paulhodge|13 years ago|reply
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.
[+] [-] russelluresti|13 years ago|reply
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.
[+] [-] AnIrishDuck|13 years ago|reply
[+] [-] ChuckMcM|13 years ago|reply
Bret writes: "People understand what they can see." which is true for some people but not true for all people. I've got one daughter who is very verbal, one very visual. They learn differently. This in a minor nit though, his exploration of the 'code' / 'example' model is good.
I particularly liked the commentary on something like:
(We'll see how that comes out in the formatting)TOPS-20 had a really interesting macro language for programming commands, it was the inspiration for a lot of self-describing command line interfaces like the ones made popular on Cisco gear. Basically you could write it like
But all of the 'fill text' was really unnecessary for the parser so if you wrote: It would be just as intelligible. The point being that the training wheels got out of your way when ever you wanted them too, and if you were ever stuck you could type ? and it would tell you what your choices were.Not enough learning environments put this sort of dynamically sizing help into the system where it is needed such that it helps novices and doesn't slow down experts.
[+] [-] teek|13 years ago|reply
There's also nothing from stopping us from making a "training wheels" interface in javascript:
[+] [-] UnFleshedOne|13 years ago|reply
Now, an IDE that generates a training text like that on the fly and allows you to fill in the values without actually storing the training text would be nice. Something like intellisence popups, but inline and expanded.
[+] [-] kennywinker|13 years ago|reply
It seems to me like what he's talking about is less a bicycle with training wheels than it is a self-balancing segway. A bicycle with training wheels is annoying to anyone but a beginner... what he's talking about is something that isn't annoying to a pro... even if they don't lean on it as much.
[+] [-] andolanra|13 years ago|reply
I'm interested, though, in what the ramifications are for advanced, complex programming. I am personally a Haskeller, and advanced Haskell regularly deals with incredibly abstract, difficult-to-visualize structures. Monads are infamous in this regard, and monads are embarrassingly trivial next to, say, comonads or iteratees. I have difficulty imagining this sort of model expanded beyond elementary visualization techniques, and certainly cannot imagine how one might represent and interact with these code structures.
Victor seems to believe that visual, interactive systems such as these should become standard for all programmers, c.f. the section 'These Are Not Training Wheels.' The idea seems powerful, but: how?
[+] [-] mamcx|13 years ago|reply
def startDef: self.cache['start'] = now
def endDef: performance.register(self.function.__name,'time', now - self.cache['start'])
hook(sample,pre = startDef, post = endDef)
Now with that ability, is possible to log with a graph the flow of the data in the program, in realtime. Still will lack the instant play but is a good start...
[+] [-] dkarl|13 years ago|reply
This is nothing but prejudice, and, ironically, it is contrary to how we work as human beings. In any field, we celebrate sympathy between an expert and the matter of his or her expertise. If we say that a pianist "becomes" the piano; we do not regret the dehumanization of the pianist. If we say that a rider has learned to "think like" a horse, we do not believe the rider has become less intelligent thereby. If we say a fireman thinks like a fire, it's a compliment, not a statement that his mind can be modeled by simple physical laws. Sympathy is an expansion of one's understanding, not a reduction. For example, the wonderfully named "Mechanical Sympathy" is a blog that will improve your grasp of the connection between performance and hardware architecture without dehumanizing you one bit. Heck, here's a guy who says he has to "think like a maggot," and he doesn't seem ashamed or degraded in the least: http://www.bbc.co.uk/news/uk-england-17700116
Is it reasonable to ask a programmer to think like a machine? Of course. We find it natural and admirable for people working with pianos, horses, fires, or maggots to identify themselves with the subject of their expertise, and there's no reason why we should make an exception for computers. It's true that when it comes to usability, for a long time we've known we have to take very strong negative emotions into account. It isn't an overstatement to say that some people loath and fear computers. However, as a general principle, it seems to me that any educational philosophy grounded in the assumption that the learners find the subject uniquely distasteful or unworthy is unlikely to be effective. If someone learning programming finds computers so inherently distasteful that they are put off by the idea of achieving a more intimate sympathy with them, then the long-term plan should be to overcome their aversion, not to try to teach them to understand and control something they are fundamentally alienated from. Human beings just don't work that way. Alienation and understanding don't mix.
[+] [-] szx|13 years ago|reply
We have the power to make it easier for ourselves, and lower the barrier of entry for others. They might develop that sympathy you speak of later on, but there's no reason why that should be a prerequisite.
[+] [-] gfodor|13 years ago|reply
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.)
[+] [-] stdbrouw|13 years ago|reply
[+] [-] jschulenklopper|13 years ago|reply
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.
[+] [-] adrusi|13 years ago|reply
But I can't think of any way that such an environment could exist without having to program a new environment for every problem. Not from scratch, of course, a lot of core concepts could be abstracted out, but even with all the abstractions in place, and all the libraries presenting a standard interface, I'd imagine few thousand lines for the features described just for the environment which is limited to 2d graphics.
You could need a new "plugin" for the environment for every different kind of problem. You would run into two problems: first, how could these be composed in a usable way, you don't usually solve problems that are just about 2d graphics or just about parsing text, you're working with 4 or 5 of these at once; second, the whole idea behind this is to enhance imagination, but doesn't the dependence on existing tooling to help you solve a specific set of problems limit you not by the extent of your imagination, but by the power of your tools? Currently our imaginations aren't getting much help, but they're our only limit (that and the speed of the computer of course).
I'd rather the only real limit to what I can design be myself, not my tools.
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] paulclinger|13 years ago|reply
[deleted]
[+] [-] aaronblohowiak|13 years ago|reply
[+] [-] wmf|13 years ago|reply
[+] [-] Evbn|13 years ago|reply
[+] [-] confluence|13 years ago|reply
Woah come on Bret, we're getting there give them a break! I distinctly remember that this was the work of a couple of interns with the help of Resig.
A couple of things - I still don't have live coding for the vast majority of my programming environments - so that little text box is about 10x better than the vim/eclipse + run loop with print statements that most of us use.
Second javascript is brilliant - lazy ways of thinking are brilliant - you will not believe how motivating it is to just get shit on the screen as a learner. I myself have wasted inordinate amounts of time setting up compilers, interpreters, environments, graphics/audio etc. when all I want to do is bloody program the thing in my head. Who cares where the files are? Who cares where the images are? The environment should be designed to get out of my way - not the other way around.
Most importantly of all - javascript is the most forgiving language I have ever seen - and this is gold. There's a reason Google started with python, Twitter with rails, and Facebook started with PHP - no one gives a shit about "strict thinking" or "brutal languages" - that stuff should come way - way later when you actually need it.
Strict languages for learners are a case of premature optimisation. My little brother absolutely loves the new Khan Academy coding environment/system because of the fact that it isn't strict.
[+] [-] jules|13 years ago|reply
The control flow visualisation works great for toy problems when learning programming, but quickly breaks down in the real world. The iteration counts become too big to see anything. If you are working with functions that can be sensibly plotted when the iteration counts get too large that's great, but 99.9% of code is not like that. You're working with billions of seemingly random integers, or with strings, or even more complex data structures. How are you going to visualize that over time? Probably for each problem you can come up with an adequate mini-IDE, but that doesn't really help because implementing that mini-IDE is more work than solving the original problem in the first place. To make this practical you need general purpose tools with easily customisable visualisations (and IDE interactions in general).
Another example is the UI for the bouncing ball. Displaying the trajectory of the ball faded out like that works great for an animation or a very simple game where a single thing change over time, but how about a more complicated game where the entire screen changes every frame (as in most 3d games and even side scrollers). That's not even considering GUI applications!
This type of visualisation is also highly specific to single imperative loops, yet the author agues against that. How do you visualize a program structured functionally? You can try to do something with an unfolded expression tree, but that quickly gets out of hand too.
All the examples in the post fall into the category "drawing a very simple 2d scene with at most a singly nested loop". How big a subset of the field of programming is that? It's also no accident that the author chose that subset: it is the easiest case for this kind of visual interaction. Don't fall into the trap of extrapolating the results to all of programming, and thinking we are almost there and the problems lies just in implementing this kind of IDE. While this is superb work, 99% is still to be discovered.
[+] [-] th0ma5|13 years ago|reply
[+] [-] aaronblohowiak|13 years ago|reply
[+] [-] skybrian|13 years ago|reply
We do a lot of programming using API's we're not yet fluent in (and may never be), and that's why IDE's can be so helpful and this isn't black and white. But at some point you do need to get some core concepts into your head and communicate them in a reasonably terse language.
[+] [-] perfunctory|13 years ago|reply
We all learn to read at a very early stage in our lives. What is a real world metaphor for a letter? For a syllable? Or, taking an example from the article, what's the metaphor for a timeline? Or for time itself for that matter. I'm sceptical that having a metaphor matters that much.
Also, I yet have to see any evidence that kids who start with Smalltalk learn programming faster than those who start with basic, or pascal, or anything else. There is frustratingly almost no case studies in this area.
[+] [-] milkshakes|13 years ago|reply
[+] [-] bad_user|13 years ago|reply
Of course, I've lost my patience since then and I rely more and more on already known concepts, but that's one reason why children learn faster than grownups - because they start with a blank slate, they have no preconceptions, no biases, have no fear of experiments and of failure. You only need to watch a child learn how to ride a bike, then compare it with a grown-up doing the same.
Parents are also privileged to watch their children learn how to use everyday language. The most marvelous thing happens right before your eyes - as your child does not need to learn the grammar rules, or to read from a dictionary or to take lessons from a tutor. And during this time all they are doing is listen, then trying out words by themselves to see how you behave.
And you really can't compare a microwave with a programming language. A microwave is just a stupid appliance with a bunch of buttons for controlling a state machine. A programming language on the other hand is a language that can describe anything. And I don't know what the best method is for teaching programming, but we could probably take some hints from people that learn foreign languages, especially children.
[+] [-] comatose_kid|13 years ago|reply
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.
[+] [-] brador|13 years ago|reply