Seibel Peter. Coders at Work
Подождите немного. Документ загружается.
Brendan Eich
145
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?
Download at Boykma.Com
Brendan Eich
146
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.
Download at Boykma.Com
Brendan Eich
147
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 thread-
scheduling problem, as I recall. But even then, you talk about better
Download at Boykma.Com
Brendan Eich
148
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.
Download at Boykma.Com
Brendan Eich
149
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 type-
theoretic 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
Download at Boykma.Com
Brendan Eich
150
concurrent or parallel programming algorithms on to it. And you shouldn’t
try.
People like Joe Armstrong have done really good work with the shared-
nothing 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.
The ability to go study something in a systematic, and maybe even leisurely,
way is attractive. The go-to-market, ride Moore’s law, and compete and
deal with fast product cycles and sometimes throwaway software—seems
like a shame if that’s all everybody does. So there’s a role for people who
want to get PhDs, who have the skills for it. And there is interesting
research to do. One of the things that we’re pushing at Mozilla is in
between what’s respected in academic research circles and what’s already
practice in the industry. That’s compilers and VM stuff, debuggers even—
things like Valgrind—profiling tools. Underinvested-in and not sexy for
Download at Boykma.Com
Brendan Eich
151
researchers, maybe not novel enough, too much engineering, but there’s
room for breakthroughs. We’re working with Andreas Gal and he gets
these papers rejected because they’re too practical.
Of course, we need researchers who are inclined that way, but we also
need programmers who do research. We need to have the programming
discipline not be just this sort of blue-collar thing that’s cut off from the
people in the ivory towers.
Seibel: How do you feel about proofs?
Eich: Proofs are hard. Most people are lazy. Larry Wall is right. Laziness
should be a virtue. So that’s why I prefer automation. Proofs are something
that academics love and most programmers hate. Writing assertions can be
useful. In spite of bad assertions that should’ve been warnings, we’ve had
more good assertions over time in Mozilla. From that we’ve had some
illumination on what the invariants are that you’d like to express in some
dream type system.
I think thinking about assertions as proof points helps. But not requiring
anything that pretends to be a complete proof—there are enough proofs
that are published in academic papers that are full of holes.
Seibel: On a completely different topic, what’s the worst bug you ever had
to track down?
Eich: Oh, man. The worst bugs are the multithreaded ones. The work I did
at Silicon Graphics involved the Unix kernel. The kernel originally started
out, like all Unix kernels of the day, as a monolithic monitor that ran to
completion once you entered the kernel through a system call. Except for
interrupts, you could be sure you could run to completion, so no locks for
your own data structure. That was cool. Pretty straightforward.
But at SGI the bright young things from HP came in. They sold symmetric
multiprocessing to SGI. And they really rocked the old kernel group. They
came in with some of their new guys and they did it. They stepped right up
and they kept swinging until they knocked the ball pretty far out of the field.
But they didn’t do it with anything better than C and semaphores and spin
Download at Boykma.Com
Brendan Eich
152
locks and maybe monitors, condition variables. All hand-coded. So there
were tons of bugs. It was a real nightmare.
I got a free trip to Australia and New Zealand that I blogged about. We
actually fixed the bug in the field but it was hellish to find and fix because it
was one of these bugs where we’d taken some single-threaded kernel code
and put it in this symmetric multiprocessing multithreaded kernel and we
hadn’t worried about a particular race condition. So first of all we had to
produce a test case to find it, and that was hard enough. Then under time
pressure, because the customer wanted the fix while we were in the field,
we had to actually come up with a fix.
Diagnosing it was hard because it was timing-sensitive. It had to do with
these machines being abused by terminal concentrators. People were
hooking up a bunch of PTYs to real terminals. Students in a lab or a bunch
of people in a mining software company in Brisbane, Australia in this sort of
’70s sea of cubes with a glass wall at the end, behind which was a bunch of
machines including the SGI two-processor machine. That was hard and I’m
glad we found it.
These bugs generally don’t linger for years but they are really hard to find.
And you have to sort of suspend your life and think about them all the time
and dream about them and so on. You end up doing very basic stuff, though.
It’s like a lot of other bugs. You end up bisecting—you know “wolf fence.”
You try to figure out by monitoring execution and the state of memory and
try to bound the extent of the bug and control flow and data that can be
addressed. If it’s a wild pointer store then you’re kinda screwed and you
have to really start looking at harder-to-use tools, which have only come to
the fore recently, thanks to those gigahertz processors, like Valgrind and
Purify.
Instrumenting and having a checked model of the entire memory hierarchy
is big. Robert O’Callahan, our big brain in New Zealand, did his own
debugger based on the Valgrind framework, which efficiently logs every
instruction so he can re-create the entire program state at any point. It’s
not just a time-traveling debugger. It’s a full database so you see a data
structure and there’s a field with a scrogged value and you can say, “Who
wrote to that last?” and you get the full stack. You can reason from effects
Download at Boykma.Com
Brendan Eich
153
back to causes. Which is the whole game in debugging. So it’s very slow. It’s
like a hundred times slower than real time, but there’s hope.
Or you can use one of these faster recording VMs—they checkpoint only at
system call and I/O boundaries. They can re-create corrupt program states
at any boundary but to go in between those is harder. But if you use that
you can probably close in quickly at near real time and then once you get to
that stage you can transfer it into Rob’s Chronomancer and run it much
slower and get all the program states and find the bug.
Debugging technology has been sadly underresearched. That’s another
example where there’s a big gulf between industry and academia: the
academics are doing proofs, sometimes by hand, more and more
mechanized thanks to the POPLmark challenge and things like that. But in
the real world we’re all in debuggers and they’re pieces of shit from the ’70s
like GDB.
Seibel: In the real world one big split is between people who use symbolic
debuggers and people who use print statements.
Eich: Yeah. So I use GDB, and I’m glad GDB, at least on the Mac, has a
watch-point facility that mostly works. So I can watch an address and I can
catch it changing from good bits to bad bits. That’s pretty helpful. Otherwise
I’m using
printfs to bisect. Once I get close enough usually I can just try
things inside GDB or use some amount of command scripting. But it’s
incredibly weak. The scripting language itself is weak. I think Van Jacobson
added loops and I don’t even know if those made it into the real GDB, past
the FSF hall monitors.
But there’s so much more debugging can do for you and these attempts, like
Chronomancer and Replay, are good. They certainly changed the game for
me recently. But I don’t know about multithreading. There’s Helgrind and
there are other sort of dynamic race detectors that we’re using. Those are
producing some false positives we have to weed through, trying to train the
tools or to fix our code not to trigger them. The jury is still out on those.
The multithreaded stuff, frankly, scares me because before I was married
and had kids it took a lot of my life. And not everybody was ready to think
about concurrency and all the possible combinations of orders that are out
Download at Boykma.Com
Brendan Eich
154
there for even small scenarios. Once you combine code with other people’s
code it just gets out of control. You can’t possibly model the state space in
your head. Most people aren’t up to it. I could be like one of these chest-
thumpers on Slashdot—when I blogged about “Threads suck” someone was
saying, “Oh he doesn’t know anything. He’s not a real man.” Come on, you
idiot. I got a trip to New Zealand and Australia. I got some perks. But it was
definitely painful and it takes too long. As Oscar Wilde said of socialism, “It
takes too many evenings.”
Seibel: How do you design code?
Eich: A lot of prototyping. I used to do sort of high-level pseudocode, and
then I’d start filling in bottom up. I do less of the high-level pseudocode
because I can usually hold it in my head and just do bottom-up until it joins.
Often I’m working with existing pieces of code adding some new subsystem
or something on the side and I can almost do it bottom-up. When I get in
trouble in the middle I do still write pseudo-code and just start working
bottom up until I can complete it. I try not to let that take too long because
you’ve got to be able to test it; you’ve got to be able to see it run and step
through it and make sure it’s doing what it’s supposed to be doing.
Before that level of design, there may be some entity relationships or gross
modularization. There’s probably an algorithm or three that we’re thinking
of where you’re reasoning about the complexity of it—is it linear? Is it
constant? Every time I’ve written some kind of linear search that’s going to
compound quadratically, and unleashed it on the Web, web developers have
found that to be a problem. They’ve written enough stuff it stresses it. So
we tend to do a lot of data structures that are constant time. And even
then, constant can be not one—it can be big enough that you care.
So we do lots of prototyping, we do lots of bottom-up and top-down and
they meet in the middle. And I think actually we, at Mozilla, don’t do enough
rewriting. We’re very conservative. We are open source, so we have
community we try to build and bring new people into. We certainly have
value that users benefit from, and we don’t want to take a three-year break
rewriting, which is what would happen if we tried too much.
But if you really are trying to move a needle and you don’t know exactly
what you’re doing, rewrite. It’s going to take several tries to know what the
Download at Boykma.Com