Seibel Peter. Coders at Work
Подождите немного. Документ загружается.
Guy Steele
355
want to write in C++ now could be done about as well and more easily in
Java. Unless efficiency were the primary concern.
But I don’t want to be seen as a detractor of Bjarne Stroustrup’s effort. He
set himself up a particular goal, which was to make an object-oriented
language that would be fully backwards-compatible with C. That was a
difficult task to set himself. And given that constraint, I think he came up
with an admirable design and it has held up well. But given the kinds of goals
that I have in programming, I think the decision to be backwards-compatible
with C is a fatal flaw. It’s just a set of difficulties that can’t be overcome. C
fundamentally has a corrupt type system. It’s good enough to help you avoid
some difficulties but it’s not airtight and you can’t count on it.
Seibel: Do you think languages are getting better? You keep designing
them, so hopefully you think it’s a worthwhile pursuit. Is it easier to write
software now because of advances that we’ve made?
Steele: Well, it’s much easier now to write the kinds of programs we were
trying to write 30 years ago. But I think our ambitions have grown
tremendously. So I think programming is probably a more difficult activity
than it was 30 years ago.
Seibel: And what are the things that are making it more difficult?
Steele: I think we’ve got people now who are just as smart as the people
we had 30 years ago and they are being pushed to the limits of their abilities
as people were 30 years ago—I’ve chosen 30 years ago as an arbitrary
baseline because that’s when I got out of school. But the difference is that—
as I remarked earlier—it’s not possible to understand everything that’s
going on anymore. Or even to think you can. So I think that the
programmers of today are up against a more difficult environment—still
exercising the same amounts of ingenuity but in an environment that’s
harder to understand. So we try to make more elaborate languages to help
them deal with the uncertainty of those environments.
Seibel: It’s interesting that you say, “more elaborate languages.” There’s a
school of thought—one that you’re certainly aware of as it could be called
the Scheme school of thought—that the only way to manage complexity is
to keep things, including our programming languages, very simple.
Download at Boykma.Com
Guy Steele
356
Steele: I think it’s important that a language be able to capture what the
programmer wants to tell the computer, to be recorded and taken into
account. Now different programmers have different styles and different
ideas about what they want recorded. As I’ve progressed through my
understanding of what ought to be recorded I think we want to say a lot
more about data structures, we want to say a lot more about their
invariants. The kinds of things we capture in Javadoc are the kinds of things
that ought to be told to a compiler. If it’s worth telling another
programmer, it’s worth telling the compiler, I think.
Seibel: Isn’t most of the stuff in Javadoc, other than the human-readable
prose, actually derived from the code?
Steele: Some of it is. But some of it isn’t. Relationships between
parameters are not well captured by Java code. For instance, here’s an array
and here’s an integer and this integer ought to be a valid index into the
array. That’s something you can’t easily say in Java. That’s an important
concept and in Fortress you are able to say such things.
Seibel: And they’re compiled into runtime asserts or statically checked?
Steele: Whatever is appropriate. Both. In the case of Fortress we are
trying to be able to capture those kinds of relationships. We talked about
algebraic relationships earlier, the idea that some operation is associative.
We want to be able to talk about that very explicitly in Fortress. And I
don’t expect that every applications programmer is going to stop and think,
“You know, this subroutine I just invented is associative.”
But library programmers really care about that a lot. Partly because if
they’re going to use sophisticated implementation algorithms, the
correctness of the algorithm hinges crucially on these properties. And so
where it does depend crucially on those properties, we want a way to talk
about them in a way the compiler can understand. I conjecture that that is
an important approach to finding our way forward, to capture in the
language important properties of programming.
Seibel: What about the role of the language in making it impossible to
make mistakes? Some people say, “If we just lock this language down enough
it’ll be impossible to write bad code.” Then other people say, “Forget it;
Download at Boykma.Com
Guy Steele
357
that’s a doomed enterprise, so we might as well just leave everything wide
open and leave it to the programmers do be smart.” How do you find that
balance?
Steele: The important thing is just to realize that it is a trade-off that you
make. And you can’t hope to eradicate all bad code. You can hope to
discourage certain kinds of likely errors by requiring “Mother, may I?” code;
in order to do something difficult, you have to write something a little more
elaborate to say, “Yes, I really meant this.” Or you can purposely make it
difficult or impossible to say a certain thing, such as, for example, to corrupt
the type system. Which has its pluses and minuses—it’s really hard to write
device drivers for bare metal in a completely type-safe language just because
the levels of abstraction are wrong for talking to the bare metal. Or you can
try to add in stuff that lets you say, “This variable really is this device
register at absolute address XXXX.” That in itself is a kind of unsafe feature.
Seibel: Have any of the newer languages provided any interesting surprises?
Steele: Python’s kind of nice in the way that it’s organized. I think I
disagreed with Guido’s decision not to use a garbage collector early on. I
think he’s since recanted that decision—I could have predicted they would
probably want one eventually. They made some interesting syntactic choices
including the decision to rely on indentation, and the way they use colons at
the end of certain statements is kind of cute. And the specific ways in which
they support objects and closures is kind of interesting.
Seibel: Most Lispers would think of the closures as being sort of deficient;
the lambda is pretty limited.
Steele: Right. Well you know, he was making a certain set of compromises
based on implementability and explainability and other things. And it was an
interesting set of choices. And it was not the set of choices I would have
made, but he was serving a particular user community and trying to get
certain things done and I can appreciate why he made the choices the way
he did. Haskell is a beautiful language. I love Haskell. I don’t use it that much.
Seibel: So you’re in the midst of designing a language and you love Haskell,
but Fortress isn’t a pure functional language?
Download at Boykma.Com
Guy Steele
358
Steele: On the other hand, now Haskell has discovered monads and they
have dragged in the I/O monad and now the transactional-memory monad.
There’s a theory that it’s functional and maybe that does give you a leg up.
On the other hand it’s feeling more and more imperative. And I can’t resist
thinking of the White Knight in Through the Looking Glass—“I was thinking of
a plan to dye one’s whiskers green, and always use so large a fan that they
could not be seen.” And in some ways, monads strike me as that fan, where
you’re dragging in the I/O and trying to hide it again—are the side effects
really there, or are they really not?
Although I will say that about once a month I get the feeling that I wish that
in designing Fortress we had started with Haskell and tried to move it
toward Fortran and Java, rather than starting with Fortran and Java and
trying to move it toward Haskell. We are finding ourselves taking more and
more of a functional approach as we design the Fortress libraries as we
encounter the difficulties of trying to make efficient parallel data structures.
Seibel: You obviously write a lot in English and care about that craft as
well. Do you find writing prose and writing code to be similar mental
exercises?
Steele: Well, they feel different in that I’m very aware that the primary
reader for English prose has a very different kind of processor than a
computer. So I can’t use recursion in quite the same way, for example. For
sophisticated readers I can use it a little bit. But there’s a constant
awareness of how a reader is going to process the text and understand it.
Something I worry about a lot when I write, that I’m less worried about
with a computer, is about the ways in which English is ambiguous. I’m
constantly worrying about ways in which the reader might misinterpret
what I’ve written. So I’ve actually spent a lot of time consciously crafting the
mechanics of my prose style to use constructions that are less likely to be
misinterpreted.
My favorite Saturday Night Live sketch, even more than the bees or the wild
and crazy guys, was a sketch where Ed Asner was on and he played the
manager of a nuclear power plant going on vacation for two weeks. He
walked out the door, saying, “Goodbye, everybody, I’m going. Remember,
Download at Boykma.Com
Guy Steele
359
you can’t give too much coolant to the nuclear reactor.” And they spend
the next three minutes arguing over what he meant.
Seibel: So when you’re writing English, you’re obviously writing for a
human reader and you seem to contrast that to writing software, which is
for a computer. But lots of people—such as Knuth—make a big point that
when you’re writing code you’re writing as much for human readers as for
the computer.
Steele: Oh, that’s true.
Seibel: So do the lessons of writing English for a human reader help you
with that aspect of code?
Steele: Well, sure. When I’m writing code, one of the foremost things in
my mind is, will this get the computer to do what I want? And so it’s a
matter of, “Will it be understood even one way?” Rather than not at all.
Then there’s the question of often there’s more than one way to write
something correctly. And at that point I begin worrying about the human
reader. And I also worry about efficiency.
There’s a trade-off there, typically. If efficiency is important, I’ll often resort
to a trick. And then I realize that will mislead a human. And you have to
comment it or do something to flag that, to make it more readable. But yes,
very often in things like choices of variable names and the way code is laid
out and so forth, the emphasis is more on the human reader, and you think
about how you can use details of the code formatting that don’t matter to
the computer to provide the necessary signals to the human reader.
Seibel: As our languages get better, or at least more programmer-friendly,
compared to the days of assembly language on punch cards, it seems like it’s
easier to write correct programs—you get a lot of help from compilers that
flag errors for you and so forth. Is it possible to allow the focus on
readability to come first, if only slightly ahead, of correctness? After all, as
the Haskell folks are fond of saying, “If your Haskell program type checks, it
can’t go wrong.”
Steele: I think that’s a terrible pitfall. There are so many ways for a
compilable program to have errors in it that you really do need to worry
Download at Boykma.Com
Guy Steele
360
about correctness all the time. And if it’s not correct you’ll mislead not only
the computer but your human readers, too.
Programming is a highly unnatural activity, I’m convinced, and it must be
carefully learned. People are used to their listeners filling in the gaps. I
suppose we lean on compilers to do that in a little way—you say, “I need a
variable named ‘foo’,” you don’t worry about exactly what register and so
forth. But I think that most people are not used to being very precise and
rigorous in their communications. But when we are describing processes to
be carried out, little details do matter because a change in a small detail can
affect the gross outcome of the process.
I think people are used to using recursion in a limited way—I think Noam
Chomsky demonstrated that. But in practice people rarely go even three
deep—and when they do it’s usually in a tail-recursive way. The discipline of
understanding recursion is actually a very difficult learned art. And yet that
is actually one of our most powerful programming tools, once you’ve
learned the discipline and wrapped your head around it. So I really think you
can’t afford to take your eye off the correctness ball.
Seibel: Yet lots of people have tried to come up with languages or
programming systems that will allow “nonprogrammers” to program. I take
it you think that might be a doomed enterprise—the problem about
programming is not that we haven’t found the right syntax for it but that
people have to learn this unnatural act.
Steele: Yeah. And I think that the other problem is that people like to
focus on the main thing they have in mind and not worry about the edge
cases or the screw cases or things that are unlikely to happen. And yet it is
precisely in those cases where people are most likely to disagree what the
right thing to do is.
Sometimes I’ll quiz a student, “What should happen in this case?” “Well,
obviously it should do this.” And immediately someone else will jump in and
say, “No, no, it should do that.” And those are exactly the things that you
need to nail down in a programming specification of some process.
I think it’s not an accident that we often use the imagery of magic to
describe programming. We speak of computing wizards and we think of
Download at Boykma.Com
Guy Steele
361
things happening by magic or automagically. And I think that’s because being
able to get a machine to do what you want is the closest thing we’ve got in
technology to adolescent wish-fulfillment.
And if you look at the fairy tales, people want to be able to just think in
their minds what they want, wave their hands, and it happens. And of
course the fairy tales are full of cautionary tales where you forgot to cover
the edge case and then something bad happens.
Seibel: Fantasia and the perils of recursion, for instance.
Steele: Fantasia and recursion, yes. Or, “I wish I was the richest man in the
country”—well, that makes everybody else extremely poor and you’re the
same as you were before. That kind of thing happens in fairy tales because
people forget that there’s more than one way to do something. And if you
just think about your main wish and don’t think about the details, that leaves
a lot not tied down.
Seibel: So the lesson from fairy tales is that the Gandalfs of the world got
there by hard labor, learning the incantations, and there’s no shortcut to
that?
Steele: Yeah. I’ll give you another example—suppose I were to tell my
smart computer, “OK, I’ve got this address book and I want the addresses
to always be in sorted order,” and it responds by throwing away everything
but the first entry. Now the address book is sorted. But that’s not what you
wanted. It turns out that just specifying something as simple as “a list is in
sorted order and I haven’t lost any of the data and nothing has been
duplicated” is actually a fairly tricky specification to write.
Seibel: So are there language features that make programmers—folks who
have mastered this unnatural act—more productive? You’re designing a
language right now so you’ve obviously got some opinions about this.
Steele: I said earlier that I think you can’t afford to neglect correctness. On
the other hand, I think we can design tools to make it easier to achieve that.
We can’t make it trivial, but I think we can make it easier to avoid mistakes
of various kinds. A good example is overflow detection on arithmetic, or
providing bignums instead of just letting 32-bit integers wrap around. Now,
Download at Boykma.Com
Guy Steele
362
implementing those is more expensive but I believe that providing full-blown
bignums is a little less error-prone for some kinds of programming.
A trap that I find systems programmers and designers of operating-systems
algorithms constantly falling into is they say, “Well, we need to synchronize
some phases here so we’re going to use a take-a-number strategy. Every
time we enter a new phase of the computation we’ll increment some
variable and that’ll be the new number and then the different participants
will make sure they’re all working on the same phase number before a
certain operation happens.” And that works pretty well in practice, but if
you use a 32-bit integer it doesn’t take that long to count to four billion
anymore. What happens if that number wraps around? Will you still be OK
or not? It turns out that a lot of such algorithms in the literature have that
lurking bug. What if some thread stalls for 2 to the 32nd iterations? That’s
highly unlikely in practice, but it’s a possibility. And one should either
mitigate that correctness problem or else do the calculation to show that,
yeah, it’s sufficiently unlikely that I don’t want to worry about it. Or maybe
you’re willing to accept one glitch every day. But the point is you should do
the analysis rather than simply ignoring the issue. And the fact that counters
can wrap around is a lurking pitfall that doesn’t hurt most programmers but
for a very few it lays traps in their algorithms.
Seibel: Speaking of glitches, what was the worst bug you’ve ever had to
track down?
Steele: I’m not sure I can dig up a worst one, but I can tell you a few
stories. Certainly, dealing with parallel processes has produced the most
difficult-to-deal-with bugs.
When I was a teenager programming on the IBM 1130 was the one time in
my life when the solution to a bug came to me in a dream. Or as I woke up.
I had been puzzling over a bug for a couple days, couldn’t figure it out. And
then suddenly sat bolt upright in the middle of the night and realized I knew
what the problem was. And it was because I had overlooked something in
an interface specification.
It had to do with concurrent processes. I was writing a decompiler so that I
could study the IBM disk operating system by decompiling it. And to this
end it would take binary data on the disk and print it in a variety of formats
Download at Boykma.Com
Guy Steele
363
including as instructions, as character codes, as numbers, and so on. And in
order to convert the characters, I was feeding the data to various character-
conversion routines, one of which was designed for use after reading card
codes from a card reader. And I had overlooked the tiny footnote in the
specification that said, “We assume that before you call the procedure, the
buffer in which the card data will be read has all over the low order bits
cleared.” Or maybe had them set.
Anyway, the 12 bits from the card-code column were going into the high 12
bits of the 16-bit word and they were using the low bit for a clever trick
whereby you could call the card-reader routine asynchronously and it would
asynchronously load the buffer and the conversion routine would follow
behind, using that low bit to determine whether the next card column had
been read in or not. And if it had been read it would then convert that
character. Thereby, as soon as the card was read, very shortly thereafter
the conversion would finish—they were overlapping the cost of the card
conversion with the time it took to read the card. And I was feeding it raw
binary data that wasn’t obeying this constraint. And I had just overlooked
this—I thought it was yet another card-conversion routine but it turned out
this one had something special about its interface—it was relying on those
low-order bits, which ordinarily you wouldn’t think about. It was
interpreting what was in the buffer as saying, “Oh, the data has not yet
arrived from the card reader.” In principle I knew this, but it wasn’t
occurring to me. And then, as I say, it came to me while I was asleep. So
that was an odd case.
The other really interesting story I can think of was while I was the
maintainer of the Maclisp system and Maclisp supported bignums—integers
of arbitrary precision. They’d been around for several years and were
considered pretty well debugged and shaken out. They’d been used for all
kinds of stuff in Macsyma, and Macsyma users were using them all the time.
And yet a report came in from Bill Gosper saying, “The quotient of these
two integers is wrong.” And he could tell because the quotient was
supposed to be very near a decimal multiple of pi.
These were numbers about a hundred digits each and it really wasn’t
feasible to trace through the entire thing by hand because the division
routine was fairly complicated and these were big numbers. So I stared at
Download at Boykma.Com
Guy Steele
364
the code and didn’t see anything obviously wrong. But one thing that caught
my eye was a conditional step that I didn’t quite understand.
These routines were based on algorithms from Knuth, so I got Knuth off
the shelf and read the specification and proceeded to map the steps of
Knuth’s algorithm onto the assembly-language code. And what caught my
eye in Knuth was a comment that this step happens rarely—with a
probability of roughly only one in two to the size of the word. So we
expected this to happen only once in every four billion times or something.
From that I reasoned to myself, “These routines are thought to be well
shaken out, thus this must be a rare bug; therefore the problem is likely to
be in the rarely executed code.” That was enough to focus my attention on
that code and realize that a data structure wasn’t being properly copied. As
a result, later down the line there was a side-effect bug where something
was getting clobbered. And so I repaired that and then fed the numbers
through and got the right answer and Gosper seemed to be satisfied.
A week later he came back with two somewhat larger numbers and said,
“These don’t divide properly either.” This time, properly prepared, I
returned to that same little stretch of ten instructions and discovered there
was a second bug of the same kind in that code. So then I scoured the code
thoroughly, made sure everything was copied in the right ways, and no
errors were ever reported after that.
Seibel: That’s always the trick—that there’s going to be more than one.
Steele: So I guess there’s lessons there—the lesson I should have drawn is
there may be more than one bug here and I should have looked harder the
first time. But another lesson is that if a bug is thought to be rare, then
looking at rarely executed paths may be fruitful. And a third thing is, having
good documentation about what the algorithm is trying to do, namely a
reference back to Knuth, was just great.
Seibel: When it’s not just a matter of waking up in the middle of the night
and realizing what the problem is, what are your preferred debugging
techniques? Do you use symbolic debuggers, print statements, assertions,
formal proofs, all of the above?
Download at Boykma.Com