Peter Seibel - Coders at Work - Reflections on the craft of programming

But you want improvements in areas that are going to make a big impact. And I think a lot of the times the level that programming languages are looking at is maybe too low a level to have as big an impact as language designers think it’s going to. So if they say, “Oh look, in my shiny new language, these six lines of code become two lines of code.” Well yeah, that’s nice, and I guess that makes you more productive and it’s easier to debug and maintain and so on. But maybe the code that you write is just a small part of the whole production system, and really the big headache is updating your data every day, and scraping the Web and getting this new data in, and putting it in the right format. So you have to remember that you’re solving a very small part of the overall problem and that means there has to be a big barrier to make it worthwhile to make a switch.

Seibel:So leaving aside the utility language research, you feel like we have come a ways since computer science was like majoring in IBM.

Norvig:Yeah. I think it’s a good curriculum now, and it’s depressing that it’s not being taken up by many students. Enrollments are down. Certainly there is a class of people who just love computers or computer design so much that that’s where they end up. We’re holding onto that group. But then there’s a bunch of the best and the brightest who are going into physics or biology or something because those are the hottest fields. And then there’s a bunch who are saying, “Well, I kind of like computers but there’s no future in it because all of the jobs are outsourced to India anyway, so I’m going to do prelaw or something else so I can get a job.” And I think that’s a shame. I think they’ve been misinformed.

Seibel:You mean it’s a shame because you think a lot of those people would enjoy being programmers, or because we need them?

Norvig:Both. Many people could enjoy lots of different things and if they enjoy two equally I don’t want to say that they have to do computer science. But I think there is a mismatch. We need more good people and I think that they can have a big impact on the world and if that’s what they want to accomplish, rationally we should be allocating more of the top people into computer science than we are now.

Seibel:In one of his papers Dijkstra talks about how computer science is a branch of mathematics and how computer-science students shouldn’t even touch a computer for the first n years of their education and should instead learn to manipulate systems of formal symbols. How much mathematics do you think is required to be a competent programmer?

Norvig:I don’t think you need the full Dijkstra level. And it’s a particular type of math that he focuses on. It’s discrete, logical proofs. I guess I’m coming from an area where that’s less important and it’s more probabilistic rather than logical. I rarely have a program that I can prove correct.

Is Google correct? Well, type in these words, you get back ten pages. If it crashes, then it’s incorrect but if it gives you back these ten links rather than those ten links, there’s no saying that one is right. You can have opinions on which are better than the other, but you can’t go beyond that. I think that’s quite different than what he had in mind. I think once you start solving these types of problems or the problem of having a robot car navigate through a city without hitting anybody, the logical proof gets thrown out pretty quickly.

Seibel:So is there any essential skill needed to be a good programmer? Different domains obviously have different requirements but ultimately is there some commonality to writing code regardless of the domain?

Norvig:You’ve got to be able to make progress and then improve on it. That’s all you need to be able to do in life. You’ve got to have some idea and say, “Here’s the direction to go,” and then be able to say, “Now I’ve got to refine it.” And refinement can be, “I didn’t quite get it right; there are cases I didn’t handle,” or it can be, “Now that I understand it better, I’m going to write a tool so that it’s more abstract and next time I can write a system like this more easily.” Which I guess is that level of introspection to say, “Where was I going? How did I get there? Is there a better way to get there?”

Seibel:So do you think that that skill—essentially make it; debug it; iterate—is a kind of thinking that lots of people should learn, even people who aren’t going to ultimately be programmers? If you were making a grade-school or junior-high or high-school curriculum, would you want everyone to be exposed to the idea of programming? Or is it too specialized a skill?

Norvig:I think it’s specialized. I think it’s one example of this type of thinking. But I’d be just as happy if you brought other examples like some type of mechanical problem. “Here’s a bunch of pieces. How can I move some water from here to here and get it into this cup?” It doesn’t have to be manipulating lines of code. It could be manipulating many kinds of pieces and seeing how they work together.

Seibel:And how far down should programmers go? In “Teach Yourself Programming in Ten Years,” you talk about knowing how long it takes to execute an instruction vs. reading from disk and so on. Do we still need to learn assembly?

Norvig:I don’t know. Knuth said, do everything in assembly, because it’s just too inefficient to write in C. I don’t agree with that. I think you want to know enough to know what instructions are inefficient, but that’s no longer at the level of individual instructions. It’s not just that this was a threeinstruction sequence rather than a two-instruction sequence. It’s, did you have a page fault or a cache miss? I don’t think we need to know assembly language. You need architecture. You should understand what assembly language is, and you should understand that there’s a memory hierarchy and missing from one level of the hierarchy to the next is a big performance penalty. But I think you can understand that at the abstract level.

Seibel:Are there any books that you think all programmers should read?

Norvig:I think there are a lot of choices. I don’t think there’s only one path. You’ve got to read some algorithm book. You can’t just pick these things out and paste them together. It could be Knuth, or it could be the Cormen, Leiserson, and Rivest. And there are others. Sally Goldman’s here now. She has a new book out that’s a more practical take on algorithms. I think that’s pretty interesting. So you need one of those. You need something on the ideas of abstraction. I like Abelson and Sussman. There are others.

You need to know your language well. Read the reference. Read the books that tell you both the mechanics of language and the whole enterprise of debugging and testing: Code Complete or some equivalent of that. But I think there are a lot of different paths. I don’t want to say you have to read one set of books.

Seibel:Though your job now doesn’t entail a lot of programming you still write programs for the essays on your web site. When you’re writing these little programs, how do you approach it?

Norvig:I think one of the most important things is being able to keep everything in your head at once. If you can do that you have a much better chance of being successful. That makes a small program easier. For a bigger program, you need extra tools to be able to handle that.

It’s also important to know what you’re doing. When I wrote my Sudoku solver, some bloggers commented on that. They said, “Look at the contrast—here’s Norvig’s Sudoku thing and then there’s this other guy, whose name I’ve forgotten, one of these test-driven design gurus. He starts off and he says, “Well, I’m going to do Sudoku and I’m going to have this class and first thing I’m going to do is write a bunch of tests.” But then he never got anywhere. He had five different blog posts and in each one he wrote a little bit more and wrote lots of tests but he never got anything working because he didn’t know how to solve the problem.