Seibel Peter. Coders at Work
Подождите немного. Документ загружается.
Brendan Eich
155
hell you’re doing. And then when you have a design more firm you’ll stick
with it and you’ll start patching it more, and you’ll get to this mature state
where we creak with patches. It’s kind of an evolutionary dead-end for
code. You know, maybe it’s a good sunk cost and you can stand on it for
years. Maybe it’s this thing that’s crying out for replacement. Maybe in the
open-source world some better standard library has emerged.
And that gets back to the craft of programming, I think. You don’t just write
code based on some old design. You want to keep practicing, and the
practicing involves thinking about design and feeding back your experience
in coding to the design process.
I have this big allergy to ivory-tower design and design patterns. Peter
Norvig, when he was at Harlequin, he did this paper about how design
patterns are really just flaws in your programming language. Get a better
programming language. He’s absolutely right. Worshipping patterns and
thinking about, “Oh, I’ll use the X pattern.”
Seibel: So newer experiences can show you better ways going forward. But
what about when writing the code shows you big flaws in your existing
design?
Eich: That does happen. It happens a lot. Sometimes it’s difficult to throw
out and go back to square one. You’ve already made commitments, and you
get into this trap. I did this with JavaScript, In a great big hurry, I wrote a
byte-code interpreter. Even at the time I knew I was going to regret some
of the things I’d done. But it was a design that was understandable to other
people and I could hope to get other people helping me work on. So I
question design all the time. I just realize that we don’t always get the luxury
of revisiting our deepest design decisions. And that is where we then
attempt to do a big rewrite, because you really would have a hard time
incrementally rewriting to change deep design decisions.
Seibel: How do you decide when it’s right to do a big rewrite? Thanks to
Joel Spolsky, Netscape is in some ways the poster child for the dangers of
the big rewrite.
Eich: There was an imperative from Netscape to make the acquisition that
waved the Design Patterns book around feel like they were winners by using
Download at Boykma.Com
Brendan Eich
156
their new rendering engine, which was like My First Object-Oriented
Rendering Engine. From a high level it sounded good; it used C++ and
design patterns. But it had a lot of problems.
But the second reason we did the big rewrite—I was in mozilla.org and I
really was kind of pissed at Netscape, like Jamie, who was getting ready to
quit. I thought, you know, we need to open up homesteading space to new
contributors. We can’t do it with this old hairball of student code from
1994. Or my fine Unix kernel-style interpreter code.
We needed to do a fairly big reset. Yeah, we were going to be four years
from shipping. At that point I don’t think we were telling upper management
that because they didn’t want to hear it, so we were optimizing to them.
And that cost some of the management their heads. Though they all made
out fabulously on the options—much better than I did. But for Mozilla that
was the right trade.
We were lucky in hindsight, because we could have had a more rapid
evolution of the Web. Microsoft was—some people claim this was due to
the antitrust case more than their nature—inclined to sit on the Web and
stagnate it. So that gave us time to wave the standards flag—which is two-
edged and half bullshit—and go rewrite. Like Joel, I’m skeptical of rewrites. I
think it’s rare to find that kind of an alignment of interests and get enough
funding to live through it and not miss the market. The exceptions are very
rare.
The rewrites I was speaking of earlier, though, were when you’re
prototyping. That’s critical and smaller-scale. It may be a cross-cutting
change to a big pile of code so it’s small in lines, but it’s big in reach and all
the invariants you have to satisfy. Or maybe it’s a new JIT or whatever, and
that you can get away with.
Seibel: Have you ever done any literate programming, a la Knuth?
Eich: I followed the original stuff. It was very neat. I liked it. It was word
retrieval. He had some kind of a hash-trie data structure and it was all
literately programmed. Then Doug McIlroy came along and did it all with a
pipeline.
Download at Boykma.Com
Brendan Eich
157
Our programs are heavily commented but we don’t have any way of
extracting the prose and somehow making it be checked by humans, if not
automatically, against the code. Python people have done some more
interesting work there. I have not done anything more than heavily
comment. I do go back and maintain comments—it’s a real pain and
sometimes I don’t do it and then I regret it because somebody gets a bum
steer.
I actually like McIlroy’s rejoinder. It wasn’t a rebuttal of literate
programming—but it was kind of. You don’t want to write too many words,
prose or code. In some ways the code should speak for itself at the small
level. It’s at the bigger level, the big monster function or the module
boundary, that you need docs. So doc comments or things like them—doc
strings. Embedding the test in the comment. I guess that’s the big Python
thing. That’s good.
There is something to literate programming, especially these integrated
tests and doc strings. I’d like to see more of that supported by languages.
We tried to add doc comments of some sort to ES4 with first-class
metadata hooks or reflection hooks and it was just impossible to get
everybody to agree.
Seibel: Do you read code you’re not working on?
Eich: I do it as part of my job. Code review is a mandatory pre-check-in
step, mostly to compensate for Netscape’s bad hiring, but we kept it and
still use it for integration review. We have a separate “super review” for
when you’re touching a lot of modules and you don’t know all the hidden
invariants that Joe Schmoe, who no longer works on Mozilla, knew in his
head. Somebody else may have figured them out so you have somebody
experienced to look at the big picture. Sometimes you can bypass it if you
know what you’re doing and you’re in the sort of Jedi council, but we’re not
trying to cheat on it too much.
We don’t have design reviews, so sometimes this causes a delayed design
review to happen. They say, “Oh, back to the drawing board. You wrote
too much code. You should have designed it this other way.” That’s the
exception. We aren’t going to impose any kind of waterfall, design then
implementation. That was the big thing when I was getting into the industry
Download at Boykma.Com
Brendan Eich
158
in the early ’80s and it was a nightmare, frankly. You spend all this time
writing documents and then you go to write the code and often you realize
that it’s really stupid and you totally change the code and put the documents
down the memory hole.
Seibel: So that’s code that is going into Mozilla; do you ever read other
people’s code, outside Mozilla, just for edification?
Eich: Open source is great. I love looking at other people’s code that’s in
some other part of the world. I don’t spend enough time on it but I do look
at server frameworks or I look at things like Python and Ruby.
Seibel: The implementations of those things?
Eich: Implementations and also library code. I look at the Ajax libraries—
and it’s heartening to see how clever people can be and how this small set
of tools—closures, prototypes, and objects—can be used to create
reasonable, convenient, sometimes very convenient abstractions. They’re
not always hardened or safe but they’re awfully convenient.
Seibel: When you read a big piece of code, how do you get into it?
Eich: I used to start top-down. If it’s big enough you get function pointers
and control flow gets opaque. I sometimes drive it in the debugger and play
around with it that way. Also, I look for bottom-up patterns that I
recognize. If it’s a language processor or if it’s got something that makes
system calls that I understand, I can start looking at how those primitives
are used. How does that get used by higher levels in the system? And that
helps me get around. But really understanding it is this gestalt process that
involves looking at different angles of top and bottom and different views of
it, playing in the debugger, stepping through in the debugger—incredibly
tedious though that can be.
If you can understand what’s going on a little bit in the heap—chase
pointers, walk through cons cells, whatever—that can be worth the trouble
though it gets tedious. That, to me, is as important as reading source. You
can get a long way reading source; you can also get stuck and get bored and
convince yourself you understand something that you don’t.
Download at Boykma.Com
Brendan Eich
159
When I did JavaScript’s regular expressions I was looking at Perl 4. I did step
through it in the debugger, as well as read the code. And that gave me ideas;
the implementation I did was similar. In this case the recursive backtracking
nature of them was a little novel, so that I had to wrap my head around. It
did help to just debug simple regular expressions, just to trace the
execution. I know other programmers talk about this: you should step
through code, you should understand what the dynamic state of the
program looks like in various quick bird’s-eye views or sanity checks, and I
agree with that.
Seibel: Do you do that with your own code, even when you’re not tracking
down a bug?
Eich: Absolutely—just sanity checks. I have plenty of assertions, so if those
botch then I’ll be in the debugger for sure. But sometimes you write code
and you’ve got some clever bookkeeping scheme or other. And you test it
and it seems to work until you step through it in the debugger. Particularly if
there’s a bit of cleverness that only kicks in when the stars and the moon
align. Then you want to use a conditional break point or even a watch point,
a data break point, and then you can actually catch it in the act and check
that, yes, the planets are all aligned the way they should be and maybe test
that you weren’t living in optimistic pony land. You can actually look in the
debugger, whereas in the source you’re still in pony land. So that seems
important; I still do it.
Seibel: Is the way you discover a problem that you’re stepping through
looking at the source with your mental model of what’s about to happen,
and then you see it not happen?
Eich: You see it not happen, or—and this is my problem—I was in pony
land. I’m getting older and more skeptical and I’m doing better, but there’s
still something that I was optimistic about. In the back of my mind this Jiminy
Cricket is whispering, “You probably have a bug because you forgot about
something.” That kind of problem happens to me still.
And sometimes I know about it, I swear—somewhere in there I know I’m
wrong. I have this sort of itch in my hind-brain—well, not in my hind-brain; I
don’t know where it is; the microtubules. Anyway, I kind of feel like there’s
something that I should watch out for, and being in debugger helps me
Download at Boykma.Com
Brendan Eich
160
watch out for it and it helps me force the issue or see that the test vector,
though it covered the code in some sense, didn’t cover all the combinations,
because it’s a huge, huge hyperspace. And if you just change this one value
then you’d go into a bad place.
Seibel: In addition to reading code, lots of programmers read books about
programming—are there any books that you would recommend?
Eich: I should be a better student of the literature. But I think it’s sort of
like music in that you have to practice it. And you can learn a lot reading
other people’s code. I did like Brian Kernighan’s books; I thought they were
neat, because they would build up a small amount of code, and start reusing
it as you go, and modularizing. And Knuth's Art of Computer Programming,
Volumes 1–3, especially the seminumerical stuff. Double-hashing—I love
those parts. The lemma about the golden ratio with the proof left as an
exercise.
But I’m a little skeptical of book learning for programming. Programming is
partly engineering; there’s maybe some math on a good day. And then
there’s a lot of practical stuff that doesn’t even rise to the level of
engineering in the sense of civil engineering and mechanical engineering.
Maybe it’ll be formalized more over time.
There’s definitely a good corpus of knowledge. Computer science is a
science. I remember somebody on Usenet 20 years ago said, “Science lite,
one-third the rigor.” There’s still a lot of stuff that doesn’t look like it really
holds up over time—there are these publish-or-perish ten-page, ten-point-
font papers that often have holes in them. The journal publications are
better because you get to interact with the referee; it’s not just a truth or
dare. And they get reviewed more carefully. The areas of mechanized
proofs, that’s getting impressive. But it’s still not reaching programmers. So
there’s something a little bit missing in computer science in my view that
makes me skeptical of book learning. I should probably not go so far on this
Luddite track. But there it is.
There is science there, and there are important things to learn. You could
spend a lot of time studying them, too. I know a lot of people on the
theoretical side of it from work on JavaScript language development, and a
lot of them are hackers, too, which is good.Some of them don’t program.
Download at Boykma.Com
Brendan Eich
161
They’re not really practical people. They have amazing insights, which can
sometimes be very productive, but when you have to actually write
programs and ship them to users and have them be usable and have them
win some sort of market contest, you’re far removed from theory. But I am
interested in theory, and it does help improve our lives.
Seibel: There are other kinds of books too. There are books that
introduce you to the craft of programming, without a lot of theory.
Eich: And that’s the kind of book I like. We talked about Knuth’s literate
programming paper. And there was a whole area of programming as craft
that I like. I like the Smalltalk books. Now that I think about it, those were
pretty influential. The Adele Goldberg book. And before that, the Byte issue.
Seibel: With the hot-air balloon on the cover?
Eich: Yeah. That turned me around in a big way. That was big. That was like
’80 or so. So I wasn’t really doing a lot of programming then. I was thinking
about it and I was reading about it and I was playing around on this old iron
at undergraduate university. The purity of the Smalltalk environment, the
fact that it was so highly bootstrapped—all that really hit me in a way that
made me want to be involved in programming—languages and virtual
machines. Going into Unix was physical machines and operating systems,
and that was where the action was. But even then I was reading—there was
a Springer-Verlag book that had a bunch of papers, and people back then
were fantasizing about universal object file formats and Java byte-code,
essentially, before its time. But yes, Smalltalk was huge. I didn’t actually get
to use it until years later at U of I, when they finally released something that
ran on the Suns of the time and it was slow.
Seibel: On another topic, how do you recognize programming talent?
Eich: We hired somebody a while ago; he was a friend of one of the
superbrains we’d hired. But this was a guy who was, I think, just undergrad
or a bachelor’s degree; I’m not sure if he even finished. He met a guy who
was working for us and they’re both OCaml hackers, and he was doing his
own OCaml hacking on the side. And he was thinking about problems that
we were seeing in my static analysis. When we interviewed him, I knew he
was young but you couldn’t tell. Some people thought, “Oh, yeah, he hasn’t
Download at Boykma.Com
Brendan Eich
162
done much. You know, we should only hire rock stars; what are we talking
to him for?”
I said, “No, you guys are looking at this wrong. This is like one of our bright
interns. Get them while they’re young. He’s done a bunch by himself, he’s
gotten into OCaml; he knows not just the source language, but the runtime,
and he’s hacked native methods and he was writing an OCaml operating
system, toy operating system. But this guy is good.” And it wasn’t that I gave
him any particular programming test; it was just that I’d listened to him talk
about what he’d done and why he’d done it. He wasn’t just repeating
pabulum about C++ patterns. We have kids like that, unfortunately. Nice
people and adequate programmers, for what they were doing, Java
Enterprise stuff. But we needed somebody different, and this guy was
different.
So in the interview the main problem was overcoming people misreading his
age or thinking he wasn’t accomplished enough. But we hired him and he’s
just been a superstar. He’s done a bunch of static analysis tooling, originally
on this open-source Berkeley Oink framework, and then on GCC as plug-
ins, working with the GCC guys. Now he’s kicking our mobile effort into
high gear, just doing poor man’s profiling and
printf of timestamps and
finding out where the costs are and whacking them.
So when I interviewed him I knew there was talent. That he came
recommended from somebody bright was good, because you know bright
people like each other and can judge each other—generally there’s not a
dysfunctional, “Hire my friend, who’s really not bright.” They want to work
with bright people. Maybe this sounds like I’m cheating, but that’s one way I
recognize talent. And I think that’s why we’re hiring superhackers. I think
we’re hiring up all the Valgrind hackers. Some of those guys can do anything;
they don’t fuck around.
Seibel: So is that something you often do in interviews: get them to talk
about their own projects?
Eich: I do. I don’t give people puzzles to solve. We have people who do
that here. To the extent that we have to do that and we’re using that to
filter applicants, I worry.
Download at Boykma.Com
Brendan Eich
163
Seibel: Is that even a good first-pass filter?
Eich: I’m skeptical. Google does that in spades, and they hire a bunch of
very bright puzzle-solvers. But some of them, their street smarts are not
necessarily there, and mature judgment. So I’m skeptical of it. I think we
have to do it to some extent because you can end up getting someone who
talks well, but actually isn’t effective at programming, and so you want to
see them think on their feet, you want to see if they’ve solved a problem
before. So we give them fairly practical problems. Not esoteric puzzles or
math-y things, but more like programming problems.
Check their C++ knowledge, because C++ is hairy. So it’s sort of a sanity
check, not enough to say, “Let’s hire him.” But if they pass it, that’s good; if
they don’t, we worry. To say, “Let’s hire them,” we have to see something
else, and that’s the spark that involves particulars, like what they’ve done
and their approach and what languages they’ve used.
Maybe I’m also sympathetic to the odd duck. I don’t mind people who are a
little different. I don’t want to hire somebody who’s hard to work with, but
we need talent. We need people who think differently.
When I was an undergrad I was really affected by Pirsig’s Zen and the Art of
Motorcycle Maintenance. And I had been going through Plato and the early
philosophers. I was, at that point, inclined more towards idealism in some
philosophical sense. I thought little-endian byte order was superior to big-
endian, because after all, the least significant digits are in the lowest
address—there was some kind of harmony or geometry in that. But try
reading a hex dump. Practical things matter; particulars matter. The famous
School of Athens painting with Aristotle pointing down and Plato pointing
up—I’m more on the pointing-down side now. As I get older I get more and
more skeptical and more and more interested in what works.
When I’m interviewing people, when I’m looking for talent, it’s very hard for
me to not stick with particulars and practicalities. OK, so this guy knew
OCaml—it meant he was smart, but should we hire him? Well no, but he
also did things on his own and he thought on his feet when I talked to him,
and he was already thinking about compilation or analysis problems that we
were going to hire him to work on. But maybe the important thing there,
Download at Boykma.Com
Brendan Eich
164
the real story, was the network we were going through, the guy we hired,
he was his friend.
Seibel: Do you still enjoy programming?
Eich: Yeah. It’s a bit like an addiction; it’s a little problematic. It’s not just
the programming part of getting the code to run; to me now it’s more and
more finding the right idea that has the New Jersey philosophy of a 90/10
trade-off—a sweet, sound theoretical core that isn’t going to solve all your
problems but when you fall on the 10 percent that loses, you don’t go to
hell. You can actually win this way and the code stays small enough and
simple enough and there’s some dance between theory and implementation.
I like that. That still appeals to me; it still is fun; it keeps me up at night
thinking about it when I should be sleeping.
Seibel: Are there parts of it that you don’t enjoy as much anymore?
Eich: I don’t know. C++. We’re able to use most of its features—there are
too many of them. It’s probably got a better type system than Java. But
we’re still screwing around with ’70s debuggers and linkers, and it’s stupid. I
don’t know why we put up with it.
Impatience and hatred of primitive tools drives me to try to be a better
programmer. Our code is riddled with assertions now and they are fatal.
That’s important to us. But this is something that has helped me, especially
when I’m doing one of these allegedly sound, 90/10, sweet trade-off moves
on the code that doesn’t quite satisfy all the invariants. I forget something;
an assertion will botch and then it’s like, bing, I know what to fix.
Also I’m even now learning about my own weaknesses, where I’ll optimize
something too much. I’ll have made some kind of happy pony land in my
head, where I forgot some important problem. That’s always a challenge
because programmers have to be optimists. We’re supposed to be
paranoid, neurotic, Woody Allen types who are always worried about
things, but really you wouldn’t get anywhere in programming if you were
truly paranoid.
Seibel: Do you feel at all that programming is a young person’s game?
Download at Boykma.Com