Seibel Peter. Coders at Work

Подождите немного. Документ загружается.

Bernie Cosell

525

Seibel: At this point, you had presumably written a lot of the code despite

having originally inherited the system.

Cosell: Yeah. The operating system was not done when I got it. It was

buggy and there were pieces of it that were not finished when Steve Weiss

and Bob Morgan went off to grad school. I did something that they hadn’t

done—it was one of the things that I got known for around BBN, which is, I

made things work.

I really believed that computers were deterministic, that you could

understand what they were supposed to do, and that there was no excuse

for computers not working, for things not functioning properly. In

retrospect, I was surprisingly good at keeping the system running, putting in

new code and having it not break the system.

That was the first instance of something I got an undeserved reputation for.

I know that my boss, and probably some other of my colleagues, have said I

was a great debugger. And that’s partly true. But there’s a fake in there.

Really what I was was a very careful programmer with the arrogance to

believe that very few computer programs are inherently difficult. I would

take some piece of code that didn’t look like it was working and I would try

to read it. And if I could understand, then I could usually see what was

wrong or poke around with it and fix it. But sometimes I would get a piece

of code—often one that other people couldn’t make work—and I would

say, “This is way too complicated.”

So I would think through what it was supposed to do, throw it away, and

write it again from scratch. Some of the folks I worked with—like Will

Crowther—who are terrific programmers, couldn’t tolerate that. They

would believe that by doing that, I would probably have fixed the 2 bugs that

were there and introduced 27 new bugs. But the fact is, I was good at that.

So I would rewrite stuff completely and it would be organized differently

than the original programmer had organized it because I had thought about

the problem differently. Typically, it was simpler than it used to be, or at

least simpler to my eyes. And it would work.

So I got this reputation—I fixed these mysterious bugs that nobody else

could fix. Fortunately, they never asked me what the bug was. Because the

Bernie Cosell

526

truth of the matter is if they’d have asked, “How did you fix the bug?” my

answer would have been, “I couldn’t understand the code well enough to

figure out what it was doing, so I rewrote it.”

I did that a lot on the PDP-1 time-sharing system. There were chunks of the

code that I would read and would say, “This doesn’t do what I think this

part of the program is supposed to be doing,” or “It’s weird.” So I’d rewrite

it. The only thing that kept me working there, with that attitude, was that I

had a good track record. That’s one of the things, that if you’re not good at

it, you make chaos. But if you are good at it, the world thinks that you can

do things that you can’t, really.

Seibel: When you left MIT, was it a hard decision at all, deciding to drop

out of school?

Cosell: No. In retrospect, it was surprisingly easy. I was hating school. It

was making me crazy. MIT is really a pressure-filled place. And BBN was like

the Promised Land. It was wonderful. They played with computers; the

company was so laid back. It was more like Project MAC than Project MAC.

This was back in an era when people routinely brought their dogs in with

them. So pets were padding up and down the halls; people were working

day and night.

I started working part-time because I almost always had a part-time job

while I was at MIT. And it just instantly felt like home. I couldn’t believe it.

My MIT stuff went completely to hell so I dropped out of school and went

to full-time. Then I got settled in at BBN and was much more mellow and

got my head in a better place. So the following fall, which would have been

my senior year, I actually re-enrolled back at MIT. And I got back in again.

So that all worked out.

Seibel: Did you feel like your MIT education was a good complement to

your work experience?

Cosell: The programming courses that I took when I was an MIT

undergraduate stood me in good stead in some abstract way, but didn’t

actually teach me very much. Mostly what did was the environment at BBN.

Nobody, other than maybe Steve Weiss, was really mentoring me, but I was

sucking what I needed to know from everybody.

Bernie Cosell

527

Seibel: Obviously there were fewer computer books available then than

there are now, but are there books that you found particularly useful or

books that you think programmers should read?

Cosell: Hard for me to say what programmers should do now. There was

certainly nothing I can remember from back then in terms of how to

program. The closest was when I got my copy of Knuth’s The Art of

Computer Programming and sort of digested them from cover to cover. But I

would hardly recommend that as a tutorial text for people.

Seibel: You read Knuth straight through?

Cosell: Oh, it was hot stuff. I was in my prime back then. So each volume

as it came out we mostly read and sucked into our heads cover to cover.

Seibel: That requires a fair bit of mathematical sophistication. Do you think

most programmers need to be able to read Knuth cover to cover like that?

