Me, a painter?
I’d better keep an eye on this Paul Graham guy. He’s obviously been thinking too much about programming. But the lastest article of his that I’ve read is just fascinating — especially because I instinctively agree to most of what he says.
I’ve never liked the term ‘computer science.’ The main reason I don’t like it is that there’s no such thing. Computer science is a grab bag of tenuously related areas thrown together by an accident of history, like Yugoslavia. At one end you have people who are really mathematicians, but call what they’re doing computer science so they can get DARPA grants. In the middle you have people working on something like the natural history of computers— studying the behavior of algorithms for routing data through networks, for example. And then at the other extreme you have the hackers, who are trying to write interesting software, and for whom computers are just a medium of expression, as concrete is for architects or paint for painters. It’s as if mathematicians, physicists, and architects all had to be in the same department.
Perhaps one day ‘computer science’ will, like Yugoslavia, get broken up into its component parts. That might be a good thing. Especially if it meant independence for my native land, hacking.
…Hackers need to understand the theory of computation about as much as painters need to understand paint chemistry. You need to know how to calculate time and space complexity and about Turing completeness. You might also want to remember at least the concept of a state machine, in case you have to write a parser or a regular expression library. Painters in fact have to remember a good deal more about paint chemistry than that.
…I was taught in college that one ought to figure out a program completely on paper before even going near a computer. I found that I did not program this way. I found that I liked to program sitting in front of a computer, not a piece of paper. Worse still, instead of patiently writing out a complete program and assuring myself it was correct, I tended to just spew out code that was hopelessly broken, and gradually beat it into shape. Debugging, I was taught, was a kind of final pass where you caught typos and oversights. The way I worked, it seemed like programming consisted of debugging.
…For a long time I felt bad about this, just as I once felt bad that I didn’t hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. As far as I can tell, the way they taught me to program in college was all wrong. You should figure out programs as you’re writing them, just as writers and painters and architects do.”
Mr. Hoar, I assume you’re reading this. It’d be a great idea to take Paul’s reflections into account as you teach novice programmers how to go about programming. Because some of your students will be the ones just looking for another math credit, this may not matter all that much to everyone. But to those of us who care about programming, treating us like programmers — makers — will, in my (humble) opinion, help us learn our field of study so much better.
Not that IPO charts and pseudocode are wrong; they might be necessary on larger projects. But don’t push us to write pseudocode until we get to the big programs — the Best Works™ projects. Maybe then.