Bret Victor: Learnable Programming

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 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.

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.

>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.