Seibel Peter. Coders at Work

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

C H A P T E R

Fran Allen

Planning to be a math teacher but needing to pay off her student loans, in 1957

Fran Allen took what she intended to be a temporary job as a programmer at IBM

Research. Her first assignment: teach resistive IBM scientists the newly invented

language Fortran.

Instead of returning to teaching, Allen stayed at IBM for 45 years and worked on a

series of compiler projects, including the compilers for the STRETCH-HARVEST

machine and the ambitious but never-built ACS-1 supercomputer as well as her

own PTRAN project, which developed techniques for automatic parallelization of

Fortran programs and developed the Static Single Assignment intermediate

representation, which is now widely used in both static and just-in-time compilers.

In 2002 Allen was awarded the Turing Award for her “pioneering contributions to

the theory and practice of optimizing compiler techniques,” becoming the first

female recipient in the 40-year history of the prize. She was also the first woman

to be named an IBM Fellow, IBM’s top technical honor. She is also a fellow of the

IEEE and the Association for Computing Machinery and a member of the National

Academy of Engineering, the American Academy of Arts and Sciences, and the

American Philosophical Society.

Over her career, Allen has observed the changing role of women in computing,

from her earliest days when women were specifically recruited by companies like

Fran Allen

486

IBM for the new and ill-defined job of “programmer,” to later decades when the

field became largely male-dominated.

In our conversation she talks about what that transition was like as well as why it

is important to increase the diversity in the field and how C has grievously

wounded the study of computer science.

Seibel: How did you get involved in programming? I know you started out

planning to be a math teacher but took a job at IBM in order to pay your

student loans.

Allen: To be a fully certified teacher in New York state required a master’s

degree. I had an undergraduate degree in mathematics, a minor in physics,

and had taught for two years. Then I went to the University of Michigan and

focused very much on mathematics. At the University of Michigan, in order

to get a master’s degree, one had to take two courses outside one’s field, so

I took a course on computing. Computer science didn’t exist then, in 1957.

It was ten years later that it started to emerge seriously. But they had a

couple of courses in the engineering school.

Seibel: What did they teach you?

Allen: They had an IBM 650 machine, which was quite a different machine

than what we’re used to today, and the students learned to program that

machine. That involved not only learning all about the machine itself and

coding in, essentially, assembly language but also running your programs on

the machine. It was a really hands-on experience.

Seibel: So you would punch your deck, take it to the machine yourself, and

feed it through yourself?

Allen: Right. And then go and fix it. It was a drum machine—the drum was

constantly spinning and that’s where your instructions were. So the way one

got it to run fast involved spacing the placement of the instructions on the

drum so as it turned the next instruction would be in the right place.

Fran Allen

487

Seibel: Then the IBM recruiters came around. What was it about working

at IBM that appealed to you?

Allen: Well, I just needed a job. I had this debt and the recruiter came on

campus and it was in the right geographical area, back in New York state. So

I filled out an application and really didn’t realize much about what group I

was interviewing with, the fact that it was IBM Research. I was kind of

clueless about that.

A few weeks later I got a call while I was interviewing for a faculty job at a

teacher’s college in southern Illinois. I was really getting desperate—it was

time to get a job and I didn’t have one. So I got that call while I was on the

road and took the job, sight unseen, and got the papers to report at what

turned out to be the research laboratory in Poughkeepsie.

So I went there and got started as a programmer. IBM was expanding

rapidly into computing and there weren’t any computer-science courses, so

they were hiring people from wherever they had found them.

Seibel: What kind of training did they give you?

Allen: Well, it was a kind of a learn-as-you-go, as I recall. There was an

orientation to the company but I don’t recall there was any programming

class per se, which is odd in retrospect. I suppose there were some classes,

depending on what your background was. It was all very informal.

The first assignment I got, because I’d been a math teacher, was to teach the

scientists and other programmers Fortran. I had joined in July of 1957 and

Fortran had been issued as a product on April 15 that same year. And IBM

Research—the group I was in—had an edict that by September all the

programming had to be done in Fortran. That was the way to convince their

own people, just as they were trying to get outside people to, to use it.

Seibel: So these were scientists within IBM, doing their own scientific

computation?

Allen: Yes. The machine they had was the 704 machine and that’s what

Fortran was originally designed for and optimized to. They were used to

writing in assembly code right on the machine, doing the same thing I had

Fran Allen

488

done at the University of Michigan, running their own programs—scheduling

some time and running the programs. They did not believe that it would be

possible for any high-level language to do nearly as well as what they could

do programming the machine itself.

Seibel: And that was the last time scientists adopted a new language,

because they’re still using Fortran, right?

Allen: That’s right. Well, it was an unhappy class. But in the end, it was an

amazing experience for all of us because Fortran was not only a language,

but they had provided a compiler which was extremely advanced, and laid

the foundations for the structure of compilers today.

Seibel: The next big project that you worked on, that I know about, was

the Stretch computer. Did you work on anything in between this time and

the Stretch project?

Allen: There were two projects that I was involved with between Fortran

and the Stretch compiler. One of them was the Monitored Automatic

Debugging system, which was down at the assembly level for the 704. I

