Seibel Peter. Coders at Work
Подождите немного. Документ загружается.
Douglas Crockford
95
Seibel: And Habitat started while you were there.
Crockford: It sure did. A friend of mine, Chip Morningstar, started that
project. He invented the avatar; he invented the graphical virtual world. He
did all that stuff first. It ran on Commodore 64s and off-peak x25 networks.
Just amazing foresight in the design of that thing—he got so much right, It
was amazing. I was sort of a spectator. I saw them doing it and encouraged
them. But I can’t take any credit for what they did.
Seibel: And then you went with them to found Electric Communities,
which built upon those ideas?
Crockford: Right. Morningstar and Randy Farmer left Lucasfilm to start a
company called the American Information Exchange, which took their idea
of a social server and applied it to the idea of online markets. Brilliant idea,
but ahead of their time. Had they been a little bit later, they could have
been eBay.
Then we got the idea of well, let’s do that again and come up with a
common platform which does the entertainment thing and the social thing
and the business thing and the commercial thing and everything and we’ll do
the platform for the whole world. And we had some ideas about how to
make it fully distributed so that there is no single server—that it all spreads
over the Net. And we would come up with security models that would
allow it to be fully decentralized. It was a really powerful idea and that was
the idea behind Electric Communities.
Seibel: And that’s where the first versions of E came from.
Crockford: Right. We needed a secure programming language to develop
the platform and the applications in. And our first attempt at that was
something called Joule which was being developed at another company
called Agorics. Joule was an actor language and was pretty odd in the way
that it did things—it was brilliant but unconventional.
We had concerns about Joule. Were we going to be able to get people to
use this language; is it too freaky? Then we came up with the idea of E,
which was taking the core actor concepts out of Joule and reimplementing
them on top of Java.
Download at Boykma.Com
Douglas Crockford
96
Seibel: Did E ever have any adoption by anyone other than its inventors?
Crockford: Not the original language. The old E was a Java dialect. We had
all sorts of problems with Sun about that. We then came up with an E
scripting language that was lighter but had similar properties. And that is the
language which is now called E.
We developed that language at Electric Communities but I don’t think we
ever made use of it. But at one point we decided that we weren’t using it,
but it was good stuff so we spun it out and I’m really happy to see that it
survived.
One of the things that was good for me in being at Electric Communities is
it taught me to think in terms of closures. So when I started doing web stuff
I looked at JavaScript and said, “There’s something familiar about this.”
Because a lot of JavaScript’s heritage comes from Scheme but you look at
the documentation and there’s nothing there that tells you that there are
closures in the language. So I kind of discovered it by accident and went,
“Whoa! This is great.” And I’ve been promoting that idea that you can
actually do serious programming in this silly little language.
Seibel: So that sort of brings us to the recent controversy about
ECMAScript 4. I gather that you like the simplicity of the ES3 version of
JavaScript.
Crockford: Well, ultimately, the significance of the changes you can make
to a language is related to the success of the language. The more successful
the language is, the greater the cost of changing it. You have greater re-
education costs and you have the potential costs of disruption which, as you
become bigger, become unacceptable. When you’re really successful, you
need to be extremely cautious in any changes that you make. Whereas if
you haven’t made it yet, you have a lot more freedom in changing it around.
JavaScript, purely by accident, has become the most popular programming
language in the world. There are more JavaScript processors in the world
than any other language by far. And for all of its problems with its security
model, JavaScript is the only language where you can write code and run it
on any machine.
Download at Boykma.Com
Douglas Crockford
97
And if that weren’t enough, it’s now being embedded in a lot of applications.
Most of the Adobe applications have JavaScript in them so you can script
them locally. And other applications as well. So it’s become hugely popular.
The problem with the language is that it was rushed to market way too fast
and standardized way too fast. So most of its defects are not in the current
implementations—they are in the specification. The standard says do this
incorrectly. Which is appalling. But that’s the state of it. It got frozen in 1999
and then should have gone into neglect and died. But instead, by accident,
Ajax happened and suddenly it’s the world’s most important programming
language.
So now we’re thinking that we need to fix it. But the time to have fixed it
should have been in 2000. But it didn’t get fixed then, back when everyone
was paying no attention to it. Now it’s huge.
There’s another thing that’s odd about JavaScript in the web context: If
you’re doing a server application or a desktop application or an embedded
application, you get to choose not only the language but which specific
compiler you’re going to use, which specific runtime you’re going to use.
You don’t get that choice in JavaScript. You have to run on everything that’s
out there.
Because we have to run on everything, bugs don’t get fixed. If a browser
maker ships a bug and goes, “Oops, we screwed up,” and the next month
they ship another one, we cannot depend on all of their users doing the
upgrade. The mainstream, once they get IE installed on their machine, that’s
it; they don’t upgrade. Those bugs stay there for years.
Seibel: So that’s the current situation. Yet you want the Web to be a
better platform for developing applications. If we can’t fix the problems we
have unless all the browsers fix it and even that doesn’t help, we’re just
stuck. What’s the way forward?
Crockford: That’s the thing I struggle with. I can see the ideal. I know what
it needs to be. And I know where we are and I can see all the obstructions
in the way. And so I’m trying to figure out how do we take this forward.
We’re in a trap, in a sense, in that we have developed these huge systems—
I’m more concerned with the economic systems and the social systems, but
Download at Boykma.Com
Douglas Crockford
98
also the technological systems—that are dependent on this system which
was not thought through very well.
The worst feature of JavaScript, without question, is its dependence on a
global object. It doesn’t have linkers, it doesn’t have any kind of information
hiding between compilation units. It all gets dumped together into a
common global object. So all the components see everything else; all the
components have equal access to the DOM; they all have equal access to
the network. If any script gets onto your page it can go to the server and
represent itself as your script and there’s absolutely no way the server can
tell the difference.
It has access to the screen; it can go to the user and represent itself as your
script and the user can’t tell the difference. All of the new antiphishing
things that they’re putting in the chrome don’t work if the page came from
your server and all scripts come with the same authority no matter where
they came from.
But it’s even worse than that because there are other ways that script can
get onto your page. The architecture of the Web has several languages in
it—there’s HTTP, there’s HTML, URLs are a language, there’s CSS, and
there’s the scripting language. They’re all in there and they can all be
embedded in each other and they all have different quoting and escaping and
commenting conventions. And they are not consistently implemented in all
of the browsers. Some of them are not specified anywhere. So it’s really
easy for an evildoer to take some script and put it in a URL, put it in a piece
of style and put that in some HTML and put that in another script, and so
on.
Seibel: Those are the classic cross-site scripting attacks, taking advantage of
bugs in the browser.
Crockford: Right. That’s horrible; we have to fix that—it’s intolerable that
we keep going this way.
On top of that we’ve discovered mash-ups. And mash-ups realize something
that we’ve been trying to do in software for 20 years: to have interesting
reusable components that we can snap together like LEGO and make new
applications out of, instantly. And we’re doing that stuff in mash-ups and it’s
Download at Boykma.Com
Douglas Crockford
99
brilliant, where you can take something from Yahoo and something from
Google and something of yours and something of someone else’s and put
them all together and make an application, and it’s great. And it all happens
on the browser, right in front of your eyes. Except that each of those
components has access to the same stuff. So now we are intentionally
creating XSS exploits. And the browser’s security model did not anticipate
any of this goodness and does not provide any way of allowing for
cooperation with mutual suspicion. The whole Web is built on one mistake
after another. We have this big pile of accidents.
Seibel: So given all that, is the cost of the ES4 effort just the opportunity
cost, that everyone is going to spend time thinking about that instead of
some way to fix these problems?
Crockford: Right. It’s solving the wrong problem. It’s solving the problem
that people hate JavaScript. And I can appreciate Brendan Eich’s position
there because he did some brilliant work but he rushed it and he was
mismanaged and so bad stuff got out. And he’s been cursed and vilified for
the last dozen years about how stupid he is and how stupid the language is
and none of that’s true. There’s actually brilliance there and he’s a brilliant
guy. So he’s now trying to vindicate himself and prove, I’m really a smart guy
and I’m going to show it off with this language that has every good feature
I’ve ever seen and we’re going to put them all together and it’s going to
work.
I don’t think that’s the problem we need to be solving right now. I think the
problem we need to be solving is: The Web is broken and we need to fix it.
So we need to figure out a way to go forward. And my biggest objection
with what Brendan is trying to do is it’s a distraction.
I’m looking at this stuff incrementally. If we can get a module; if we can get a
choice of programming language, we’ve gone way forward. We’re still not
done yet, but we’re in much better shape than we are now. Then there are
things like Caja and ADsafe which are trying to do that using today’s
technology. We can’t wait.
What ADsafe does is it creates a safe subset of JavaScript. So it disallows
access to anything that’s global and anything that’s dangerous. And it turns
out there’s still a useful language in that subset. Because all the lambda
Download at Boykma.Com
Douglas Crockford
100
power is there. And lambdas can do a lot. So it’s an unconventional language
because it doesn’t let you use prototypes in the way we have up until now.
But it’s a full lambda language, so hugely powerful.
Seibel: Leaving aside that it may be solving the wrong problem, are there
any bits of ES4 that you like, just from a language point of view?
Crockford: There are some bug fixes that are good that I think we should
have. But there’s too much stuff in the language that hasn’t been tried. And
our experience with ES3 is that once an error gets into the spec, it’s
impossible to take it out. And we have no experience with this language. No
one has ever written a big application with it.
It will be standardized and deployed before we know that it works. So I
think we’re doing this way too fast. I’d be much more comfortable if we had
multiple reference implementations and people doing useful applications
with it and then go, OK, the language seems to work; now let’s standardize
it, now let’s deploy it worldwide. I think we’re doing it all backwards.
Seibel: So Google’s GWT compiles Java into JavaScript. And other folks
have played around with compiling other languages to JavaScript. Is that a
path forward?
Crockford: It’s sort of interesting to see JavaScript turning into the
universal runtime. That’s not a role we ever expected for it.
Seibel: But, as you said, it’s everywhere; it is the universal runtime.
Crockford: Which I think puts even more pressure on getting JavaScript to
go fast. Particularly as we’re now going into mobile. Moore’s law doesn’t
apply to batteries. So how much time we’re wasting in interpreting stuff
really matters there. The cycles count. So I think that’s going to put more
pressure on improving the quality of the runtime.
As far as GWT goes, and other transforming things, I’m really pragmatic.
This environment is so hard to work in—if you can find something that
works, then great. I’m fearful of using it myself because I worry about the
abstraction leakage. If there’s a problem in your Java code or in GWT or in
what it produces on the other side, you may or may not have a place to
Download at Boykma.Com
Douglas Crockford
101
stand to deal with that. Particularly if you took the approach that you can
afford to be completely ignorant about JavaScript because the language is
hidden from you. Then you’re going to be in a world of hurt if anything goes
wrong. I hadn’t heard of that happening to anybody, so so far they appear to
be doing it right. But there is that risk.
Seibel: What would you like to see happen with JavaScript?
Crockford: I think the best way to make JavaScript better would be to
make it smaller. If we could just get it down to what it does really well and
remove the features that add little or no value, it’s actually a better
language. And I think we can take that approach to HTML; I think we can
take that approach to HTTP and to CSS. I think all of the standards that
we’re working with, we need to figure out what do they do right and what
is it missing and refocus them, rather than just piling new features on top.
Seibel: Yet there’s often a tension between small, elegant jewels and
sprawling, practical balls of mud. A small, perfect jewel is easy to understand
and it doesn’t have warts but then you have to build more stuff on top of it
to do anything. So everybody reimplements the same things over and over
and that leads to a different kind of bloat and ugliness.
Crockford: But that’s not what’s happening. We have a number of Ajax
library developers who are doing that and some of them are getting very
sophisticated in their use of the language. And then the communities out
there are building sloppy stuff on top of it and that’s working. So it’s not
necessary for every application programmer to understand how to fully
exploit lambda in order to take advantage of the lambda nature of the
language. So we’re already doing that. We don’t need to abandon the
language in order to fix that—that’s not where it’s broken.
Where we do have a problem there is that there are too many Ajax
libraries. That was a consequence of the fact that JavaScript is so powerful
and the need is so profound and that they’re easy to make. So for a while
everybody was making them. I’ve been expecting that we’re going to have a
shake-out but it hasn’t happened yet. So we still have a whole lot of
libraries. So we have an alternative problem now—because there are so
many libraries to choose from, developers don’t know which one to use. I
think there will be a shake-out eventually.
Download at Boykma.Com
Douglas Crockford
102
One thing that we’re seeing now is that the Ajax libraries are converging.
jQuery came up with a notation for using CSS selectors for getting a list of
objects from the DOM and then providing methods for manipulating the
objects en masse. And that turns out to be a really good idea and it’s
something that JavaScript does very effectively. There’s an inefficiency there
in that the interface to the DOM is horrible but they hide it all. They’ve
really simplified the programming model—it’s brilliant.
So everybody’s doing that now—we’re seeing feature convergence. Which
makes the problem even harder for the user community because it makes it
harder to decide which library to use because they’re all becoming more
similar. But eventually they’re going to coalesce down to a couple, maybe
one. I had been predicting that one of the winners was going to be
Microsoft with their Atlas framework, just because Microsoft is always one
of the winners. But they don’t appear to be getting traction. The open
frameworks seem to be doing much better. So I’m expecting one or two of
the open frameworks will ultimately win.
Seibel: These days you’re a JavaScript architect and evangelist here at
Yahoo!, so part of your job, presumably, is to tell Yahoo! JavaScript
programmers, “Here’s how you should do it.” Does your job also cover
general good design practice and good coding practice?
Crockford: One of the things I’ve been pushing is code reading. I think that
is the most useful thing that a community of programmers can do for each
other—spend time on a regular basis reading each other’s code. There’s a
tendency in project management just to let the programmers go off
independently and then we have the big merge and if it builds then we ship
it and we’re done and we forget about it.
One of the consequences of that is that if you have weak or confused
programmers you’re not aware of their actual situation until much too late.
And so the risks to the project, that you’re going to have to build with stuff
that’s bad and the delays that that causes, that’s unacceptable. The other
thing is that you may have brilliant programmers on the project who are not
adequately mentoring the other people on the team. Code reading solves
both of those problems.
Seibel: Can you talk a bit about how you conduct a code reading?
Download at Boykma.Com
Douglas Crockford
103
Crockford: At each meeting, someone’s responsible for reading their code,
and they’ll walk us through everything, and the rest of us will observe. It’s a
really good chance for the rest of the team to understand how their stuff is
going to have to fit with that stuff.
We get everybody around the table; everybody gets a stack of paper. We
also blow it up on the screen. And we all read through it together. And
we’re all commenting on the code as we go along. People say, “I don’t
understand this comment,” or, “This comment doesn’t seem to describe the
code.” That kind of stuff can be so valuable because as a programmer you
stop reading your own comments and you’re not aware that you’re
misdirecting the reader. Having the people you work with helping to keep
your code clean is a huge service—you find defects that you never would’ve
found on your own.
I think an hour of code reading is worth two weeks of QA. It’s just a really
effective way of removing errors. If you have someone who is strong
reading, then the novices around them are going to learn a lot that they
wouldn’t be learning otherwise, and if you have a novice reading, he’s going
to get a lot of really good advice.
And it shouldn’t be something that we save for the end. Back in the old
days, we would schedule a code reading just as we were finishing a project
and usually it would be canceled because we were late. I now believe that
code reading should be happening all the time throughout the life of the
project. That’s something that took me a while to figure out but there are
so many benefits that come from that.
For one thing it makes it easier to track the project, because we can actually
see what progress people are making. And we can see much sooner if
they’re going off the rails or not.
I’ve managed projects where we’re up against a deadline and we had people
saying, “Yeah, I’m almost done,” and then you get the code, and there’s
nothing there, or it’s crap, or whatever, and they’re nowhere close to done.
In management, those are the experiences you hate the most and I think
code reading is the best way of not getting trapped like that.
Download at Boykma.Com
Douglas Crockford
104
Seibel: So say we’re doing a code reading of some of my code. I bring
printouts and we put it up on the screen. Then what? Do I literally read it
out loud?
Crockford: Yeah, go through it line by line, and you’ll be doing
commentary on it. This is what’s supposed to be happening here. If we have
time, we’ll go line by line.
Seibel: Do you find that you have to teach people how to do code
readings? I can imagine it’d be hard to find the right balance of being critical
enough to be worthwhile without making the code’s author feel personally
attacked.
Crockford: Yeah, it requires a lot of trust on the part of the team
members so there have to be clear rules as to what’s in bounds and what’s
not. If you had a dysfunctional team, you don’t want to be doing this,
because they’ll tear themselves apart. And if you have a dysfunctional team
and you’re not aware of it, this will reveal it pretty quickly. There’s a lot that
you can learn, a lot that’s revealed by this process. It feels unnatural at first,
although once you get into the rhythm of it, it feels extremely natural.
Another aspect is writing your code such that it can be read. Neatness
counts, as it turns out, and style is important. And all of those things will
increase the quality of the code base going forward and increase the
competence of the programming community.
Seibel: What makes code readable for you?
Crockford: It happens at a number of levels. The simplest is just being
consistent in the presentation so you always indent everything properly; you
have white space in all the right places. One habit that I still struggle with,
something I learned back in the Fortran days, is I tend to use too many one-
letter variable names, which I believe is a bad thing. And I’m trying really
hard to break it, but it’s difficult—it’s still something I struggle with.
Seibel: How hard is it? Do you write the code and then you come back
later and say, “Oh, look at all these one-character variable names.”?
Download at Boykma.Com