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

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.

You see stuff like Ruby, which took influences from Ada and Smalltalk. That’s great. I don’t mind eclecticism. Though Ruby does seem kind of overhyped. Nothing bad about it, just sometimes the fan boys make it sound like the second coming and it’s going to solve all your problems, and that’s not the case. We should have new languages but they should not be overhyped. Like the C++ hype, the whole “design patterns will save us.” Though maybe they were reacting to the conservatism of the Unix C world of the ’80s.

But at some point we have to have better languages. And the reason is to have proof assistants or proof systems, to have some kind of automatic verification of some claims you’re making in your code. You won’t get all of them, right? And the dynamic tools like Valgrind and its race detectors, that’s great too. There’s no silver bullet, as Brooks said, but there are better languages and we should migrate to them as we can.

Seibel:To what extent should programming languages be designed to prevent programmers from making mistakes?

Eich:So a blue-collar language like Java shouldn’t have a crazy generic system because blue-collar people can’t figure out what the hell the syntax means with covariant, contravariant type constraints. Certainly I’ve experienced some toe loss due to C and C++’s foot guns. Part of programming is engineering; part of engineering is working out various safety properties, which matter. Doing a browser they matter. They matter more if you’re doing the Therac-25. Though that was more a threadscheduling problem, as I recall. But even then, you talk about better languages for writing concurrent programs or exploiting hardware parallelism. We shouldn’t all be using synchronized blocks—we certainly shouldn’t be using mutexes or spin locks. So the kind of leverage you can get through languages may involve trade-offs where you say, “I’m going, for safety, to sacrifice some expressiveness.”