Seibel Peter. Coders at Work
Подождите немного. Документ загружается.
Dan Ingalls
405
Seibel: This was in Smalltalk, I assume. Did you have a symbolic debugger
that you could use, or were you looking at hex dumps of memory?
Ingalls: This was lower level than the nice Smalltalk debugger. I really can’t
tell you the details of this one, but the kind of thing is you get an error
somewhere, which would actually take you to the low-level debuggers. So
you’re looking at memory like a bunch of octal locations. Then you find
things like one object pointing into another object in the way it shouldn’t.
So you’re trying to think of, “How could that happen?” You have all these
little clues and little patterns of this can cause that, this can cause that, and
so then you try to figure them out.
Seibel: So that was at a very low level. When you’re developing in the nice
Smalltalk environment, I assume you use symbolic debuggers. Do you ever
resort to print statements?
Ingalls: I don’t know of anybody who does that if they have the choice of
using a good debugger. Because where do you put the
print statement?
You put it there. Well, wouldn’t you just like to be there, looking at
everything, instead of just printing it? Now I do a fair amount of print
statement–style debugging because it’s often the case I don’t have a good
enough JavaScript debugger.
Seibel: What made the Smalltalk debugger so nice?
Ingalls: Well, you could stop anywhere in the program and you could
actually look at all the bindings of all the variables. You could execute
fragments, evaluate expressions right in the middle of the context.
Seibel: At any particular point in the stack frame?
Ingalls: Yep, and you could make significant changes and then proceed. And
you could get to an error, have it on the screen, save the entire state of the
system, ship it to somebody else who was on a Windows machine and not a
Mac, and they could fire up that same image, be where you were, make a fix,
and proceed. So just complete preservation of state across different
machine representations.
Download at Boykma.Com
Dan Ingalls
406
Seibel: Invariants are another sort of debugging tool. Some people are very
big on formal preconditions, and postconditions on all their methods and
class invariants, and some people are more ad hoc about how they think
about things. How do you think about them?
Ingalls: I’d probably go in the less formal camp. Mainly out of that original
feeling of having things be as absolutely simple as possible. I feel the same
kinds of things about types. Types are essentially assertions about a
program. And I think it’s valuable to have things be as absolutely simple as
possible, including not even saying what the types are. I think as you get
more serious about a system, it’s nice to be able to add all that stuff, and
there are ways of having your cake and eating it, too, such as inferring the
types and not having to see them except when you want to see them.
And types are only one thing in a spectrum that includes units and all sorts
of other assertions you can put on there. That’s part of the fascinating area
we have to explore with this synthetic mathematics. I think increasingly we
can take areas of computation and document them more and more with
living documentation, real programming documentation, so there are
assertions there that really help you that you don’t usually see, but if you’re
stuck, you can start to bring them in and test various things about it.
Seibel: Do you have an opinion one way or the other on formally proving
programs correct?
Ingalls: It’s never been an occupation of mine. I’m inclined to focus on the
architectural part that makes it easier to make assertions about things. So if
you are allowed to do all sorts of dangerous things in a program, then when
you sit down to do the formal proof, it’s very hard because at every step
you’ve got to say, “Well, this could happen, that could happen, that could
happen.” If the architecture is clean, then the formal proof may almost be
obvious just by reading the code. You’ll say, “Well, this could only come
from there. We’re safe.”
Seibel: Have you ever used C++?
Ingalls: No. Nor C.
Download at Boykma.Com
Dan Ingalls
407
Seibel: But you did BCPL and assembly, so it’s not like you’ve never used
low-level languages.
Ingalls: Right. And I actually have done some C to debug things generated
by Squeak. But I remember when we did Squeak, part of my purpose was to
have a system that you really could be master of without having to know
anything but Squeak. So I made it my purpose to not ever learn that. John
Maloney did the translator from Squeak to C in order to give us a practical
implementation. The truth is, I would go in and look at that C code but I
pretty much made sure that you didn’t need to do any of that.
Seibel: You must’ve looked at C++ when it came out, as you were part of
the group that—other than perhaps the Simula folks—can best claim to
have invented object-oriented programming.
Ingalls: I didn’t get that much into it. It seemed like a step forward in
various ways from C, but it seemed to be not yet what the promise was,
which we were already experiencing. If I had been forced to do another
bottom-up implementation, instead of using machine code I would’ve maybe
started with C++. And I know a couple of people who are masters of C++
and I love to see how they do things because I think they don’t rely on it for
the stuff that it’s not really that good at but totally use it as almost a
metaprogramming language.
Seibel: Let’s talk about code reading. How do you get into a new piece of
code?
Ingalls: It’s hard for me to answer in the abstract. You start out knowing
what it does or is supposed to do. I guess I go at it pretty much top-down—
I just try to understand what the pieces are and how they work together.
See what classes and methods are defined and what they’re doing. Then it
depends on why we’re looking. It could be it’s just something new and we
want to find out about it. It could be that it’s performing badly and then you
do a profile of it and look at that.
Seibel: We talked about Knuth before. His other passion is literate
programming. Have you ever written literate code or read any?
Download at Boykma.Com
Dan Ingalls
408
Ingalls: I like to work that way with something where I’ve got the time to
finish it off. When I first write stuff, there are no comments. As soon as I
have it working, I’ll write some comments. And if I like what I’ve done or it
seems like it would be hard to figure out, I’ll write more comments. But I
don’t believe in putting comments beside everything. And I kind of feel like
the better a language is, the less you need comments. You use reasonable
variable names. That’s why I liked the keyword parameters in Smalltalk. It
really makes things pretty readable.There’s this wonderful little hack that
you can do in various places in JavaScript. It’s a little bit expensive, but
JavaScript has this curly bracket object notation, and so you can use
keywords and they actually looks like Smalltalk keywords because they end
with colons, so you can have your multiple arguments be in a curly brace
expression. It actually makes nice-looking programs.
Seibel: Hmmm. That’s kind of beautiful and disgusting at the same time.
Ingalls: Yeah, right.
Seibel: Have you convinced anyone else to adopt that style?
Ingalls: The truth is I found somebody else doing that before I thought of it
myself.
Seibel: Do you consider yourself a scientist, an engineer, an artist, or a
craftsman?
Ingalls: Really, all of those. I think my education as a physicist was good for
me. A lot of that just has to do with looking at problems like physical
problems, trying to isolate the forces on a body. It’s the same kind of thing
you use for looking at what all the ways are that something’s being used in
the system, how it could be affected. And it’s a very physical feeling I have
about stuff that’s also really spatial—how things work together and how
things that might be different could be the same and how that would make a
better architecture.
I remember one of the early talks I had to give about Smalltalk; I said,
“What we do in this group is like the scientific method, which is you make
an observation, you come up with a theory to explain it, and you perform
an experiment to verify it.” And that’s very much what we did in the
Download at Boykma.Com
Dan Ingalls
409
successive generations of Smalltalk. We had a theory for how to make
something work. We built a system that worked that way. We used it for a
while and we found out, “Oh, it’d be good if we did this and this and this
differently,” and we built a new one. So we kept going around that circle,
which is just like scientific research and progress.
I feel like an artist when I’m working because I have this idea in my head and
I just want to make it real. I imagine a sculptor having the same feeling,
bringing a piece to life.
In this context, I view engineer and craftsman as being almost identical. It’s
just that an engineer is a craftsman in a technological field. There are times
when I feel that way, too, but they are different times—a very different
time. It’s when I’m doing something low-level. From my history, I worked
on the deepest parts of BitBlt or the Smalltalk byte-code engine and those
are very craftsman-like things. And I had the luxury to do those over again a
couple of times to get them really right and that’s a craft.
Seibel: The difference I see between engineers and craftsmen is the
engineers are the folks who say, “We should be like the guys who build
bridges. Bridges don’t fall down. They have a repeatable engineering
process.” The craftsmen say, “This is more like woodworking. The wood is
unique every time and there are rules of thumb but no method that can
guarantee certain results.”
Ingalls: So in that regard I may be less of an engineer. I think that the ways
in which I stress systems are different. I know there are people who do
serious enterprise programming systems. That’s not a focus or a passion of
mine. Of the four you mentioned, the engineer is probably the least, then
craftsman, and then this funny combination between artist and scientist at
the top.
Seibel: You mentioned that you left industry for a while and then you came
back. Were you tired of computers or was it just other things in life?
Ingalls: It was other things in my life. It was also a nice break, and I picked a
good time for it, because when I came back, it didn’t seem to me like things
had changed that much, except everything was a hundred times faster.
Download at Boykma.Com
Dan Ingalls
410
Seibel: Do you have any recommendations for people who want to be
programmers?
Ingalls: Well, I think a decent course in computer science should be good.
The way I would organize that is to learn several different languages that
have various different strengths. Smalltalk’s got a lot of strengths but it’s not
the answer to everything. There’s logic programming. There’s functional
programming. Actually, you can do Smalltalk in a functional style, and so
that’s covered there pretty much. But like what I said about Lotus 1-2-3 and
translating English to pig Latin, I think it’s worth it to take several different
computing environments and then pick a problem to solve in them, which
either reveals the strength of the language or encourages you to somehow
escape from it.
Seibel: Do you think programming—and therefore the kind of people who
can succeed as programmers—has changed? Can you be a great
programmer operating at a certain high level without ever learning
assembly, or C, and maybe without ever learning the algorithms you would
get from reading Knuth, because these days you’re using some high-level
language that includes a lot of those algorithms in libraries?
Ingalls: Different people have different levels that they need to go to to feel
good about what they’re working with. So I think somebody can be entirely
confident maybe using a collections library without having programmed it
themselves. It just means they’re operating at another level. Lord knows, I
wouldn’t expect anybody who intends to work with graphics to have had to
write BitBlt. You don’t have to do NAND gates; you can use assembly
language. I think you can work at any of these levels. If the challenge calls on
you for it, you’re going to have to go deeper, and if your interest is sparked,
you will want to go deeper.
Seibel: So do you think most programmers today, who may be working at
a fairly high level, in a different environment would have learned assembly
and microcode? Or do you think the kind of talents that people need to be
successful programmers are changing?
Ingalls: Yes and no. It is in a way the same up and down at any level and
hopefully it will come to appear even more so. But there are areas right
Download at Boykma.Com
Dan Ingalls
411
now where I think there’s more putting together according to formula and
other areas where there’s dealing with things that are much more primitive.
I was a physicist; I had mathematician friends and I did not feel like I was at
all the same kind of brain as they were. But we both did good things. I think
that’s going to be the case in computers, too. The people who are working
on program provers are different from the people who are working on
graphics systems, I think. And so people are going to find their strengths and
the place they want to work and the place that they’re not comfortable
working. I think there’s some nature as well as nurture going on here, and
there always will be.
It may be that some of these systems have enough levels and parts to them
that a given person may be mainly comfortable and productive working in
one kind of area rather than another, but I think it’s all the same stuff.
There’s logical thought and there’s structural thought. And there’s human
stuff and creativity. A given person has a given mix of that from their nature
and their nurture, and to me, it hasn’t changed much. People are trying to
do presumably bigger, better stuff, but it seems to me to still be pretty
much the same.
Seibel: Related to that, as more and more fields rely on computing in more
and more ad hoc ways, there are folks who want to find a way for
“nonprogrammers” to program. Do you think that’ll happen, or will domain
experts, say biologists, always have to team up with programmers to build
custom software to solve their problems?
Ingalls: I think there will be that kind of collaboration because the biologist
isn’t interested in programming it. He’s interested in finding out this or that.
Then there’s somebody who understands how this stuff is being worked on
on the computers who can help him do that. I think the thing that lets a
nonprogrammer program is an application.
Seibel: I worked on a project that tried to provide a programming
environment for biologists on the theory that the software they would need
would always be ad hoc. You couldn’t build an application and be done with
it because the biologists didn’t really know what they needed until they got
down to some piece of biological data and said, “What I really want to
Download at Boykma.Com
Dan Ingalls
412
know is X,” and the only way to extract X from that data was, essentially,
to write a program.
Ingalls: Yeah, it would be nice if we could have some computing
environment with all your information in it so you could somehow figure
out how to get to it all just by its self-revealing nature. But I think that there
are people who are going to be interested in that and people who aren’t.
Seibel: Is there anything I haven’t asked about that you thought I might?
Ingalls: Often, reading about famous people, the side of it that I’m
interested in is, how do they make their life work? All the things that
weren’t their passion, and how did they deal with that, and with their family,
and with their finances, and balancing that. Or did they just hole up and say,
“To hell with everything else,” and let it just come crumbling down until
they had their work done?
Seibel: Do you feel like there were times in your life where your passion
for programming ran amok to the detriment of other parts of your life?
Ingalls: Yeah, there are times when it’s been hard on others because I’m
focused and need to stay focused. It’s a risk with anybody who’s got a
passion for what they’re doing. I think either you learn to moderate it
somewhat or the other thing you do is communicate it so that everybody
around you knows that you’re dealing with this thing, and you’ll probably be
done in a week, but until then Daddy’s somewhat inaccessible.
Seibel: And then you win your “Dad the Determined Debugger” award.
Ingalls: Exactly; right. The other thing is, the more you can reflect the
satisfaction from progress back out to all the people who have dealt with
you during that time, at least they have a sense that Daddy’s doing
something good, and we’ll all be happy when it’s done.
Download at Boykma.Com
C H A P T E R
11
L Peter
Deutsch
A prodigy, L Peter Deutsch started programming in the late ’50s, at age 11, when
his father brought home a memo about the programming of design calculations
for the Cambridge Electron Accelerator at Harvard. He was soon hanging out at
MIT, implementing Lisp on a PDP-1, and hacking on and improving code written
by MIT hackers nearly twice his age.
As a sophomore at UC Berkeley, he got involved with Project Genie, one of the first
minicomputer-based timesharing systems, writing most of the operating system’s
kernel. (Ken Thompson, inventor of Unix and the subject of Chapter 12, would
also work on the project while a grad student at Berkeley, influencing his later
work on Unix.) After participating in a failed attempt to commercialize the Project
Genie system, Deutsch moved to Xerox PARC, where he worked on the Interlisp
system and on the Smalltalk virtual machine, helping to invent the technique of
just-in-time compilation.
He served as Chief Scientist at the PARC spin-off, ParcPlace, and was a Fellow at
Sun Microsystems, where he put to paper the now famous “Seven Fallacies of
Distributed Computing.” He is also the author of Ghostscript, the Postscript viewer.
In 1992, he was part of the group that received the Association for Computing
Download at Boykma.Com
L Peter Deutsch
414
Machinery Software System Award, for their work on Interlisp, and in 1994 he
was elected a Fellow of the ACM.
In 2002 Deutsch quit work on Ghostscript in order to study musical composition.
Today he is more likely to be working on a new musical composition than on a
new program, but still can’t resist the urge to hack every now and then, mostly on
a musical score editor of his own devising.
Among the topics we covered in our conversation were the deep problems he sees
with any computer language that includes the notion of a pointer or a reference,
why software should be treated as a capital asset rather than an expense, and
why he ultimately retired from professional programming.
Seibel: How did you start programming?
Deutsch: I started programming by accident when I was 11. My dad
brought home some memo from the Cambridge Electron Accelerator,
which was being built at the time. There was a group that did design
computations and some memo of theirs accidentally found its way to him. I
saw it lying around his office and it had some computer code in it and there
was something about it that caught my imagination.
It turned out the memo was actually an addendum to another memo so I
asked him if he could lay his hands on the original memo. He brought that
home and I said, “Gee, this stuff is really interesting.” I think I might actually
have asked him if I could meet the guy who had written the memos. We
met. I don’t really remember the details any more—this was 50 years ago.
Somehow I got to write a little bit of code for one of the design calculations
for the Cambridge Electron Accelerator. That’s how I got started.
Seibel: So that was when you were eleven. By 14 or 15 you were playing
on the PDP-1s at MIT, where your dad was a professor.
Deutsch: When I was 14, I found my way to the TX-0 and to the PDP-1
shortly thereafter. I remember getting a hold of a copy of the Lisp 1.5
programmers’ manual. I don’t remember how. It was a very early version—
it was actually mimeographed—the old purple ink. There was something
Download at Boykma.Com