There’s a contrary school which is more pedantic: “We should have just a few primitives we can de-sugar our spec to; we can lambda code everything. That’s how people should write anyway because that’s how I think of things” or, “That’s the best way to think of things.” It’s very reductionistic and it’s not for everybody. Obviously one way to do your own mental proof system is to reduce things, to subset languages. Subsetting is powerful. But to say everyone has to program in this sort of minuscule subset, that’s not usable.

Seibel: In some of the discussion about ES4, you cited Guy Steele’s paper, “Growing a Language.” Speaking as a Lisper, to me the take-away from that paper was, step one, put a macro system in your language. Then all of this special sugar goes away.

Eich: There are two big problems, obviously. C syntax means that you have a much harder time than with s-expression, so you have to define your ASTs and we’re going to have to standardize them and that’s going to be a pain. Then there’s the other problem, which is hygiene is still not quite understood. Dave Herman, who’s working with us is doing his thesis—or was last I checked—on a kind of logic for proving soundness for hygiene, which is, I hope, beneficial. Because we will get to macros.

I said this to Doug Crockford a couple years ago when he had me speak at Yahoo! I started talking about the sugar that I was enthusiastic about. He said, “Gee, maybe we should do a macro system first,” and I said, “No, because then we’ll take nine years.” At the time there was a real risk politically that Microsoft was just not going to cooperate. They came back into ECMA after being asleep and coasting. The new guy, who was from Hyderabad, was very enthusiastic and said, “Yes, we will put the CLR into IE8 and JScript.net will be our new implementation of web JavaScript.” But I think his enthusiasm went upstairs and then he got told, “No, that’s not what we’re doing.” So it led to the great revolt and splitting the committee.

So we were concerned that if we went off to do macros we were doing research, and if we were doing research we were not going to have Microsoft engaged and we were not going to be putting competitive pressure on them. So macros have had to wait. I’m fine with that so long as we do the right automated grammar checks and we do make sure we can recast all of the sugar as macros when we have macros. But in the meantime there’s no reason to starve the users for sugar. It doesn’t rot their teeth and it helps them avoid mistakes.

Seibel: Back in 1995, what other languages influenced your original design of JavaScript?

Eich: Self was big, mainly because of the papers that Dave Ungar had just written. I never played with any Self code, but I was just inspired by them. I like Smalltalk and here was somebody taking one idea applied to Smalltalk, which was prototype-based delegation—multiple prototypes unlike JavaScript—and just running with it as hard as they could. That was inspiring to me because there was both good compiler, VM-level engineering and, I thought, good language design.

Because, like Crock and others, I think you do want to simplify and I do like the languages designers who take fewer primitives and see how far they can go. I think there’s been kind of a Stockholm syndrome with JavaScript: “Oh, it only does what it does because Microsoft stopped letting it improve, so why should we want better syntax; it’s actually a virtue to go lambda-code everything.” But that Stockholm syndrome aside, and Microsoft stagnating the Web aside, language design can do well to take a kernel idea or two and push them hard.

Seibel: Were you aware of NewtonScript at all?

Eich: Only after the fact did someone point it out to me and I realized, “Hey, they’ve got something like our scope chain in their parent link and our single prototype.” I think it was convergent evolution based on Self. And the DOM event handlers—part of the influence there was HyperTalk and Atkinson’s HyperCard. So I was looking not only at Self and Scheme, but there were these onFoo event handlers in HyperTalk, and that is what I did for the DOM onClick and so on.

One more positive influence, and this is kind of embarrassing, was awk. I mean, I was an old Unix hacker and Perl was out, but I was still using awk for various chores. And I could’ve called these first-class functions anything, but I called them “function” mainly because of awk. An eight-letter keyword—it’s kind of heavy, but there it is.

Seibel: At least it wasn’t “lambda”—JavaScript would’ve been doomed from the start. Were there any languages that negatively influenced JavaScript, in the sense of, “I don’t want to do that”?

Eich: It was such a rush job that I wasn’t, like, worried about, “Oh, I can’t make it into Ada or Common Lisp.” Java was in some ways a negative influence. I both had to make it look like Java and not let in those crazy things like having a distinction between primitive types and objects. Also, I didn’t want to have anything classy. So I swerved from that and it caused me to look at Self and do prototypes.

Seibel: Did you ever consider making a language more closely related to Java—take Java and make some kind of simple subset; get rid of the primitive types and other needless complexities?

Eich: There was some pressure from management to make the syntax look like Java. There was also some pressure to make it not too big, because after all, people should use Java if they’re doing any real programming; this is just Java’s dumb little brother.

Seibel: So you wanted to be like Java, but not too much.

Eich: Not too much. If I put classes in, I’d be in big trouble. Not that I really had time to, but that would’ve been a no-no.

Seibel: Coming back to the present, ES4 has been officially abandoned and everyone is now working toward ES-Harmony, which will somehow combine ES3.1 with ideas from ES4? Do you think that’s ultimately a good decision?

Eich: Doug was a little triumphalist in first blog post: “We’ve won. The devil has been vanquished.” I had a joke slide I gave in London a year ago about Doug being Gandalf on the bridge, at Khazad-dûm facing down the ES4rog. He liked that a lot. It was the first time I poked fun at him because he’s a little serious sometimes when he gets on this topic and he liked it a lot. He can be the hero; ES4 wasn’t quite the monster.

ES4 looks, in retrospect, too big. But we need to be practical about standards. We can’t just say all you need are lambdas—Alonzo Church proved it, so we’re not going to add any more to the language. That’s the sort of impoverished approach that tries to make everybody into an expert and it will not work on the large number of programmers out there who have been mistrained in these Java schools. JavaScript will fall someday but we can keep evolving it and keep it competitive in both the theoretical and the practical sense if we don’t try to hold back the sugar for purity’s sake.

It needs to evolve to solve the problems that programmers face. Programmers can solve some of them by writing their own library abstractions. But the ability to write abstractions in the language is limited without the extensions—you can’t write getters and setters. You can’t make objects look native, have properties turn into code; things like that. And you can’t solve some of these security problems in an implicit or automated way.

Seibel: In general do you feel like languages are getting better over time?

Eich: I think so, yeah. Maybe we’re entering the second golden age; there’s more interest in languages and more language creation. We talk about programming: we need to keep practicing the craft—it’s like writing or music. But the language that you use—the tonal system—matters too. Language matters. So we should be evolving programming languages; we shouldn’t be sitting still. Because the Web demands compatibility, JavaScript may have to sit still too much. But we shouldn’t get stuck by that; we should either make a better JavaScript, even if it doesn’t replace the one on the Web, or we should move beyond that.