Cosell: I brought up Knuth as an example. I would not teach students

Knuth per se for two reasons. First, it’s got all this mathematical stuff where

he’s not just trying to present the algorithms but to derive whether they’re

good or bad. I’m not sure you need that. I understand a little bit of it and

I’m not sure I need any of it. But getting a feel for what’s fast and what’s

slow and when, that’s an important thing to do even if you don’t know how

much faster or how much slower.

The second problem is once students get sensitive to that, they get too

clever by half. They start optimizing little parts of the program because,

“This is the ideal place to do an AB unbalanced 2-3 double reverse

backward pointer cube thing and I always wanted to write one of those.” So

they spend a week or two tuning an obscure part of a program that doesn’t

need anything, which is now more complicated and didn’t make the program

any better. So they need a tempered understanding that there are all these

algorithms, how they work, and how to apply them. It’s really more of a

case of how to pick the right one for the job you’re trying to do as opposed

to knowing that this one is an order n-cubed plus three and this one is just

order n-squared times four.

Bernie Cosell

528

If they’re interested in that it’s nice to know that Knuth is there, but no

ordinary person needs to know that. But they need to know the wisdom in

there. They need to know the data structures. They need to not be stunned

when they see me building linked lists in Perl. When you know all of those

data structures you can pick the right one. You don’t have to pick the

fastest one. You don’t have to pick the one that’s cutest to implement. You

can actually pick the one that best serves your data because you know the

alternatives. Don’t tell Don that I fought through but didn’t have a lot of use

for a lot of the gruesome numerical calculations he did to reduce those

combinatorics. But boy, did I learn a lot about data structures, and that was

good stuff.

Seibel: Do you have any advice for the many programmers who are self-

taught?

Cosell: Write a lot of programs. That’s certainly what worked for me.

Looking at the various courses I’ve taken, writing programs is what really

did it. Not programming just to while away the hours but specifically, “I

ought to learn something about this; why don’t I try writing a little program

to do it?” That really does it.

You can’t see how these things work and how they interact until you’ve

done it some. You don’t know what programming practices are dangerous

until you’ve seen which ones make your programs take weeks to debug and

then seen a good programmer fix it in five minutes. I don’t think you can get

that from classes. Classes can give you a lot of stuff, but in the end

programming is a craft you have to perfect by plying it.

If you’re lucky, you can do it at work. But even in a work environment,

where you’re learning on the job, I think that to really be good you have to

learn faster than your job will make you learn things. You have to

supplement what your job is asking you to do. If your job requires that you

do a Tcl thing, just learning enough Tcl to build the interface for the job is

barely adequate. The right thing is, that weekend start hacking up some Tcl

things so that by Monday morning you’re pretty well versed in the

mechanics of it.

Seibel: How much of your own programming did you do for fun versus

consciously doing things to learn particular techniques?

Bernie Cosell

529

Cosell: Mostly I viewed computer programming as a means to get neat

things done and I learned how to program in order to make things happen.

There were things that seemed broken to me that I could fix. I thought it

would be fun to do some Lisp programming not because I wanted to learn

Lisp but because some of my friends across the bridge were big Lisp guys

and it was all a little mysterious to me. So I wrote some programs and that

just seemed like the natural thing for me to do as opposed to sitting at Dan

Murphy’s knee and having him give me lectures on CONS and CDR and

CAR.

Seibel: Are there areas in formal computer science that you think are

particularly useful for people who ultimately want to work as programmers?

Cosell: There are a bunch of things. I know a lot of schools do a terrible

job of it, but I think getting a good course in object-oriented programming

in its abstract form. One of the things I fought about with some folks at a

local college here was teaching object-oriented programming using C++. I

asked how they make sure their students understand the distinctions

between the philosophical concept of object-oriented programming versus

the idiosyncrasies and weirdnesses of C++’s implementation of it.

One other thing I think schools can do is the stuff that’s in Knuth. I’m

surrounded by people who think linked lists are magic. They don’t know

anything about the 83 different kinds of trees and why some are better than

others. They don’t understand about garbage collection. They don’t

understand about structures and things.

Then the next volume: sorting and searching. If the programming language

didn’t have a sort function, they wouldn’t have a clue about different types

of sorting, or how to search for things, when you should build indexes, what

it means that the database we’re using stores things in a B-tree. I think a

good course would give them background not in, how do you write a linked

list in C—that’s a craftsman thing—but what do linked lists do in an abstract

sense?

