Bret Victor says we're doing it all wrong, and constructs an existence proof for an environment that supports learning in the way that humans learn things.
We've engaged in a good deal of conversation here about teaching and learning how to program (see: Learning (More About) Programming and Google's Online Course Creation Tool) and debated whether or not it makes sense to introduce the subject to young children (Teaching Kids to Program). Now let's look at the question that lurks behind all of the educational initiatives we have been discussing: what is the best way to convey the concepts of programming to a human being?
Khan Academy's John Resig saw a talk by Bret Victor, Inventing on Principle, and declared that it was the inspiration behind the Academy's new computer science curriculum, which has been widely praised. The problem is that Victor himself doesn't think that what Resig and Khan came up with bears all that much resemblance to the ideas he was trying to convey.
So Victor created an interactive essay, essentially as an answer to Khan, that is like nothing you've seen before. It is peppered with live examples of a (nonexistent) learning environment that would support the principles of human learning, as applied to the discipline of programming in particular. Victor's essay got a bit of notice in the tech press (here's Technology Review) and was bruited about on Hacker News. Victor writes:
A good system is designed to encourage particular ways of thinking, with all features carefully and cohesively designed around that purpose. This essay will present many features! The trick is to see through them -- to see the underlying design principles that they represent, and understand how these principles enable the programmer to think.
The teaching environment Victor envisions is inherently interactive and transparent. Nothing is hidden, and every action by the student produces a visible result in program output. According to Victor, this should hold true even if in the underlying programming language, some things are invisible by nature, such as the value of a default parameter that affects a calculation.
The user should be able to see the state of all important program components, in other words. The flow of the program over time should be visible as well, and Victor provides some striking examples of UI techniques for making the flow transparent.
Another important idea for getting the programmer's creativity out of his or her head -- where it is forced to operate by most modern learning and programming environments -- is "pushing paint around." Victor's simulations show how it is possible to get something on the screen as soon as possible as the user is typing, and offer visual hints as to how what's on screen can be modified. Another UI technique towards the same end is to make all components visible and pickable -- the programming equivalent of the kid who starts playing with Legos by spilling the bucket all over the floor.
Victor has definite ideas about the kinds of programming languages that make good teaching vehicles, and the ones that don't. He favors Seymour Papert's Logo, Alan Kay's Smalltalk, and Bill Atkinson's HyperCard over the current favorites, used by Khan Academy and others: JavaScript and Processing.
Victor's final twist is to assert that the principles he demonstrates are not training wheels -- they don't apply only to learning environments. He asserts (emphasis in the original): "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."
Please go work through Bret Victor's essay. I guarantee you won't look at learning, or programming, in the same way afterwards.