Seibel Peter. Coders at Work

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

Bernie Cosell

555

Seibel: Let me first ask about the engineering part. There are certainly

folks, like Watts Humphrey and the folks at the Software Engineering

Institute, who say programming should be an engineering discipline just like

building bridges. People can build bridges and they can predict how long it’s

going to take, and the bridges, for the most part, don’t fall down.

Cosell: Exactly right. The analogy is very good except they put a non

sequitur in the middle of it. It turns out that the guy that designs the bridge

so it won’t fall down is not the guy that strings the cables or that inspects

the cables to make sure the steel was right or pours the concrete or does

any of those other things.

Programming is in that regard an engineering discipline. You have to know

what to do. You have to know what your capabilities are. At the level I was

working, I had to be able to envision how the pieces were going to fit

together. I had to have some intuition for what things were fast and what

things were slow, what things were hard to build, what things were easy to

build, and come up with, at the engineering level, a model of what I thought

was going to happen.

The artist part decides that the design should be elegant. Those fit together

because in computer programs the artistry affects the longevity of it. Part of

what I call the artistry of the computer program is how easy it is for future

people to be able to change it without breaking it. That doesn’t have

anything to do with constructing its functionality but with its life as an

existing thing.

Seibel: So for you the beauty of code is tied up with the fact that people

are going to have to change it.

Cosell: One or two things I wrote were black boxes that just had to run as

long as the computer cycled, but most of them were code that generations

of people were able to hammer on and mostly not keep breaking. When I

talk about the artistry and the beauty of it, what I’m talking about is the idea

that when you write a program you have a huge amount of discretion. How

you organize your routines, how you lay them out on the page, where you

decide to put comments, how you name your variables, whether you like

your subroutines to all have uniform calling sequences or situational-

appropriate code.

Bernie Cosell

556

So you have to look at the program through the eyes of a new programmer

sometime down the road. What’s the structure of the program? What are

you doing? How are you doing it? And why are you doing it? The artistry is

how the next guy that reads the program and understands that this

subroutine was supposed to do this—he gets the message that it’s not right

for him to go and muck it up to do something else and that he should keep

the structure of the program.

Seibel: What about the tension between clarity and efficiency? Sometimes

the simplest, easiest-to-read code isn’t the fastest.

Cosell: Programmers are the worst optimizers in the world. They always

optimize the part of the code that’s most interesting to optimize, and

almost never get the part of the code that actually needs optimization. So

you get these little nuts of very difficult code that have no point. I always tell

the people working with me, “Code it as lucidly, as easy to read, as crystal-

clear as you can. Do it the simple way. And then if it needs to be sped up,

we’ll deal with that later. If you’ve done it right, we can draw a little box

around this piece.”

Eons ago one of the versions of Emacs had one page of the source code that

was a gigantic skull and crossbones in comments that said something like:

“Seriously twisted code follows this thing.” It was some piece of the

innermost guts of the search code or something like that that they had

optimized the hell out of. That’s a place where I can see that this piece is

really tough. So there’s a big black box around it saying, “Don’t stray in

here, unless you know what you’re doing.”

But programs we write these days are bigger and clumsier, in terms of the

elegance I learned when I was doing PDP-1, and slower. And that’s fine. It

turns out it doesn’t matter. Now, the guys doing video synthesis and the

guys doing the CGI animation stuff, clearly those guys don’t have that

luxury. That takes some beaucoup careful programming. I could not do that

anymore; I am way over the hill for that. But I could do that once. And I

understand the guys that do that. But most of the programs we do are just

routine crap.

At some college they had a two-semester course from September right

through May and you had you work on some fairly hard program at the

Bernie Cosell

557

beginning. What they didn’t warn you was in April they were going to make

you work on the program again, having now really run you through the

hoops on other things. The idea was for you to be stunned at how hard it

was to remember whatever it was you thought you understood perfectly

clearly just six months ago.

Seibel: So all that stuff that you did at the last weekend before it was due

comes back to haunt you.

Cosell: That’s right. I thought that was a brilliant scheme. It’s teaching them

a lesson that is hard to get except in the real world.

Seibel: When I talked to Ken Thompson I asked him about whether there

were inherent problems in C that lead to security problems and he basically

said that’s not the problem. You teach courses on computer security—what

do you think of that?

Cosell: I would hate to cross swords with him, but I say in my computer-

security class that the biggest security problem to befall modern computers

is C. It was designed to be a systems-programming language and it was such

a comfortable systems-programming language that all the hotshots used it.

We built operating systems out of it. We built real-time systems out of it.

I remember the wars in the days of Pascal. The argument was that

computers should help you; that C was too dangerous a language. The two

big voices I remember were Wirth and Dijkstra. On the other side was

every systems programmer I know, including me. I wrote everything in C.

So C sort of steamrolled the zillions of languages back then.

The government tried mandate Ada and they wouldn’t let contracts unless

they were in Ada. C steamrolled over those. It was just amazing. But as I

look at it now, I am still stunned almost every day that it borders on the

impossible to write a program of any real complexity in C and not have a

security problem. The amount of care it takes for a programmer to never

