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

Seibel: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.

Seibel: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.

Seibel: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?

Crockford:For me it was years of trial and error. When I started working with JavaScript, I didn’t read anything about it. I just started. I found a sample program, which was awful, and started fiddling with it until it worked more like the way I thought it should. So I began programming in the language, having no understanding about what the language was, or how it worked, or how you needed it to think about it.

I understand why people are frustrated with the language. If you try to write in JavaScript as though it is Java, it’ll keep biting you. I did this. One of the first things I did in the language was to figure out how to simulate something that looked sort of like a Java class, but at the edges it didn’t work anything like it. And I would always eventually get pushed up against those edges and get hurt.

Eventually I figured out I just don’t need these classes at all and then the language started working for me. Instead of fighting it, I found I was being empowered by it.

Seibel:When you’re designing software, do you prefer to think top-down or bottom-up or middle-out?

Crockford:All at once. That’s the thing about keeping the system in your head. Ultimately you need to divide and conquer and get it down into something you can manage. I find I’m on all parts of the problem and using all those techniques simultaneously. And I keep struggling with it until I become clear on what the structure is. Once you figure out what the structure is, then the rest of it falls out.

Seibel:How do design and coding relate for you? Do you start coding immediately and then iteratively refine it, or do you do something that’s separate from writing code?

Crockford:They used to be separate. They’re becoming more similar now. I used to work in a design language or a meta language—something semi-English, a little structured, which is more descriptive of what you’re going to write. But if I’m writing in JavaScript, that language has turned into JavaScript.

Seibel:What tools do you actually use for writing code?

Crockford:I use a little freeware text editor. It doesn’t do anything tricky. That’s about all I need. There is much less need of formal tools like you have in other languages. The browser just wants a source file, and so you send it a source file, and the compiler is built into the browser, so there’s really nothing to do. You don’t have a linker. You don’t have a compiler. You don’t have any of that stuff. It just all runs on the browser.

Seibel:You use JSLint, presumably.

Crockford:I do use JSLint. I use it a lot. I try to use it every time before I run a program, so if I’ve gone through and I’ve done some edits, I’ll run it through JSLint first before I run it.

Seibel:So you edit in your text editor, run JSLint on the program, and then run it in a browser. How about debugging?

Crockford:It depends on the browser. If it’s Firefox, then you use Firebug. If it’s IE, then you use the Visual Studio debugger. They’re both actually very good. We have surprisingly good debuggers in the browser.

I’ve used frameworks in which there were inspectors built out of DOM elements that could then go into objects, and open them up, and inspect through that set of frames. But I found I really don’t need that. Just a debugger is enough.

Seibel:Do you ever step through code just as a way of checking it when you’re not tracking down a specific bug?

Crockford:Only if I have something that’s really intricate. I’ll step through it as part of my testing, but generally I only step if I know I have problems.

Seibel:How about other debugging techniques, like assertions, or proofs. Do you use any of those? Do you think in terms of invariants?

Crockford:I like them. I was disappointed that Eiffel was not the winner in the object-oriented-language contest; that C++ won instead. I thought Eiffel was a much more interesting language and I liked the precondition/postcondition contract stuff that it did. I would like to see that built into my language, whatever language I’m using, but that’s another one of those ideas that hasn’t really caught on.

Seibel:What’s the worst bug you ever had to track down?

Crockford:It would’ve been a real-time bug. It might’ve been in a video game. We’ve got interrupts popping all over the place, and no memory management at all, and the program suddenly goes away and you don’t know why. That kind of stuff is really hard. And generally there wouldn’t be a debugger around either.

At Basic Four we had developed a word-processing terminal. It was a Z80-based terminal with a full-page display and 64K, which wasn’t nearly enough memory for a display that big. And it had a local network connection to our server where it would send up the pages.

And we had this problem where every once in a while the screen would go blank. We had this architecture in which we had a line of text and then it would have a stop code, and then the address of the next line, and a little DMA processor that would follow those links. And at some point a link would go away—there was some race that was happening.

From our perspective, looking at it logically, all of the links were good, but we hadn’t considered the real-time interaction with the DMA processor, which might not be looking at memory at the same time that we were. I just puzzled it out. I remember I was working at home that day and I was on the phone with my team and suddenly the lightbulb went on; I knew what the problem was and I was able to tell them how to fix it and we never had that problem again.