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.
Seibeclass="underline" Have you read Knuth’s literate programs?
Crockford: Sure.
Seibeclass="underline" 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.
Seibeclass="underline" 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.
Seibeclass="underline" 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.
Seibeclass="underline" 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.
Seibeclass="underline" 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.
Seibeclass="underline" 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.
Seibeclass="underline" 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.
Seibeclass="underline" What makes it so much easier?
Crockford: I’ve become a really big fan of soft objects. In JavaScript, any object is whatever you say it is. That’s alarming to people who come at it from a classical perspective because without a class, then what have you got? It turns out you just have what you need, and that’s really useful. Adapting your objects… the objects that you want is much more straightforward.
Seibeclass="underline" Presumably the problem, working with a class-based language, is that it’s too static—you’ve got a big class hierarchy and if you want to change that structure you’ve got to take it apart and put it back together. In JavaScript it seems the danger is that it can be too dynamic—you’ve stuck little kludges everywhere and the actual structure of your program is determined by lots of things that happen at runtime; there’s no static thing you can look at and say, “OK, this is the program and how it’s structured.”
Crockford: That is the scary part of it and it’s good to be scared because it is scary and it is real. It requires discipline. In most of the classical languages, the language is the thing imposing the discipline. In JavaScript you have to bring your own discipline.
Part of what I do to keep my code from falling apart is to be really rigorous myself in how I put it together because I know the language is not providing that rigor for me. So today I would not consider undertaking something as complicated as JSLint without JSLint. JavaScript does not scale very well on its own, but with that tool I become a lot more confident that I’m going to be able to keep it working.
Seibeclass="underline" So the softness of JavaScript objects can be dangerous. But if you never availed yourself of the ability to augment objects, then you might as well just be writing classes in Java. Is there some way you think about structuring your JavaScript programs to take good advantage of the flexibility the language gives you?