do a read into a buffer without explicitly making sure it can’t run over the

end of the buffer, to never free a block of memory at the wrong time so a

pointer way elsewhere in the program becomes stale, to never store

something that’s the wrong size and happens to step on the next value—

those problems can be so hard to find.

Bernie Cosell

558

It has been such a boon in systems programming. The idea that we would

write our systems in assembler and all our applications in Pascal sent shivers

down my spine. I don’t think that was the right answer. But writing both

systems and applications in C, I would have to say has proven just not to

work very well. It’s just too hard.

It’s kind of like the problems we had with interrupt bugs. You could argue

that there’s no real magic in writing a program with sequence breaks or

interrupts. There’s no real problem with that. It takes a little bit of

understanding and a little bit of care. But I know for a fact that very good

programmers who understand all of that put those bugs in their

programmer. A programmer like me would have to come and fix it and I

had to do the Niklaus Wirth–style thing of inventing the computer language

that wouldn’t let them make interrupt bugs.

For the IMP system I wrote a complicated set of assembler macros, so you

could declare what you were doing. When you came in on an interrupt, you

wrote a declaration that says, “I am on modem input” or “I am on the high-

priority clock or the low-priority clock.” And then when it assembled your

program, it actually tagged every instruction with which interrupt level it

was running on and then there was a postprocessor that I probably wrote in

TECO macros, honest to God, that processed that and looked for time-

sharing problems. It would look for a variable that was accessed by two

different levels and it would say, “There is an interrupt conflict.” Now all of

a sudden, the time-sharing bug would go away. Other programmers could

understand that if they put the right declarations in, these macros would

keep them from making timing bugs. I got a trip to Hungary to present how

you could get programmers who don’t really understand real-time issues to

be able to write solid real-time programs by using this technique to abstract

out the conflict problems.

That’s a little bit the way I feel about C. I’m sure that there are good

programmers, perhaps including me, who can write good C programs. But

it’s just harder than it has to be. In the modern environment it’s gotten

harder because the environment is so much more difficult—the number of

places where C’s weaknesses can be exploited or overlooked, the amount

of care it takes. That’s one reason why I’m very comfortable writing in Perl.

Perl is slow. I’m sure it’s one of the slower languages, but in essence it

Bernie Cosell

559

repairs all of the security problems of programming in C. What happens

when you index off the end of the array in Perl? It makes more array.

It knows what its pointers point to, so you can never misreference a pointer

because you only say to go through it and it tells you where it’s going. So

I’m much more comfortable building security-necessary applications in Perl

because I have a world full of Perl people pounding on the core and it’s

been stable for so many years. I don’t think we’re going to find too many

allocate bugs or pointer bugs, and they’re hard to exploit from random Perl

code anyway. I don’t have to trust the programmers around me to get

every pointer check right.

And even then we get programs like the classic one where somebody wrote

a web page that was looking up somebody in a table and some hacker put

something in the input that looked like, “Joe;drop all tables.” That still

happens. That’s obviously not C’s fault, but it shows programmers just can’t

be careful enough. They don’t see all the places. And C makes too many

places. Too scary for me, and I guess it’s fair to say I’ve programmed C only

about five years less than Ken has. We’re not in the same league, but I have

a long track record with C and know how difficult it is and I think C is a big

part of the problem.

As these applications get more complicated, and built on more and more

complicated libraries—and nobody will ever understand the security cracks

in the libraries because they’re so immensely complicated—probably we’ll

have to move toward application-development languages that are more

fault-free. Processors are becoming blindingly fast and memory is becoming

ridiculously cheap. I don’t know what tomorrow’s language is. I don’t think

C or its derivatives such as C++ are going to really be the right vehicle for

heavy-duty program application—even system development—going

forward.

Java didn’t feel right. My old reflexes hit me. Java struck me as too

authoritarian. That’s one of the reasons why I mentioned that Perl felt so

good, because it’s got the safety and the checks but it is so damn

multidimensioned that the artist part of me has a lot of free board to

express things clearly and to think about the right way to do things. I have

some freedom.

Bernie Cosell

560

When I first messed with Java—this was when it was little baby language, of

course—I said, “Oh, this is just another one of those languages to help not-

so-good programmers go down the straight and narrow by restricting what

they can do.” But maybe we’ve come to a point where that’s the right thing.

Maybe the world has gotten so dangerous you can’t have a good, flexible

language that one percent or two percent of the programmers will use to

make great art because the world is now populated with 75 million run-of-

the-mill programmers building these incredibly complicated applications and

they need more help than that. So maybe Java’s the right thing. I don’t know.

Seibel: When I spoke with Fran Allen, who worked at IBM on Fortran

compilers, she was quite upset about C from a completely different

perspective, which was it made it impossible to write really highly optimizing

compilers because it was so low-level.

Cosell: Now, she’s in a different camp. She’s working on compilers; she

sees C as this awful, clunky step down that you can’t do anything with.

Whereas we were working with bit-twiddling assemblers and C was like a

breath of fresh air. So of course most of the very best programmers back

then were not the guys writing BASIC programs and not so much writing

Fortran programs doing calculations. The real heavy hitters were of course