Seibel: Perhaps the most famous project you worked on was the beginning

of the ARPANET, when you, Will Crowther, and Dave Walden wrote the

software for the original ARPANET IMPs. How did that come about?

Bernie Cosell

530

Cosell: In Frank Heart’s group, our division, Frank viewed all of his

programmer guys as this basic stable. He picked and chose how to move

people from project to project. When my projects ran out, Frank would

figure out what I should work on next. As opposed to the real consulting

guys who would start flying to Washington and writing proposals; I was

spared having to do that. Somehow, Frank had decided that I was to be the

third guy on the IMP project.

I was working on another project in the fall of ’68 when Dave and Willy and

those guys had started. I think the contract had been awarded but wasn’t

going to start until January. When I joined the project, not much was done. I

think they had scraped out some of the code, but nothing was really cycling

yet. When I came on board and Dave and Willy had started blocking out

how the system was going to be organized and had taken hunks that they

were starting to write. I just fit in and claimed a piece or two for myself. We

all had different skills but we were all going to know how every line of code

worked for the thing because it wasn’t that big a program. Complicated, but

not that big.

And I know they couldn’t have gotten very much done when I joined

because they were still doing offline assemblies, which involved taking a

paper tape into the Honeywell room where there was a 516 and running

paper tapes through, making an assembly listing by having it punch an entire

box of paper tape, which they would then have to carry to another machine

because there was no line printer on the Honeywell machine to make an

assembly listing. It was really pretty cumbersome doing the software

management for that. One of the first concrete things I did on the project

was I wrote a cross assembler for our PDP-1.

Then on the PDP-1 we could edit the files, assemble the files, make

assembly listings of the files, run TECO macros over things. The only thing

that got punched out was the comparatively small paper tape of the binary

executable program, which would then go into the Honeywell machine.

Seibel: Was that the biggest challenge of writing the IMP software: making

it go fast?

Cosell: Oh, that’s interesting. Well, let’s see. We didn’t think very much

about how big it was because the idea was that the system was going to

Bernie Cosell

531

have to have a lot of space for buffering. And the code wasn’t going to be

that big. And if the code was, say, ten percent larger than it could be if you

squeezed it down, that would just mean that there would be a few fewer

buffers. So we weren’t quite so much worried about counting how many

instructions everything took.

Seibel: In terms of how much space it would take.

Cosell: Right. How much space. But we were concerned with speed,

whether we were going to keep up with the bandwidth. And how do you

organize a system so that it degrades gracefully and, in particular, degrades

in a way that it can dig itself out of a hole as opposed to just collapsing and

dying?

The second thing was just making the system work. There was a lot of

untried, untested stuff. Were the protocols going to work? Will had come

up with some ideas for the routing algorithm—was that going to work?

There were still a lot of underlying questions. A question about congestion

control. Did we know for sure that if everybody in the world sent packets

to one poor guy that we would actually refuse the packets in the right order

and dig himself out?

Seibel: So that was basically because nobody had ever tried to solve this

problem before.

Cosell: Exactly right. It was a research project at that point—a lot of

theory. A lot of people had written dissertations. A lot of people thought

they knew what was going on. At that point, the rubber had to meet the

road. We had to actually see whether the queuing theory was going to

work, whether the routing algorithm could oscillate.

The third big challenge was simply how do you debug the thing. All of a

sudden, you can’t talk to Cincinnati, Ohio. What went wrong? How do you

figure it out? You call Cincinnati, Ohio, and you get a sleepy night watchman

at 3:00 in the morning walking up to this little blinking box in the corner.

What does he look at? What do you do? And even if you get the system

back up, what went wrong? How do you fix it? Remember, I was a big

things-don’t-crash, things-are-going to-keep-working guy.

Bernie Cosell

532

I know that one of the things that impressed Will was there was some bug

that they could not find and I found it. It turns out it was a bug in the

handling of some protocol for the modems and it was sending the wrong

packet at the wrong time. I put together a series of patches so that I could

put a marker in a packet and when it saw that particular packet, it installed a

patch on the system that looked for this other thing happening and as soon

as it saw it, it stopped the system. Then once it stopped the system, we

could use debuggers to figure out what was going on. Once I had done that,

it took about two minutes to find the bug because the offending packet was

still in memory; it hadn’t been written over.

I don’t remember the exact problem, but it was one of these problems that

was not fatal. There was a bad pointer corrupting memory and the

corruption wasn’t causing any trouble, but thousands and thousands of