really enjoyed that.

It was a very early operating system. There were three of us who worked

on it. We installed some buttons on the computer, because you could do

that, at that time and one was a panic button. When the program appeared

to loop one could just push the panic button. Then we wrote the debugger,

and one of my tasks was to take the assembly-language program and

produce the column binary—rotate the output of it. When you used a card

reader the data was row-binary, which means each row contained the bits

that were associated with the instruction, but on tape things were read

differently, so it needed to be column-binary. I still have the program.

One of the things I remember really enjoying is reading the original

program—and considering it very elegant. That captured me because it was

quite a sophisticated program written by somebody who had been in the

field a while—Roy Nutt. It was beautifully done.

Seibel: What makes a program beautiful?

Fran Allen

489

Allen: That it is a simple straightforward solution to a problem; that has

some intrinsic structure and obviousness about it that isn’t obvious from the

problem itself. I picked up probably a habit from that of learning about

programming and learning about a new language by taking an existing

program and studying it.

Seibel: How do you read code? Let’s say you’re going to learn a new

language and you find a program to read—how do you attack it?

Allen: Well, one example was one of my employees had built a parser. This

was later on for the PTRAN project. And I wanted to understand his

methods. It’s actually probably the best parser in the world—now it’s out in

open source, and it’s really an extraordinary parser that can do error

correction in flight.

I wanted to understand it, so I took it and read it. And I knew that Philippe

Charles, the man who had written it, was a beautiful programmer. The way I

would approach understanding a new language or a new implementation of

some very complex problem would be to take a program from somebody

that I knew was a great programmer, and read it.

Seibel: And how do you get into a piece of code like that? Do you trace

through the execution? Or read from top to bottom and just build a

structure in your mind? It’s a sort of tricky reading problem.

Allen: Well, it is a tricky reading problem, but I usually had some intuition

about or learned what the structure of the solution was, and then would go

in and start maybe in the middle and look for the kernel piece. And it was a

wonderful way to learn not only the algorithms that were used but how to

use the language in an elegant way.

Seibel: Do you have any favorite debugging war stories?

Allen: There were a couple. I remember one from the MAD system. The

machine operator called me in the middle of the night because it wouldn’t

run a program that had been submitted for running overnight. There was a

way in which we did automatic checksumming to ensure that the data was

right because the machines themselves didn’t have much error detection,

and no error correction.

Fran Allen

490

I couldn’t figure it out on the phone. It took a little while, but suddenly I

realized that the way I had built the checksumming piece of the system did

not handle a particular case. Even when the program was correct it couldn’t

pass that barrier because of the way I had calculated the checksum. And I

called the man back and there was a way of getting around it.

Then there was another one where—this one I remember because I was

very pleased with myself—I had an employee on Stretch who preferred to

work all night. He came in in the morning and he was a very intimidating

man—giant guy and a very serious fellow. And he threw a debug listing

across my desk—a dump of the program—a huge, thick thing. And he

pointed to one particular bit in that dump, and he said, “Why is that bit

set?” He had been worrying all night on it. And oddly enough, I knew why. It

wasn’t a bug but it was something that he didn’t know what it was there for

and had been assuming that that was the cause of the error.

Seibel: So that was later; you said there was another project between

MAD and the Stretch.

Allen: Yes. It was for a scientist here that was doing wiring diagrams for the

hardware. It had to do with laying out wires on what passed for chips at

that time. It was a mathematical solution we were implementing and it had a

lot of constraints, of course, because of the size of the real estate. I was

working as a programmer on that. There were two of us, maybe three—all

women.

Seibel: And then it was on to the Stretch project, which was a big one.

Allen: From my experience with Fortran and knowing that compiler very

well, I got drafted from Research to go and work on the next big project at

IBM—the Stretch machine. It started in 1955—it got the name Stretch in

’56 I guess—and was going to be 100 times faster than anything else in the

world—an absolutely amazing machine.

It was well recognized that the compiler was going to be key to the success

of the machine and that the biggest challenge to achieve that performance

was going to be access to memory and that the compiler played a big role in

that.

Fran Allen

491

Seibel: Because dealing with the memory latency was going to be more

complex than programmers writing assembly by hand were going to be able

to handle?

Allen: Yes. And because the memory-latency problem was being solved by

a lot of concurrency in the hardware—very complex concurrency. And the

memory organization itself was multiway-interleaved and it was

unpredictable what order data would be delivered to the computational

unit. Six accesses could be in flight at the same time. There were pipelines in

the computational unit itself and there was an ability for multiple

instructions to be in execution at the same time. And the most complicated

unit on the machine was a look-ahead unit, because they had precise

interrupts as part of the architectural design, so not only did it have to keep

track of all the concurrency going forward, but they had to back it out when

there was an interrupt.

It was an extremely complicated machine and a wonderful one to program.

The compiler had a very big challenge in order to take advantage of it. It was

a wonderfully challenging project.

So a bunch of us were drafted out of Research to come and work on the

compiler and the operating-system software itself. The compiler itself was as

grandiose as the machine. I ended up, because of my previous exposure to

the Fortran optimizer, involved with the optimizer for the Stretch

