Good essay by Bret Victor, but he’s got one thing wrong in the opening chapter

I read Bret Victor’s latest essay, it’s very good. But he started off by refuting a quote of Alan Perlis which goes like this: “To understand a program, you must become both the machine and the program.”, and Bret thinks this is a mistake. I think Bret got that argument wrong, he is misunderstanding the issue that Perlis is addressing.

I read Bret Victor’s latest essay, it’s very good. But he started off by refuting one argument, which I think he’s got the wrong end of.

In the opening section Bret quotes Alan Perlis as saying that “To understand a program, you must become both the machine and the program.”. Then Bret adds in the same sentence:

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

Yes, it is quite obvious that people aren’t machines, but that is besides the point. I think Bret got that argument completely wrong for a simple reason: if two persons don’t speak each other’s language, there is no common ground to hold meaningful discourse on. When a person writes a program, they are effectively engaging in a future discourse with a computing environment (computers, operating programs, and everything that defines the operating context of the program being written). So if this person has no idea what his/her writing (code here) could mean to the computer it is destined to run on, then the outcome is uncertain and bad things are more likely to happen. What makes programming difficult, to learn and/or practice, is the fact that people are dealing with infinitely more complexity than they think or assume that they are.

Alan Perlis wasn’t trying to be pedantic, which some people clearly are when they drivel on esoteric things in order to mystify others as a way to show off their skills and expertise. That is not what Alan Perlis was doing, Alan was simply saying that unless someone is truly aware of what  they are getting themselves yourself into, hence the metaphor of embodying those things, that person can be almost certain that bad things will happen. And that, I think was a sound judgment. Perhaps the prose could be different and more elaborate, elegant in the way that Bret himself writes, but that says nothing about the real content.

Learning about programming is difficult because the student (let’s call it that) has no idea what to expect. Some programming languages become popular because they simplify and reduce the amount of concept that the student needs to learn. Other programming environment, C language for example, are complex because virtually on each line one could be easily making several mistakes and it takes a long time to learn them all and become proficient with it.

So, the programming student is typically going to start off on a bias that is determined by the context where the learning is occurring. If the teacher isn’t good, the teaching will suffer and eventually that student will go off and spread misunderstanding further on. The complexity is compounded by all the human factors that typically add up over time. This isn’t anybody’s fault per se. It is a wicked problem, it starts off as a problem of appreciating the true mileage that lies ahead and how one’s own lung and leg capacity would fare in the journey, to use a sporting metaphor. I think that is What Alan Perlis was probably referring to and I think he was spot on. Bret is wrong in this case.

Having said the above, Bret’s essay is quite brilliant, a league above what we can regularly read on the topic. Kudos for his clarity of thought, and the generosity of spreading it out.

If you are into this topic, you would do very well to read Bret’s essay on his blog: http://worrydream.com/LearnableProgramming/

With iOS6, is Apple opening up its platform wider while its competitors move to close theirs?

Developers, Apple may be calling out to you by intentionally punching holes into iOS6, holes that they clearly know users prefer to see filled quickly. Interpreting things this way, I think Apple is taking a page from Google’s playbook rather than handing them users on a plater. It’s about increasing the Developer mind-share.

There’s a lot of talk about missing features in iOS6, reactions range from disappointment to outrage. Google Maps is the clearest example,  the native app that shipped until now was working fine and didn’t need removing, so why has Apple taken this step, how could this even make any sense? This would be a counter-example of my post on Feature Debt.

As I look at it from an innovation management point of view however, I think Apple may actually be opening up its platform more to developers in select areas. Every missing feature should be jumped on by developers, for example everyone is now able to build a more accurate navigation to the locations that are relevant to their application. That’s how I interpret Apple shipping a clearly incomplete Maps application with iOS6. At least that’s what it inspires me.

Following this line of thought, I would see Apple’s move with Maps as an offensive to Google – rather than handing them a hand. Sure, a child knows that Google Maps is outstanding. But if you’ve been paying attention, Google’s strategy is to get people to build more and more feature on their platform, hence deepening developer dependence on Google. If Apple makes it possible for developers to build more essential features on iOS, they are playing the same cards that Google and Microsoft are playing. So this would be an offensive move. It’s about increasing Developer mind-share.

Just a thought.