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

Seibel:I read somewhere where you said that literate programming, a la Donald Knuth, is a brilliant idea. Do you use literate tools?

Crockford:No. I’ve been thinking about it and I’ve been designing literate tools for some of the languages that I’m using but I’m currently not doing any literate programming.

Seibel:Is that just a tool-chain problem? If the tools existed you think you would write literate programs?

Crockford:I would. I think JSLint, for example, would be easier for me to maintain if I had written it in a literate style. The thing I like about the literate style is that you’re designing the program specifically for reading and I think that provides tremendous value to the program.

Seibel:What are the key features of a literate programming tool, as you see it?

Crockford:The principal thing that Knuth found or provided was the ability to write out of order. So if I’m concerned with a particular thing which touches code in a lot of places, I can collect all that code together and describe it together, and then the tool will distribute the details out to where it needs to go.

Another of the things he frees you from is the size of a function. Ideally, you want a function to be no bigger than a screen’s worth so that you can read it all at once. And if it doesn’t fit, then you’re making a lot more functions, and if the functions aren’t actually contributing anything to the structure of the program, they’re just introducing noise.

Knuth allows you to take each of the aspects of that function, which may be closely related—it might have good coherence but it’s just big; sometimes stuff is big—and he allows you to represent each of those collections of stuff with an extremely descriptive label and then say, “This function is:” and then list those labels. You could do that with functions, but it’s not quite the same and then you have to deal with communication between the pieces, and so on. So it’s introducing more structure which doesn’t exactly match the problem.

Ultimately I would like to see new languages designed specifically to be literate languages. Knuth has been very good at applying the idea to Pascal and C, but I’d really like to see a new language which is, from the bottom, designed to be used in that fashion.

Seibel:Have you read Knuth’s literate programs?

Crockford:Sure.

Seibel:How do you read them? Like a novel?

Crockford:Yeah, I read it like a novel. I tend to be reading his prose rather than his program, but I really like the way he lays it out and he writes really well, and occasionally he’ll slip a little joke in there. I enjoy reading his stuff.

Seibel:And what do you get out of it? So you’ve read TeX: The Program , and you get to the end. Now are you ready to go add features into TeX or do you just have an overall sense of wow, Knuth’s a brilliant guy?

Crockford:That’s a really good question. I’ve read TeX, but I didn’t read it with an intention that I wanted to modify TeX. I was just reading it to see what he had done. I had a particular interest in how he was doing linebreaking, so I read that part with particular interest, more to understand his algorithm than to understand how the code works so that I can modify it or reuse it. If I were reading it with the expectation that I was going to mess with the program, I’m sure I would’ve read it differently.

Seibel:Do you often read code, literate or otherwise, for fun?

Crockford:Yeah. There’s not much code out there that’s good enough that you could read it for fun. Knuth wrote some. Fraser and Hanson have a C compiler that is literate; it’s very good. But there are not a lot of examples of that yet. That’s kind of a shame. That could indicate that maybe literate programming has failed, because there aren’t very many examples of it.

Seibel:What about Knuth’s magnum opus, The Art of Computer Programming ? Are you the kind of person who read it cover to cover, who dips into it for reference, or who put it on the shelf and never looked at it?

Crockford:All except the last one. When I was in college, there were a couple of months where I didn’t pay rent in order to buy copies of his books. And I read them and found jokes in them, like there’s a TUG joke in the index of Volume I. I have not been able to make sense out of all of it. There are places where he goes really a lot deeper than I can go, but I enjoy the books a lot, and I’ve also used them as reference books.

Seibel:Did you literally read them cover to cover, skimming over the math that you couldn’t understand?

Crockford:Yeah, the part when there are too many stars, I would read it very quickly. I tried to make familiarity with Knuth a hiring criteria, and I was disappointed that I couldn’t find enough people that had read him. In my view, anybody who calls himself a professional programmer should have read Knuth’s books or at least should have copies of his books.

Seibel:To read Knuth, it seems to me, you have to be able to read the math and understand it. To what extent do you think having that kind of mathematical training is necessarily to be a programmer?

Crockford:Obviously it’s not, because most of them don’t have it. In the sorts of applications that I’m working on, we don’t see that much application of the particular tools that Knuth gives us. If we were writing operating systems or writing runtimes, it’d be much more critical. But we’re doing form validations and UIs. Generally performance is not that important in the things that we do. We spend most of our time waiting for the user or waiting for the network.

I would like to insist that it’s absolutely necessary for people to understand this stuff, but it’s not. And maybe that’s why web programming has taken off and why it’s so accessible and why JavaScript works. This stuff really isn’t that hard. And most of the things that make it hard are unnecessarily hard. If we just cleaned up the platform a little bit, this work gets a lot easier.

Seibel:So there’s the nitty-gritty stuff that Knuth will teach you how to do and then there’s the big picture. Even if you clean up the platform, building big systems and designing them in a way that’s comprehensible will still be hard. How do you design your code?

Crockford:It’s not so much about writing the program as making iterations on the program’s survival. Generally the reason we’re doing software is because we know we’re going to have to change it and changing anything is hard because there’s a likelihood that, in changing it, you’re going to break it.

You can’t anticipate everything that’s going to be done with it but you try to build in enough flexibility that it’s likely to adapt to whatever you’re going to do. So that’s what I’m thinking. How do I not write myself into a corner too much? How do I give myself the flexibility to adapt as I need to?

That’s one of the things that I discovered I really like about JavaScript. Refactoring in JavaScript, I find, is really easy. Whereas refactoring a deep class hierarchy can be really, really painful.

For example, JSLint has transformed quite a lot since I started writing it in 2000, 2001. And its goals have changed significantly—it’s doing a lot of stuff now that I never thought it would do. And a lot of that’s because JavaScript is so flexible. I can fiddle with it and allow the program to grow without becoming sloppy.