Seibel: So you don’t think there are any ideas floating around academia that haven’t been picked up by industry simply because people resist certain kinds of change—maybe a generation of self-taught PHP programmers are never going to warm to Haskell even if it might be a better way to write software?

Norvig: I guess I’m pretty skeptical. I think that if there were real advantages, people would be taking advantage of them. I don’t think it’s a perfect information market where everything instantly moves to the optimal solution, but I think it approximates that. Academics may be not seeing the whole problem that the industry has to deal with. And part of it is an education problem, but if you have a bunch of programmers who don’t understand what a monad is and haven’t taken courses in category theory, there’s a gap.

And part of it’s this legacy of we’ve got all these systems and you can’t just throw them out all at once, so there’s a transition. I’m sure there are places where industry should be more forward-looking about saying, “Sure, we can’t make that transition today, but we should have a plan to say where are we going to be in ten years? It’s not going to be where we are now and how do we get there?”

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.