Seibel: So that’s a very high-level view of programming. How close to themetal do you think programmers today need to be able to go? If someone isgoing to be writing most of their applications in JavaScript, is it stillimportant that they grok assembly?

Eich: I know a lot of JavaScript programmers who are clever programmers,and the best ones have a good grasp of the economics. They benchmark andthey test as they go and they write tight JavaScript. They don’t have to knowabout how it maps to machine instructions.

A lot of them are interested in that when they hear about these JITing,tracing VMs that we’re building. And we’re getting more and more peoplewho are pushing pixels. If you give people enough programming-languageperformance and enough pixel-pushing power I think JavaScriptprogrammers will start using JavaScript at a lower level. And machineeconomics or the virtual-machine economics—what really matters? Maybeit’s the virtual-machine economics.

Abstraction is powerful. What I’m really allergic to, and what I had a badreaction to in the ’90s, was all the CORBA, COM, DCOM, object-orientednonsense. Every startup of the day had some crazy thing that would take200,000 method calls to start up and print “hello, world.” That’s a travesty;you don’t want to be a programmer associated with that sort of thing. AtSGI, the kernel, of course, was where the real programmers with chest hairwent, and there you couldn’t screw around. Kernel malloc was a new thing;we still used fixed-sized tables, and we panicked when we filled them up.

Staying close to the metal was my way of keeping honest and avoiding thebullshit, but now, you know, with time and better, faster hardware and anevolutionary winnowing process of good abstractions versus bad, I thinkpeople can operate above that level and not know assembly and still begood programmers and write tight code.

Seibel: Do you think, conversely, that the people who, back in the day,could write intricate, puzzle-box assembly code, would be just as greatprogrammers in today’s world doing high-level programming? Or does thatkind of programming require different skills?

Eich: I would say for certain aspects of programming there is acorrespondence between the two. There’s a difference between rawpointers and this happy, fun JavaScript world. That kind of still separates thechest hair—gender-independent—programmers from those who don’tquite have it.

Keeping it all in your head is important. Obviously people have differentsizedheads. Somebody with a big head could keep track of higher-levelinvariants in a memory-safe architecture and not have to worry aboutpointers. But there’s something still that bothers me if over time we losethe ability to write to the metal. Somebody’s doing it; the compiler isgenerating the code. The compiler writers have to be doing a better jobover time.

Seibel: So there will always be a place for that kind of programming. Butare there people who can be successful programmers now who justcouldn’t when all programming was low-level hacking? Or is there one fixedpopulation of people who have the right kind of brain for programming andnow they’re split with some people doing low-level stuff and some peopledoing high-level stuff?

Eich: I haven’t hacked kernel code in a long time, so I would have to go forthere’s some ability to migrate. There’s more code to write. And soundabstractions give you leverage over problems you couldn’t address before.

Seibel: Let’s go back to those ten days when you implemented the originalJavaScript. I know that at some point someone had turned you on toAbelson and Sussman and your original idea was to put Scheme in thebrowser.

Eich: The immediate concern at Netscape was it must look like Java. Peoplehave done Algol-like syntaxes for Lisp but I didn’t have time to take aScheme core so I ended up doing it all directly and that meant I could makethe same mistakes that others made.

I didn’t have total dynamic scope, like Stallman insisted was somehowimportant for Emacs and infested Elisp with. JavaScript has mostly lexicalscope with some oddness to it—there are a few loopholes that are prettymuch dynamic: the global object, the with statement, eval. But it’s not likedollar variables in Perl before my or upvar, uplevel in Tcl. The ’90s was fullof that—it was trendy.

But I didn’t stick to Scheme and it was because of the rushing. I had toolittle time to actually think through some of the consequences of things Iwas doing. I was economizing on the number of objects that I was going tohave to implement in the browser. So I made the global object be thewindow object, which is a source of unknown new name bindings andmakes it impossible to make static judgments about free variables. So thatwas regrettable. Doug Crockford and other object-capabilities devotees areupset about the unwanted source of authority you get through the globalobject. That’s a different way of saying the same thing. JavaScript hasmemory-safe references so we’re close to where we want to be but thereare these big blunders, these loopholes.

Making those variables in the top level actually become mutable propertiesof an object that you can alias and mess around with behind the back ofsomebody—that’s no good. It should’ve been lexical bindings. Because if yougo down from there into the functions and nested functions, then it is muchmore Scheme-like. You don’t quite have the rich binding forms, the fluid letsor whatever; you have more like set-bang. But the initial binding you createwith a local variable is a lexical variable.

Seibel: So basically now people make a top-level function to get anamespace.

Eich: Yeah. You see people have a function and they call it right away. Itgives them a safe environment to bind in, private variables. Doug’s a bigchampion of this. It was not totally unknown to the Schemers and Lispersbut a lot of JavaScript people had to learn it and Doug and others have donea valuable service by teaching them. It’s not like you’re getting everybody tobe high-quality Scheme programmers, unfortunately, but to some extentthey’ve succeeded, so people now do understand more functional idioms atsome patterny level, not necessarily at a deep level.

Seibel: So that’s the JavaScript that’s been out there for over a decade. Andnow there’s this big renaissance due to Ajax. So folks say, “OK, we reallyneed to take another look at this.” You recently went through the drama ofthe ECMAScript 4 proposal and the competing ECMAScript 3.1 proposaland now things seem to have settled down with the “Harmony” plan forunifying the two. Was the ES4 proposal your chance to show the worldthat, “Look, I’m a really smart guy and JavaScript is a really a goodlanguage”?

Eich: No, I don’t think so. I know Doug may think that. I don’t think Dougknows me that well, but the thing is, I’m not really looking for respect,especially from the Java-heads or the trailing edge.

Seibel: Was ES4 your brainchild? Was it your take on, knowing all that youknow now, what you want JavaScript to be?

Eich: No. It was definitely a collaborative effort and in some ways acompromise because we were working with Adobe, who had done aderivative language called ActionScript. Their version three was the one thatwas influencing the fourth-edition proposals. And that was based onWaldemar Horwat’s work on the original JavaScript 2/ECMAScript fourtheditionproposals in the late ’90s, which got mothballed in 2003 whenNetscape mostly got laid off and the Mozilla foundation was set up.

Waldemar did a good job—I gave him the keys to the kingdom in late ’97when I went off to found mozilla.org with Jamie. Waldemar is a hugebrain—I think he won the Putnam in ’87. MIT PhD. He did try and keep thedynamic flavor of the language, but he struggled to add certainprogramming-in-the-large facilities to it, like namespaces.