Seibel Peter. Coders at Work
Подождите немного. Документ загружается.
Brendan Eich
135
programmers who’ve actually been down to bit-banging level versus the
ones who’ve been shielded all their lives.
I also was interested in C and Unix but we were only just getting into it
with this old DEC iron. We had the Portable C Compiler yacc-based mess
and we were just starting to generate code and play around with Unix utility
porting. Since physics wasn’t getting me summer jobs and I was doing a lot
of hacking and being a lab assistant I ended up switching in my senior year to
math/computer science, and that’s what I got my undergraduate degree in.
Seibel: What was the first interesting program that you remember writing?
Eich: This is going to be embarrassing. There was a terrible graphics
terminal DEC made; it was like an evolution of VT100 because it
understood the escape sequences, but it also had some pathetic color depth
and some sort of early ’80s resolution. So I started writing game knockoffs
for it: Pac-Man, Donkey Kong. I wrote those games in Pascal and they
emitted escape sequences. But it was kind of hobby programming that grew
and grew. I think that was the first nontrivial programming I did where I had
to think about modularity and protecting myself.
This was while I was a physics major, probably third year. Fourth year I
became math/computer science and I was starting to study formal languages
and write parser generators. So those were the kinds of programs I wrote:
either games or serious nerd parser generator type programs. Then I
started thinking about compilers and writing macro processor knock offs,
like m4 knockoffs or CPP knockoffs. I remember when we got some version
of the Unix source and reading some of the really crufty C code. The John
Reiser C preprocessor—probably the original—was just an amazing mess. It
was very efficient; it was using a global buffer and it was a huge pointer stew,
and it would try to avoid copying. I thought, “There has to be a better way
to do this.”
So that’s how I ended up getting out of physics and into computer science
and programming. I wasn’t really programming before that; it was all math
and science. My parents didn’t let me get an Apple II. I tried once. I didn’t
beg but I was saying, “I could learn a foreign language with this,” which was a
complete smoke screen. “No. You’ll probably waste time playing games.”
And they were right. So they saved me from that fate.
Download at Boykma.Com
Brendan Eich
136
Seibel: Other than providing more summer employment than physics, what
about programming drew you in?
Eich: The connection between theory and practice, especially at the front
end of the compiler construction process, was attractive to me. Numerical
methods I didn’t get into too much. They’re less attractive because you end
up dealing with all sorts of crazy trade-offs in representing real numbers as
finite precision floating-point numbers and that’s just hellish. It still bites
JavaScript users because we chose this hardware standard from the ’80s and
it’s not always operating the way people expect.
Seibel: Because, like the Spanish Inquisition, no one really expects floating
point.
Eich: No one expects the rounding errors you get—powers of five aren’t
representable well. They round badly in base-two. So dollars and cents,
sums and differences, will get you strange long zeros with a nine at the end
in JavaScript. There was a blog about this that blamed Safari and Mac for
doing math wrong and it’s IEEE double—it’s in everything, Java and C.
Physics was also less satisfying to me because it has kind of stalled. There’s
something not quite right when you have these big inductive theories where
people are polishing corners and inventing stuff like dark energy, which is
basically unfalsifiable. I was gravitating toward something that was more
practical but still had some theoretical strength based in mathematics and
logic.
Then I went to University of Illinois Champaign-Urbana to get a master’s
degree, at least. I was thinking of going all the way but I got stuck in a
project that was basically shanghaied by IBM. They had a strange 68020
machine they had acquired from a company in Danbury, Connecticut, and
they ported Xenix to it. It was so buggy they co-opted our research project
and had us become like a QA group. Every Monday we’d have the blue suit
come out and give us a pep talk. My professors were kind of supine about it.
I should’ve probably found somebody new, but I also heard Jim Clark speak
on campus and I pretty much decided I wanted to go work at Silicon
Graphics.
Seibel: What were you working on at SGI?
Download at Boykma.Com
Brendan Eich
137
Eich: Kernel and networking code mostly. The amount of language
background that I used there grew over time because we ended up writing
our own network-management and packet-sniffing layer and I wrote the
expression language for matching fields and packets, and I wrote the
translator that would reduce and optimize that to a short number of mask-
and-match filters over the front 36 bytes of the packet.
And I ended up writing another language implementation, a compiler that
would generate C code given a protocol description. Somebody wanted us
to support AppleTalk in this packet sniffer. It was a huge, complex grab bag
of protocol syntax for sequences and fields of various sizes and dependent
types of . . . mostly arrays, things like that. It was fun and challenging to
write. I ended up using some of the old Dragon book—Aho and Ullman—
compiler skills. But that was it. I think I did a unifdef clone. Dave Yost had
done one and it didn’t handle
#if expressions and it didn’t do expression
minimization based on some of the terms being pound-defined or undefined,
so I did that. And that’s still out there. I think it may have made its way into
Linux.
I was at SGI from ’85 to ’92. In ’92 somebody I knew at SGI had gone to
MicroUnity and I was tired of SGI bloating up and acquiring companies and
being overrun with politicians. So I jumped and it was to MicroUnity, which
George Gilder wrote about in the ’90s in Forbes ASAP as if it was going to be
the next big thing. Then down the memory hole; it turned into a $200
million crater in North Sunnyvale. It was a very good learning experience. I
did some work on GCC there, so I got some compiler-language hacking. I
did a little editor language for MPEG2 video where you could write this
crufty pseudospec language like the ISO spec or the IEC spec, and actually
generate test bit streams that have all the right syntax.
Seibel: And then after MicroUnity you ended up at Netscape and the rest
is history. Looking back, is there anything you wish you had done differently
as far as learning to program?
Eich: I was doing a lot of physics until I switched to math and computer
science. I was doing enough math that I was getting some programming but I
had already studied some things on my own, so when I was in the classes I
was already sitting in the back kind of moving ahead or being bored or doing
Download at Boykma.Com
Brendan Eich
138
something else. That was not good for personal self-discipline and I probably
missed some things that I could’ve studied.
I’ve talked to people who’ve gone through a PhD curriculum and they
obviously have studied certain areas to a greater depth than I have. I feel
like that was the chance that I had then. Can’t really go back and do it now.
You can study anything on the Internet but do you really get the time with
the right professor and the right coursework, do you get the right
opportunities to really learn it? But I’ve not had too many regrets about
that.
As far as programming goes, I was doing, like I said, low-level coding. I’m not
an object-oriented, design-patterns guy. I never bought the Gamma book.
Some people at Netscape did, some of Jamie Zawinski’s and my nemeses
from another acquisition, they waved it around like the Bible and they were
kind of insufferable because they weren’t the best programmers.
I’ve been more low-level than I should’ve been. I think what I’ve learned
with Mozilla and Firefox has been about more test-driven development,
which I think is valuable. And other things like fuzz testing, which we do a
lot of. We have many source languages and big deep rendering pipelines and
other kinds of evaluation pipelines that have lots of opportunity for memory
safety bugs. So we have found fuzz testing to be more productive than
almost any other kind of testing.
I’ve also pushed us to invest in static analysis and that’s been profitable,
though it’s fairly esoteric. We have some people we hired who are strong
enough to use it.
Seibel: What kind of static analysis?
Eich: Static analysis of C++, which is difficult. Normally in static analysis
you’re doing some kind of whole-program analysis and you like to do things
like prove facts about memory. So you have to disambiguate memory to find
all the aliases, which is an exponential problem, which is generally infeasible
in any significant program. But the big breakthrough has been that you don’t
really need to worry about memory. If you can build a complete control-
flow graph and connect all the virtual methods to their possible
implementation, you can do a process of partial evaluation over the code
Download at Boykma.Com
Brendan Eich
139
without actually running it. You can find dead code and you can find
redundant tests and you can find missing null tests.
And you can actually do more if you go to higher levels of discourse where
we all operate, where there’s a proof system in our head about the program
we’re writing. But we don’t have a type system in the common languages to
express the terms of the proof. That’s a real problem. The Curry-Howard
correspondence says there’s a correspondence between logic systems and
type systems, and types are terms and programs are proofs, and you should
be able to write down these higher-level models that you’re trying to
enforce. Like, this array should have some constraint on its length, at least
in this early phase, and then after that it maybe has a different or no
constraint. Part of the trick is you go through these nursery phases or other
phases where you have different rules. Or you’re inside your own
abstraction’s firewall and you violate your own invariants for efficiency but
you know what you’re doing and from the outside it’s still safe. That’s very
hard to implement in a fully type-checked fashion.
When you write Haskell programs you’re forced to decide your proof
system in advance of knowing what it is you’re doing. Dynamic languages
became popular because people can actually rapidly prototype and keep this
latent type system in their head. Then maybe later on, if they have a
language that can support it, or if they’re recoding in a static language, they
can write down the types. That was one of the reasons why in JavaScript we
were interested in optional typing and we still are, though it’s controversial
in the committee. There’s still a strong chance we’ll get some kind of hybrid
type system into a future version of JavaScript.
So we would like to annotate our C++ with annotations that conservative
static analysis could look at. And it would be conservative so it wouldn’t fall
into the halting-problem black hole and take forever trying to go
exponential. It would help us to prove things about garbage-collector safety
or partitioning of functions into which control can flow from a script,
functions from which control can flow back out to the script, and things to
do with when you have to rematerialize your interpreter stack in order to
make security judgments. It would give us some safety properties we can
prove. A lot of them are higher-level properties. They aren’t just memory
safety. So we’re going to have to keep fighting that battle.
Download at Boykma.Com
Brendan Eich
140
Seibel: So that’s a very high-level view of programming. How close to the
metal do you think programmers today need to be able to go? If someone is
going to be writing most of their applications in JavaScript, is it still
important that they grok assembly?
Eich: I know a lot of JavaScript programmers who are clever programmers,
and the best ones have a good grasp of the economics. They benchmark and
they test as they go and they write tight JavaScript. They don’t have to know
about how it maps to machine instructions.
A lot of them are interested in that when they hear about these JITing,
tracing VMs that we’re building. And we’re getting more and more people
who are pushing pixels. If you give people enough programming-language
performance and enough pixel-pushing power I think JavaScript
programmers will start using JavaScript at a lower level. And machine
economics or the virtual-machine economics—what really matters? Maybe
it’s the virtual-machine economics.
Abstraction is powerful. What I’m really allergic to, and what I had a bad
reaction to in the ’90s, was all the CORBA, COM, DCOM, object-oriented
nonsense. Every startup of the day had some crazy thing that would take
200,000 method calls to start up and print “hello, world.” That’s a travesty;
you don’t want to be a programmer associated with that sort of thing. At
SGI, the kernel, of course, was where the real programmers with chest hair
went, and there you couldn’t screw around. Kernel
malloc was a new thing;
we still used fixed-sized tables, and we panicked when we filled them up.
Staying close to the metal was my way of keeping honest and avoiding the
bullshit, but now, you know, with time and better, faster hardware and an
evolutionary winnowing process of good abstractions versus bad, I think
people can operate above that level and not know assembly and still be
good programmers and write tight code.
Seibel: Do you think, conversely, that the people who, back in the day,
could write intricate, puzzle-box assembly code, would be just as great
programmers in today’s world doing high-level programming? Or does that
kind of programming require different skills?
Download at Boykma.Com
Brendan Eich
141
Eich: I would say for certain aspects of programming there is a
correspondence between the two. There’s a difference between raw
pointers and this happy, fun JavaScript world. That kind of still separates the
chest hair—gender-independent—programmers from those who don’t
quite have it.
Keeping it all in your head is important. Obviously people have different-
sized heads. Somebody with a big head could keep track of higher-level
invariants in a memory-safe architecture and not have to worry about
pointers. But there’s something still that bothers me if over time we lose
the ability to write to the metal. Somebody’s doing it; the compiler is
generating the code. The compiler writers have to be doing a better job
over time.
Seibel: So there will always be a place for that kind of programming. But
are there people who can be successful programmers now who just
couldn’t when all programming was low-level hacking? Or is there one fixed
population of people who have the right kind of brain for programming and
now they’re split with some people doing low-level stuff and some people
doing high-level stuff?
Eich: I haven’t hacked kernel code in a long time, so I would have to go for
there’s some ability to migrate. There’s more code to write. And sound
abstractions give you leverage over problems you couldn’t address before.
Seibel: Let’s go back to those ten days when you implemented the original
JavaScript. I know that at some point someone had turned you on to
Abelson and Sussman and your original idea was to put Scheme in the
browser.
Eich: The immediate concern at Netscape was it must look like Java. People
have done Algol-like syntaxes for Lisp but I didn’t have time to take a
Scheme core so I ended up doing it all directly and that meant I could make
the same mistakes that others made.
I didn’t have total dynamic scope, like Stallman insisted was somehow
important for Emacs and infested Elisp with. JavaScript has mostly lexical
scope with some oddness to it—there are a few loopholes that are pretty
much dynamic: the global object, the
with statement, eval. But it’s not like
Download at Boykma.Com
Brendan Eich
142
dollar variables in Perl before my or upvar, uplevel in Tcl. The ’90s was full
of that—it was trendy.
But I didn’t stick to Scheme and it was because of the rushing. I had too
little time to actually think through some of the consequences of things I
was doing. I was economizing on the number of objects that I was going to
have to implement in the browser. So I made the global object be the
window object, which is a source of unknown new name bindings and
makes it impossible to make static judgments about free variables. So that
was regrettable. Doug Crockford and other object-capabilities devotees are
upset about the unwanted source of authority you get through the global
object. That’s a different way of saying the same thing. JavaScript has
memory-safe references so we’re close to where we want to be but there
are these big blunders, these loopholes.
Making those variables in the top level actually become mutable properties
of an object that you can alias and mess around with behind the back of
somebody—that’s no good. It should’ve been lexical bindings. Because if you
go down from there into the functions and nested functions, then it is much
more Scheme-like. You don’t quite have the rich binding forms, the fluid lets
or whatever; you have more like set-bang. But the initial binding you create
with a local variable is a lexical variable.
Seibel: So basically now people make a top-level function to get a
namespace.
Eich: Yeah. You see people have a function and they call it right away. It
gives them a safe environment to bind in, private variables. Doug’s a big
champion of this. It was not totally unknown to the Schemers and Lispers
but a lot of JavaScript people had to learn it and Doug and others have done
a valuable service by teaching them. It’s not like you’re getting everybody to
be high-quality Scheme programmers, unfortunately, but to some extent
they’ve succeeded, so people now do understand more functional idioms at
some patterny level, not necessarily at a deep level.
Seibel: So that’s the JavaScript that’s been out there for over a decade. And
now there’s this big renaissance due to Ajax. So folks say, “OK, we really
need to take another look at this.” You recently went through the drama of
the ECMAScript 4 proposal and the competing ECMAScript 3.1 proposal
Download at Boykma.Com
Brendan Eich
143
and now things seem to have settled down with the “Harmony” plan for
unifying the two. Was the ES4 proposal your chance to show the world
that, “Look, I’m a really smart guy and JavaScript is a really a good
language”?
Eich: No, I don’t think so. I know Doug may think that. I don’t think Doug
knows me that well, but the thing is, I’m not really looking for respect,
especially from the Java-heads or the trailing edge.
Seibel: Was ES4 your brainchild? Was it your take on, knowing all that you
know now, what you want JavaScript to be?
Eich: No. It was definitely a collaborative effort and in some ways a
compromise because we were working with Adobe, who had done a
derivative language called ActionScript. Their version three was the one that
was influencing the fourth-edition proposals. And that was based on
Waldemar Horwat’s work on the original JavaScript 2/ECMAScript fourth-
edition proposals in the late ’90s, which got mothballed in 2003 when
Netscape mostly got laid off and the Mozilla foundation was set up.
Waldemar did a good job—I gave him the keys to the kingdom in late ’97
when I went off to found mozilla.org with Jamie. Waldemar is a huge
brain—I think he won the Putnam in ’87. MIT PhD. He did try and keep the
dynamic flavor of the language, but he struggled to add certain
programming-in-the-large facilities to it, like namespaces.
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.
Download at Boykma.Com
Brendan Eich
144
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.
Download at Boykma.Com