machine cycles later, the program crashed because some data structure was

corrupt. But it turns out the data structure was used all the time, so we

couldn’t put in code that says, “Stop when it changes.” So I thought about it

for a while and eventually I put in this two- or three-stage patch that when

this first thing happened, it enabled another patch that went through a

different part of the code. When that happened, it enabled another patch to

put in another thing. And then when it noticed something bad happening, it

froze the system. I managed to figure how to delay it until the right time by

doing a dynamic patching hack where one path through the code was

patched dynamically to another piece of the code. And I was lucky because I

guessed the right thing and we immediately found the problem.

Seibel: What enables that kind of intuition?

Cosell: On the systems I’m very good with like that, like the IMP system

when I had it all in my head, or the PDP-1 time-sharing system, even though

the system is a multiprogramming, multilayered, interrupt-driven system, I

have all the dynamics of the system in my head. I know what order things

are supposed to happen. I know somehow what’s not supposed to happen,

when things are supposed to not be happening. That lets me build up a

model for, “How could this thing possibly have happened?”

And at least some of those were two-machine problems, which also

required some odd creativity to find. That is, the trouble is something goes

wrong on my machine and the evidence of it shows up on yours. I can’t

Bernie Cosell

533

stop—my machine has already processed 6,000 more packets by the time

yours hits the trap that says, “I got a bogus packet.” So now what do you

do? We’d work through, the three of us, finding ways to track those things

down and fix them and basically make the system pretty solid.

Seibel: Did you build in debugging code?

Cosell: No.

Seibel: So you had many different tricky bugs, each of which you had to

track down in a unique way?

Cosell: As far as I can remember, we didn’t build in any debugging stuff. I

mean, these days, I always point out that you’ve got to make programs so

that they are testable. And the only way to make a program testable is to

think about that before you write the first line of code. You can’t retrofit

block points and assert points and test points that work efficiently and do

the right thing if you wait until the program is working.

But I’m sure that we didn’t think about any of that. We were just trying to

write this incredibly complicated real-time thing that had to be fast. It was a

hard enough problem. We didn’t put in any real consistency checks; who

would want to waste time for that? So these things were all ad hoc patches.

Jump off into a spare part of memory, run through some hand-coded stuff

to check this or that or the other, jump back, and continue.

In fact, it was even formalized. One of the things—I’m pretty sure I wrote

it—was a patcher where you could submit a patch to the system and it

would pull one buffer out of circulation and use it to hold the code and link

up to that and then link back. We used to do that kind of stuff but it was all

ad hoc. We would find some bug and we would crack our heads trying to

figure out what it could be.

A lot of the times, just understanding what the bug is points you at the right

piece of code. Now you read it more critically and you fix it. Other times,

you need to collect more data. Other times, you need to bang your head

against the wall trying to catch that little bit of evidence that illuminates the

thing. And we did some of all of that.

Bernie Cosell

534

Remember, we’re running on a machine that’s got no console, no nothing.

In general, the patches would stash away some data and then halt the

machine. Then we would probably use the front panel because I don’t think

there was a debugger we could run from the terminal that wouldn’t trash

the machine. So we’d look through the appropriate areas of memory from

the front console, doing examines and deposits to go figure out what was

going on.

Seibel: So that’s literally a row of lights?

Cosell: Yeah, a row of lights. Bit per light.

Seibel: And toggle switches to put in the address?

Cosell: Right. Actually, this is better. The PDP-1 had toggle switches. This

one had, as I recall, push buttons.

Seibel: How did the three of you work together?

Cosell: One of the things that I remember doing shows a little bit of the

style difference. Will was a brilliant intuitive programmer. All of the hardest

problems that most people couldn’t understand how to do at all, he would

find ways to do.

Like the AI engine in Adventure that he did in Fortran of all things. And the

routing algorithm and all sorts of stuff in the dynamics of the IMP system,

Will had cobbled together. One of the things about a real-time system is

everything has to be timed out. You can’t wait forever for anything because

there’s no forever in a real-time system.

And a bigger and bigger collection of time-outs were growing up all over the

program. I tried to understand them and had a hard time doing it. So in one

of my revisions of the source code, I tried to make an algebra for all of the

time-outs. For example, the total time-out to get an acknowledgement for a

message should be eight times the time-out for a single packet to transit the

net plus something. Or, the total time-out for a message to track the net is

the maximum diameter of the net times the maximum time for the packet

to make one hop.