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.”

With JavaScript I think we held to this, against the wild, woolly Frenchmen superhackers who want to use JavaScript as a sort of a lambda x86 language. We’re not going to add call/cc; there’s no reason to. Besides the burden on implementers—let’s say that wasn’t a problem—people would definitely go astray with it. Not necessarily the majority, but enough people who wanted to be like the superhackers. There’s sort of a programming ziggurat—the Right Stuff, you know. People are climbing towards the top, even though some of the tops sometimes fall off or lose a toe.

You can only borrow trouble so many different ways in JavaScript. There are first-class functions. There are prototypes, which are a little confusing to people still because they’re not the standard classical OOP.

That’s almost enough. I’m not a minimalist who says, “That’s it; we should freeze the language.” That’s convenient cover for Microsoft, and it kind of outrages me, because I see people wasting a lot of time and still having bugs. You know, you can still have lots of hard-to-find bugs with lambda coding.

Doug has taught people different patterns, but I do agree with Peter Norvig: those patterns show some kind of defect in the language. These patterns are not free. There’s no free lunch. So we should be looking for evolution in the language that adds the right bits. Adding optional types probably will happen. They might even be more like PLT contracts.

Seibel: A lot of the stuff you’re dealing with, from static analysis of your C++ to the tracing JITs and new features for JavaScript, seems like you’re trying to keep up with some pretty cutting-edge computer-science research.

Eich: So we’re fighting the good fight but we’re trying to be smart about it. We’re also trying to move the research needle because—this is something else that was obvious to me, even back when I was in school, and I think it’s still a problem—there are a lot of problems with academic research. It’s widely separated from industry.

So there’s something wrong that we’d like to fix. We’ve been working with academics who are practically minded. That’s been great. We don’t have much money so we’re going to have to use leverage—partly it’s just getting people to talk and network together.

You lose something when the academics are all off chasing NSF grants every year. The other thing is, you see the rise in dynamic languages. You see crazy, idiotic statements about how dynamic language are going to totally unseat Java and static languages, which is nonsense. But the academics are out there convinced static type systems are the ultimate end and they’re researching particular kinds of static type systems like the ML, Hindley-Milner type inferences and it’s completely divorced from industry.

Seibel: Why is that? Because it’s not solving any real problems or because it’s only a partial solution?

Eich: We did some work with SML New Jersey to self-host the reference implementation of JavaScript, fourth edition, which is now defunct. We were trying to make a definitional interpreter. We weren’t even using Hindley-Milner. We would annotate types and arguments to avoid these crazy, notorious error messages you get when it can’t unify types and picks some random source code to blame and it’s usually the wrong one. So there’s a quality-of-implementation issue there. Maybe there’s a typetheoretic problem there too because it is difficult, when unification fails, to have useful blame.

Now you could do more research and try to develop some higher-level model of cognitive errors that programmers make and get better blame coordinates. Maybe I’m just picking on one minor issue here, but it does seem like that’s a big one.

Academia has not been helpful in leading people toward a better model. I think academia has been kind of derelict. Maybe it’s not their fault. The economics that they subsist on aren’t good. But we all knew we were headed toward this massively parallel future. Nobody has solved it. Now they’re all big about transactional memory. That’s not going to solve it. You’re not going to have nested transactions rolling back and contending across a large number of processors. It’s not going to be efficient. It’s not going to actually work correctly in some cases. You can’t map all your concurrent or parallel programming algorithms on to it. And you shouldn’t try.

People like Joe Armstrong have done really good work with the sharednothing approach. You see that a lot in custom systems in browser implementations. Chrome is big on it. We do it our own way in our JavaScript implementation. And shared nothing is not even interesting to academics, I think. Transactional memory is more interesting, especially with the sort of computer-architecture types because they can figure out ways to make good instructions and hardware support for it. But it’s not going to solve all the problems we face.

I think there will be progress and it should involve programming languages. That’s why I do think the talk about the second golden age isn’t wrong. It’s just that we haven’t connected the users of the languages with the would-be developers with the academics who might research a really breakthrough language.

Seibel: You got a Masters but not a PhD. Would you generally recommend that people who want to be programmers should go get a PhD in computer science? Or should only certain kinds of people do that?

Eich: I think only certain kind of people. It takes certain skills to do a PhD, and sometimes you wonder if it’s ultimately given just because you endured. But then you get the three letters to put after your name if you want to. And that helps you open certain doors. But my experience in the Valley in this inflationist boom of 20 years or so that we’ve been living through—though that may be coming to an end—was certainly it wasn’t a good economic trade-off. So I don’t have regrets about that.