machine—the Stretch Harvest, as it turns out. The outlines of the compiler

were established by a different committee but there were four of us who

were given the charge of filling in the details, including the interfaces in the

compiler and what the specs were for that and taking charge of the different

pieces of it. I had the optimizer, and somebody else had the parser, the

Seibel: How was the project structured in terms of the technical people

working on it?

Allen: Well, there were around three people who laid out the overall

design of the compiler—we’re going to have a parser, we’re going to have

this and that, and then where it fit. And there was somebody above them—

this was a product, so there were more layers of decision-making and

management.

Fran Allen

492

Then they needed to have project overseers for each of the big

components. So they asked four of us, three of us being women, to get

involved, to get together as a team and design the interfaces.

Seibel: And then were there other programmers working on the actual

implementation?

Allen: Yes. I had a group of 17, all doing programming.

Seibel: What was the relation between the design phase and the coding?

You four got together and sorted out the interfaces between the parts. Did

that all happen before your 17 programmers started writing code, or did

the coding feed back into your design?

Allen: It was pretty much happening as we went. Our constraints were set

by the people we reported to. And the heads of the different pieces, like

myself, reported to one person, George Grover, and he had worked out

the bigger picture technically. And a lot of it was driven by the constraints

of the customers. There was a lot of teamwork and a lot of flexibility at the

time, in part, because we were kind of inventing as we went. But under a

deadline. So there was not as much management hierarchy, but just being

more part of the team.

Seibel: Did the people below you ever write code that would then force

the realization that some of the higher-up decisions about how the pieces

were going to fit together had to be revisited?

Allen: Yes, how this interface is not going to work. Keeping track of how

things were coming together was a part of it. We would meet as a team, the

four of us. But most of our time was spent on trying to build the

component that we were responsible for—there was a lot of freedom.

Software engineering came much later. There wasn’t software engineering

and there weren’t big processes set up yet. On a subsequent project, the

360, run by Fred Brooks, which I wasn’t involved with, the software was a

huge crisis. The engineering on the 360 was doing pretty well around ’63.

And some engineers moved over from building the machines—hardware

engineers—guys that just knew nothing about software—to run the

software because it was so out of hand. And it was really a mess.

Fran Allen

493

After the 360 got shipped one of the people—I don’t know that he’d been

involved with the 360—wrote a letter to the higher-ups in IBM proposing a

software-engineering discipline called Cleanroom. He made statement that if

you followed all these set of processes he was laying out, you could write

perfect programs. And because of what management had been through—

this is my version—they bought the whole thing.

Seibel: Because the 360 project had been so painful?

Allen: That’s right. So IBM product development moved very strongly over

to the Cleanroom processes—a whole set of processes. One of the things

was that there would be somebody that would set objectives and there

would be another group that did the design. And the designers would

specify the design to the detail that the programmers could write to the

designs. And these groups were not interactive—you just did this cleanly

enough, and perfect software came out.

Seibel: On the 360 project, Brooks was in charge of both software and

hardware, right?

Allen: Yes, I think he had the whole thing. But he replaced some of the

software heads with people with hardware experience. And it was really the

right thing to do because the hardware people already had a wonderful

discipline around building hardware—the chip design and the testing process

and all of that. And that was an older and much more rigorous ways of

expressing designs. We software people were just making it up.

Seibel: So you feel that, at least on that project, that they brought

something to the software-development process that saved the project?

Allen: It was absolutely necessary, but it was so painful for the software

people to have these guys—all guys—move in, knowing nothing about

software, and just impose design reviews, design specs, all of this stuff.

Seibel: So it did help save that project. Did that embolden folks to take this

next step to the Cleanroom process that was sort of a step too far?

Fran Allen

494

Allen: Yeah, I think it did. That was the sequence. And the Cleanroom

process, the waterfall process, came in through management with a very

strong advocate for it.

Seibel: And that advocate was from the hardware side?

Allen: No, the advocate was from the software side. But I don’t think that

he had been part of the 360 project, in the depths of trying to rescue that.

But some of us who already had some experience with software structure

were appalled at the statements at the time. But sometimes one has to

make bold claims in order to sell something.

Seibel: Did you ever work on a project where that kind of process was

used?

Allen: Oh, yes. And found it frustrating because in its early stages, a

designer and the programmer could not interact. One of the problems

was—probably still is—that the life cycle of a piece of software is very long.

And at that time, if you were building a big piece of software, it took

months and months or years. And the environment changed and the

requirements changed. And the customers really did have the say in what

they wanted in the end.

Seibel: Would you then push changes all the way down through the

process? Or did people start short-circuiting the process, going directly to

the programmers and saying, “All right, we figured out the customer needs

X”?

Allen: Yeah. One could never really write specs that were going to be

adequate and useful at a detail level over the years of the life cycle. That was

a problem. And now we have another process, of course—just do it and

throw it away, kind of.

Seibel: Well, it was Brooks, in his famous book, who said, “Build one to

throw away because you’re going to.”

Allen: Yes. And in fact, that is true—I very much believe that. But lots of

times, that has led, in my opinion, to not thinking at all before you start

building.