the guys doing all the assembly code. So we went to C because C was like

breath of fresh of air. If you think C has problems with array checks, try

writing your array loops in assembler. So in that regard, it was a great boon.

I don’t want to say that C has outlived its usefulness, but I think it was used

by too many good programmers so that now not-good-enough

programmers are using it to build applications and the bottom line is they’re

not good enough and they can’t. Maybe C is the perfect language for really

good systems programmers, but unfortunately not-so-good systems and

applications programmers are using it and they shouldn’t be.

Seibel: Do you think that the nature of programming has changed as a

consequence of the fact that we can’t know how it all works anymore?

Cosell: Oh, yeah. That’s another thing that makes me a little bit more

dinosaurlike. Everything builds assuming what came before. I remember on

our old PDP-11, 7th edition Unix, we were doing some animation and

Bernie Cosell

561

graphics. That was a big deal. It was hard to program. The displays weren’t

handy. There were no libraries.

Each generation of programmers gets farther and farther away from the

low-level stuff and has fancier and fancier tools for doing things. The good

part is they can do cleverer things. The baseline is so good that the next

thing is spectacular and that then becomes the baseline and two years later

it becomes even better. The trouble is that these baselines are getting more

and more complicated. The PDP-1 instruction set was like a walk in the

park compared to some of the stuff that’s happening.

I would hate to be the guys at Microsoft who have to build these operating

systems that run on the quad-core multiprocessor. Video cards have grown

to the point where they have multiple megs of memory, and complete

pipeline parallel processors on them that can do array and vector things on

the fly. So you now use your video card as this very fancy data processor. I

keep thinking how hard it must be to program these things.

We had a thing called an IMLAC, which is one of the early machines that

actually had a nice integrated vector display on it the way the old PDP-1 did

but it was a mini computer. There was a program for that that had you

sitting on a little cart doing a 3-D display of a maze. So you saw the walls

coming by. You could peek around corners. I was fascinated because it did

hidden-line suppression. This is in the era where guys are writing articles in

Communications of the ACM about algorithms. I have a whole book about

how to use symmetric coordinates and somebody’s algorithm for figuring

out where two lines cross so you know where a line crosses a plane so you

know that that’s where you have to stop the line because it now becomes

hidden.

Doing the hidden-line thing was a big deal back then and that program did it.

I was just stunned by that program. That was big deal code—singular stuff.

Now, as far as I can tell, the video cards take 3-D coordinates and the video

cards do the hidden-line suppression. Eight, nine years ago things like

texture mapping and ray tracing were big deals. Hard to do in code. It took

your program hours to get the glint off of a sphere.

And now I discover that video cards do the ray tracing. So on the one hand

you have these guys working at NVIDIA and stuff who must be doing

Bernie Cosell

562

incredibly complicated stuff and you have the modern programmer who no

longer can be content just writing a thing with little line-drawn walls—he

has to master this incredible 3-D video environment that’s built on libraries

that have gotten more and more complicated. They’re easier than it would

be to write the code yourself, but I can’t fathom how people can absorb all

of that these days. It just seems so huge to me.

I run into that just with doing Tk. I’ve been trying to do a little Tk program

and I am stunned by how complicated Tk is and how many hooks it’s got,

and it’s what you need to do in order to make the button be bigger or

smaller or here or there. Mastering that thing is just a huge thing.

Understanding the PDP-1 time-sharing system was simple by comparison.

So I don’t envy modern programmers, and it’s going to get worse. The

simple things are getting packaged into libraries, leaving only the hard things.

That stuff is getting so complicated, but the standards that people are

expecting are stunning. One of the ones they showed me stunned me. He

was showing me Google Maps that will do routes for you. One of the things

you can do is you can grab a piece of the route with your mouse and drag

that piece of the route somewhere else to tell Google that you want the

route go there. Then it remaps the route so that it goes through where you

just dragged the point. Now I know what’s going on in there: a pile of

JavaScript code for the mouse tracking. When you let go of the mouse it has

to do an Ajax XML request to tell momma system that he just put this point

on the route. The route then has to do incremental updates. Calculating the

route. I can’t even imagine how they do that code so well. People complain

that you get routed through people’s backyards and stuff like that, but the

optimal-route problems are one of the classic problems of computer

science. How to take this arbitrary graph and find the shortest path through

a graph. Just stunning.

At one level I’m thinking, “This is way cool that you can do that.” The other

level, the programmer in me is saying, “Jesus, I’m glad that this wasn’t

around when I was a programmer.” I could never have written all this code

to do this stuff. How do these guys do that? There must be a generation of

programmers way better than what I was when I was a programmer. I’m

glad I can have a little bit of repute as having once been a good programmer

without having to actually demonstrate it anymore, because I don’t think I

could.

Bernie Cosell

563

This is a good time to be an over-the-hill programmer emeritus, because

you have a few props because you did it once, but the world is so wondrous

that you can take advantage of it, maybe even get a little occasional credit

for it without having to still be able to do it. Whereas if you were in

college—if you major in computer science and you have to go out there and

you have to figure out how you are going to add to this pile of stuff—save

me.