Книга: Coders at Work: Reflections on the craft of programming

Fran Allen

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 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.

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 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?

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.

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.

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 register allocator, and the interface with the assembly program.

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.

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.

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?

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.

I always like to have a picture—a model. Often a flowchart and some specification about the interfaces. We were heavy users, of course, of flowcharts at that time because one didn’t get access to the machine that often and that was a very nice model for thinking through how parts of the system would interact, what would be done, and specifying what would be done where, and the functionality of the various components. I don’t know what the analog of that is now.

Seibel: Even with flowcharting, there are formal flowcharts produced as documentation and then there are the flowcharts you draw on a blackboard to try and understand something. Was it more of the former or the latter?

Allen: In some cases, it would be formal flowcharts. Often in the kernels of things there were some very complex pieces and one would do that. Otherwise, it was just informal and a way of working at solving a problem. Blackboards would be covered and become the record for the month or whatever period of time.

Seibel: So the big project you led was the PTRAN compiler project, which was when you first started working on explicit concurrency, as opposed to the implicit concurrency in the CPU pipelines and so forth. When you started that, that was a new thing, both for you and for IBM.

Allen: It was new for IBM, but we were very, very late coming into it. The great work that initiated it from a real pragmatic point of view was at Illinois starting in ’69 and ’70.

Seibel: And what language did the PTRAN compiler compile? Was it straight Fortran with no added constructs for parallelism?

Allen: That’s right, that’s where we started from. What I wanted to do was to do the same thing we’d done for optimization: The user writes a sequential code in the language in a way that’s natural for the application and then have the compiler do the optimization and mapping it to the machine and taking advantage of concurrency.

In PTRAN, the idea was still to take the “dusty decks,” as we called them, referring to an existing code base, and to automatically take advantage of the hardware’s parallel components.

Seibel: So, essentially, that was targeting what today we would think of as symmetric multiprocessors?

Allen: Yeah, could be. There are many, many models of parallelism, which is one of the difficulties. I think that that can be greatly simplified. But multicore is one of the things that really are particularly interesting, for me at least. But there are many models of parallelism.

We actually built it from existing work, particularly Dave Kuck’s. Some work from NYU. We hired a group of newly minted PhDs from these places that already had built up a lot of expertise. We had a quite a lot of significant results, both on the practical and on the theoretical side—we worked on both at the same time. I’m a very strong believer that one wants to be able to take the practice into identifiable algorithms, and theory, and ways of thinking about how to solve the problems and also to take the algorithms into practice to see how really valuable they are, and how they apply. I think our field is best done when it works on both sides on the same projects.

Seibel: On the PTRAN project, you were leading a team. Were you still coding at all by then?

Allen: I wasn’t doing the coding, but I was very close to it. As an example, when the Static Single Assignment work was done, I didn’t see how it could be implemented in any reasonable time. I mean, it was a very good algorithm, but I didn’t see an implementation that was bounded in time and space in some real way. So I had that challenge out there. I had to see that code. I needed it. It had to be implemented. It couldn’t be just a paper—a very nice paper, a famous paper—that shows graphs and complexity bounds.

If we can’t implement it in a real system, that challenge would still be out there. It wasn’t going to be as useful as I wanted it to be. Finally, one of my people had an encoding. And I walked through that, every piece of that code, and looked at the data structures that were used. And it was astounding. I said, “This is it. It works.”

Seibel: So you were looking at all of the pieces that were going to go into the whole system?

Allen: Yes, yes, yes.

Seibel: You also were managing all these people? Or were you a technical architect with someone else managing the group?

Allen: No, I was the research manager for the group. There were about 10 or 12 core people and we divided the work up so that each person really had ownership of a piece of it.

Seibel: People have been debating at least since Gerald Weinberg’s book The Psychology of Computer Programming whether it’s better for people to “own” code, so they take responsibility for it, or to have people work more collaboratively so you avoid having silos that only one person understands. It sounds like you thought dividing up the ownership was the way to go?

Allen: We worked collaboratively, but the collaboration was about the state of the system, of the implementation. And some people were very good at the implementation, and so they’d own a piece—some piece of the optimizer or the intra-procedural analysis was definitely one or two people. But also, there were a number of people that were doing a lot of the theory work, or the abstract work of writing the papers, and writing a lot of the papers and algorithms. And it was the bringing together of those two special parts that I think really made the group so strong.

This was a period of a lot of work going on in the analysis and transformations for parallelism. So what I tried to do was, for each of the people that were doing theory to get them to write some code, express it in code as a part of the system. And the people who were just doing the other part, well I’d try to get them to write things up so they were more generally available.

Seibel: A lot of programmers will do anything to avoid becoming a manager. Was managing something that you also enjoyed?

Allen: Well, Research in the earlier times did not distinguish—doing management was not a promotion, not a salary raise. It was just somebody had to manage this piece of work, and “OK, don’t you want to do it?” Or, “You’re the obvious one to manage this piece of work.” And it was technical management; there wasn’t much people management involved. But in Research people are RSMs, Research Staff Members, the day they enter, and for the rest of their career mostly. All my colleagues, that’s what we are. So one moved in and out of management without any stigma attached.

Seibel: So presumably the people who got chosen to manage were the ones who were actually good at it. How did you pick up those skills?

Allen: Well, I was sent to management school. Everybody was, back when I was first appointed. But I think it goes back to when I grew up on the farm. I was the oldest of six kids and there were five of us in a row, so my parents were pretty overwhelmed. So it was a natural role for me in some ways.

Seibel: One of the difficulties of the kind of technical management that you were doing is finding the balance between having your own technical opinions about how stuff should be done and giving people room to put their own ideas in.

Allen: I think I had some hard lessons on the Stretch project. I remember some of the people on the project came in and said to me one day that we ought to be using list and hash functions. Well, we knew about list programs but hashing was new. So a couple of my people came and said they wanted to use hashing for the symbol table. And I said, “No, we can’t do that. We don’t know how to do that.” Yadda, yadda, yadda. The next Monday I came in and they had done it. They had torn down the system and rebuilt it with hashing. It worked, and it was much faster. So that was a big lesson to me. I should be much more open to some brand-new ideas.

Seibel: So sometimes—maybe even often—your people actually know what they’re talking about and you shouldn’t interfere too much because you might stomp out a good idea. It’s trickier when you’re really right and their idea really is a little bit flawed but you don’t want to beat up on them too much.

Allen: There was some of that. It was often where somebody came in with a knowledge of some area and wanted to apply that knowledge to an ongoing piece of project without having been embedded in the project long enough to know, and often up against a deadline.

I ran into it big time doing some subcontracting work. I had a group of people that was doing wonderful work building an optimizer based on the work we’ve done here for PL/I, a big, different language. But one of the people working for the subcontractor had just discovered object-oriented programming and decided that he would apply it to the extreme. And I couldn’t stop him, even though I was the contract overseer, and the project was destroyed. Ultimately, what did it was PL/I has lots of pointers and tracing a pointer is done all the time, and it took 11 instructions to trace the value, to find the value of one pointer consistently.

Seibel: You mean in the generated code.

Allen: In the generated code and in the compiler itself because it was bootstrapping the compiler. Every time you made a step you had to check that the thing’s valid. And you were checking, and rechecking, and rechecking. It still happens today. Some of these lessons we haven’t learned well. And I guess I was not dealing with it very well, because I should have just pointed out what the cost of applying object-oriented technology in that kind of situation. It was just hopelessly slow, so the whole thing got canceled.

Seibel: When were you most directly building a product for IBM, with production deadlines that had to be met?

Allen: Certainly, the Stretch project was that way. And I’ve worked in product development two or three times, and been in the situation where one has week-by-week code reviews right up against deadlines. I have a lot of respect for those processes and how important they are for the end result and for the team that’s doing it. It can be very painful to sit there every Friday and do code reads with people explaining why they’re doing what they’re doing and finding other people’s errors.

Seibel: Painful, but worthwhile?

Allen: Absolutely worthwhile. On the PTRAN project, towards the end when we were shipping a piece of it to the products, a half a day was devoted to explaining errors in our code, their code, whatever it was, every week. That went on for ten months, I think. Devoted Friday afternoon to it.

Seibel: When you were working in those settings did you feel like you had a process that let you estimate how long it’s going to take to build X amount of software with any kind of accuracy?

Allen: Well, they did. The product-development people certainly did. It was all tracked, and I’m sure it still is. Part of it would be to statistically get a handle on the quality of the code. How many bugs showed up this week, yeah. I liked the environment of a product lab because it’s sort of where things get real.

Seibel: When you were hiring programmers what did you look for?

Allen: Well, I had a lot of connections in the universities. NYU had some fabulous compiler-writer faculty—that group was really well-trained to write compiler code.

Seibel: So you could hire people recommended by the professors you knew and trusted. How about when you have to interview someone who doesn’t come with a recommendation from someone you trust—how do you figure out in the course of a couple of hours whether they are going to be a good programmer?

Allen: I always start with interviewing anybody for IBM Research by trying to find out what they’re excited about. That’s kind of a basic threshold for me. And it doesn’t matter whether it has anything to do with programming or computers. If they can’t get enthusiastic about something, they’re not going to get charged up in a group.

Sometimes one takes a high risk. I took a high risk on a guy whose thesis adviser wrote that he was very dyslexic. He didn’t work out so well here because he didn’t fit in some ways, but he started his own company and I still go to him for advice, for insights on how to do things technically. He just knows things. So that wasn’t a mistake. It was a mistake in terms of the project, but not in terms of his relationship with a lot of us.

Seibel: Lately you’ve been involved in mentoring—there’s a mentoring award here at IBM that is named for you. Do you have any ideas about how new programmers should be brought along into being better programmers?

Allen: That aspect of mentoring, I don’t get very close to these days. What I do do, though, is encourage a young person starting out to not jump into becoming a manager, which is very tempting for people who have a talent in that direction. Get a reputation for technical work. Whether it’s a nice piece of science, an algorithm, or writing great code—whatever it is, establish a strong reputation there first. That’ll serve you well if you do want to go to managing projects and so forth, to have learned the discipline of what it takes to do that and how to function in that way.

Seibel: Is it possible to have a great manager who’s actually not very technically skilled, but is very good at organizing the efforts of others?

Allen: Yes, as long as he doesn’t think he’s good at the technology, and is able to distinguish between who is and who isn’t in the people that work for him.

Seibel: That’s probably the trickiest thing. For you, what distinguishes the really best programmers?

Allen: Well, I always like to find the people who can turn a light bulb on over my head. That’s really important for me because I spend a lot of time thinking about systems, so I like to have people that will be able, at least in Research, to show me something new and interesting or a new way of looking at something—a new way of solving a problem.

Also, I rely on what other people think. I’ve been wrong plenty and it’s a real learning experience when I find myself thinking more highly of somebody than the group does. If you have a good group, it’s a very good way of sorting out who’s doing good work.

Seibel: When do you think was the last time that you programmed?

Allen: Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a project that I had at that time supporting automatic optimization.

The nubbin of the debate was Steve’s defense of not having to build optimizers anymore because the programmer would take care of it. That it was really a programmer’s issue. The motivation for the design of C was three problems they couldn’t solve in the high-level languages: One of them was interrupt handling. Another was scheduling resources, taking over the machine and scheduling a process that was in the queue. And a third one was allocating memory. And you couldn’t do that from a high-level language. So that was the excuse for C.

Seibel: Do you think C is a reasonable language if they had restricted its use to operating-system kernels?

Allen: Oh, yeah. That would have been fine. And, in fact, you need to have something like that, something where experts can really fine-tune without big bottlenecks because those are key problems to solve.

By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are… basically not taught much anymore in the colleges and universities.

Seibel: Surely there are still courses on building a compiler?

Allen: Not in lots of schools. It’s shocking. there are still conferences going on, and people doing good algorithms, good work, but the payoff for that is, in my opinion, quite minimal. Because languages like C totally overspecify the solution of problems. Those kinds of languages are what is destroying computer science as a study.

Seibel: But most newer languages these days are higher-level than C. Things like Java and C# and Python and Ruby.

Allen: But they still overspecify. The core thing is that it specifies location of data. If you look at these other languages, they stayed away from specifying the location of data and how to move it, where to put it in the machine. It was ultimately about its value at any point.

Seibel: But very few languages other than C and C++ have raw pointers anymore. Java has garbage collection and the data moves around. Would you say that’s still overspecified?

Allen: Yes. I believe that there’s an opportunity to do what we have done with computation in the optimization world with data. We don’t manage data very well. We don’t have good ways of managing data automatically—establishing locality of data that’s going to be used together.

There are lots of threads of research now which are very exciting. But I think what’s missing is the bigger, bolder concepts. A lot of this is happening within a space that is bounded by what exists already or the current thinking. It’s not going to change overnight by any means—there are millions of lines of code out there. But we do need to start trying to break the boundaries of, “This’ll be done here and that’ll be done there.”

Seibel: Your career has been largely in high-performance computing. Yet by 2019, or whatever, we’re supposed to have 1,000 cores in a notebook computer. Does that mean high-performance computing and everyday computing will merge? Or will high-performance computing always be out there doing things in a sufficiently different way?

Allen: Well, it kind of depends on where one is on the scale. To go to the petaflop, which is our current goal in high-performance computing—I don’t know how that’s going to go. Certainly the game in performance is going to be at the multicore because it’s driven by reducing energy and lots of good things and solving some problems with the basic physics.

And there’s a competitive element that’s just going to drive it. But harnessing those multicores pushes the problem out of the hardware space into the software space. And that is where we’re not prepared to make any progress as far as I can see. To harness these multicores—I think that’s where the new language levels are going to have to break in. We should do an end-to-end look at it. But it’s going to take some very new thinking.

I think these first 50 years—60 years maybe; ENIAC was in ’44, ’43—we’ve built up not only a wonderful, amazing legacy—just astounding—but also some artifacts that we need to get rid of. It’ll take a very long time to replace these and I think it’s a little hard to predict how that will evolve. But it’ll evolve very fast if we can get some new thinking going in the right places. We know how to do computations on a lot of stuff. We don’t know how to deliver the data to the computation elements in the machine.

Seibel: Can you give a simple example of what you mean by bringing the data to the computation in contrast to what we know how to do now?

Allen: To me it means taking over the management of the data. Basically, how we do it now is by reference—it’s moved by hardware, or by the underlying operating systems and support systems. And often the references are at an element level.

Seibel: You mean in the sense that you can have a pointer into the middle of a struct or an array?

Allen: Yeah, into an element of it. And that brings, depending on the protocols of the hardware and of the architecture itself, the value to where it can be used as part of the computation.

But another way to do that would be to organize locations of data in their relative positions as a target of optimization. The other part of it is that very often what is good for one computation is poor for another. One organization, even of simple things like matrices, is bad when you’re actually accessing it in a different way. So it’s a combination of the order of the accessing against the location. It may require some architectural work, and hardware work, but I think that one can do this if we put some of the referencing, addressing capabilities back out in the hardware itself. There are machines where one has the ability, at the point data comes into the memory, to do quite a lot of transformations. Mapping can happen there.

Computation speed is what we measure, mostly, in high-performance computing so we go through all kinds of things to increase that speed. Feeding that computational unit is one of the big issues that we face, but we never made it a first-order problem to solve. We leave it to the hardware.

Seibel: In your Turning Award lecture you said something along the lines of, “We’re at a crossroads here and we might miss it. We might go down the wrong path and then be going down it for quite a while.”

Allen: Yeah.

Seibel: So the right path, in your view, is getting back to that kind of work in automatic parallelization?

Allen: Right, but it has to be done against a higher-level language than we have now.

Seibel: And the wrong path is finding better ways for people to express parallelism explicitly?

Allen: Well, I think we would eventually realize that we’ve created more of a mess than we had. But we do need higher-level languages and there certainly are domain-specific languages, and ways of developing things, which are really quite wonderful.

But we have to be willing to try and take advantage of that, but also take advantage of the integration of systems and the fact that data’s coming from everywhere. It’s no longer encapsulated with the program, the code. We’re seeing now, I think, vast amounts of data, which is accessible. And it’s numeric data as well as the informational kinds of data, and will be stored all over the globe, especially if you’re working in some of the bioinformatics kind of stuff. And we have to be able to create a platform, probably composed of a lot of parts, which is going to enable those things to come together—computational capability that is probably quite different than we have now. And we also need to, sooner or later, address usability and integrity of these systems.

Seibel: Usability from the point of the programmer, or usability for the end users of these systems?

Allen: Of the end users of these systems. It’s a resource, a giant resource. And the integrity of the correctness of the systems. I worked on project for the NSA on risk management, quite a few years ago, and it suddenly dawned on me that we often, in high-performance computing, do not need to compute to the accuracy that we have. We do not need all the data to be able to make progress on a solution. And so there’s some nice work going on in the data side, I think, with accommodating good enough answers. I see these multicores—they’re a wonderful opportunity—to go back and to take another look at lots of things.

Seibel: Do you think of yourself as a scientist, an engineer, an artist, or a craftsman?

Allen: I think of myself as a computer scientist. I was involved in my corner of the field in helping it develop. And those were interesting times—the emergence of computer science—because there was a lot of question about, “Is this a science? Anything that has to have science in its name isn’t a science.” And it was certainly unclear to me what it meant.

But compilers were a very old field—older than operating systems. Some day want I to really look it up. The word compiler comes actually from the embedding of little snippets of instructions to execute. Like an add would be spelled out in very primitive terms for the machine. If you want to do an add, then it would go to its library that defined that and expand it.

But assemblers were also using symbolics. I’m not sure this is accurate, but I used to believe that the first early use of symbolics for names of variables came from a man named Nat Rochester, on a very early IBM machine, the 701 around 1951. He was in charge of testing it and they wrote programs to test the machine. In the process of doing that, they introduced symbolic variables. Now, I’ve seen some other things since that make me believe that there were earlier ways of representing information symbolically. It emerged in the early ’50s, I think, or maybe even in the ’40s. One would have to go back and see exactly how things were expressed in the ENIAC, for one thing.

Seibel: So somewhere along the line, you realized you had become a computer scientist, developing theories about compiler optimization and so forth. But you started out as a programmer, hired to write code. By the time of the PTRAN project you were managing a team of people who were actually writing the software. Why did you make that switch?

Allen: Well, probably two reasons—one, I wasn’t a very good programmer. I tended to make quite a few mistakes—unlike the conventional wisdom at the time that said that women make good programmers because they pay attention to details. I didn’t fit that category. So I tended to be kind of disinterested in getting all the details right and I was much more interested in the way systems work.

My interest in mathematics was very abstract. If I had had enough money to go on to get a PhD, I would have become a geometer. I loved the rigor of that process. That’s what I really most enjoy, puzzling through systems—puzzling through the engineering kinds of things without necessarily knowing the details of what one would need to know to be an engineer, which is quite a different area.

Seibel: The way you contributed technically to the PTRAN project, it sounds like you had the big architectural picture of how the whole thing was going to work and could point out the bits that it wasn’t clear how they were going to work.

Allen: Right.

Seibel: Do you think that ability was something that you had early on, or did that develop over time?

Allen: I think it came partially out of growing up on a farm. If one looks at a lot of the interesting engineering things that happened in our field—in this era or a little earlier—an awful lot of them come from farm kids. I stumbled on this from some of the people that I worked with in the National Academy of Engineering—a whole bunch of these older men came from Midwestern farms. And they got very involved with designing rockets and other very engineering and systemy and hands-on kinds of things. I think that being involved with farms and nature, I had a great interest in, how does one fix things and how do things work?

Seibel: And a farm is a big system of inputs and outputs.

Allen: Right. And since it’s very close to nature, it has its own cycles, its own system that you can do nothing about. So one finds a place in it, and it’s a very comfortable one.

Seibel: You mentioned earlier that when you were working on the Stretch compiler, that three of the four people leading the compiler effort were women. Can you talk about how that came about?

Allen: This was in ’59, something like that. Women were playing a big role at that time as programmers. And IBM has always been a great, great company on that. I saw some history recently, that IBM’s diversity policies go back to 1899, just consistently, all through these periods when there wasn’t much attention being paid to that—very explicit policies.

Seibel: Do you think the number of women on that project was due to explicit management policies—that they were saying IBM should hire more women?

Allen: I don’t think they said, “We must hire more women.” They just hired whoever was qualified, and it wasn’t just women. These were really hard times for African-Americans, and IBM really stepped out. One story that’s not very well known is there was segregated housing in Poughkeepsie at that time, regarding blacks, and IBM got it changed.

Seibel: You told a story in an interview once about one time you arrived at a conference. And they looked at you and said, “Fran Allen?”

Allen: “You’re a woman.”

Seibel: “We have you rooming with Gene Amdahl.”

Allen: Oh, yes, that one. This was an IBM conference, when we were moving the System Y project that was going on here to the West Coast into product development and had renamed it ACS. We had a big conference at the Harriman Estate across the river. It was all, with one or two exceptions, IBM people. There was a person from the West Coast who was charged with organizing it and he didn’t know any of us. He’d done it alphabetically.

Seibel: So they sorted you out and found you a room by yourself?

Allen: Yeah, a maid’s room up in the garret.

Seibel: Did you publish papers under Fran or Frances?

Allen: F.E. Allen. And I don’t recall why I did that. I think it was fairly common, at the time at least, to just use first initials.

Seibel: You also mentioned before that when you started, people thought women would be good programmers because women were thought to be detail-oriented. These days the conventional wisdom is that it’s men who have a bizarre ability to focus on things, usually to the detriment of everything else, and that’s why most programmers are men.

Allen: Right.

Seibel: You must have observed many shifts in attitudes along those lines.

Allen: Well, today they wouldn’t say great programmers, but they’re great on teams because they like to collaborate. It shifted to women collaborate and they work together well. So that’s today’s analog of that earlier assumption that women were quite detail-oriented.

Seibel: Despite the number of women in that Stretch compiler group, you must have also have had times in your career when you were working almost entirely with men. Was it a different kind of experience working in a group with lots of women?

Allen: Yes. I think it was, but it was not only lots of women—a lot of my peers were truly peers in the sense that they were mostly all the same age because of this big hiring that was going on at the point I was hired. We were pretty much all the same age and pretty much of the same background. So it was a very collegial group. And also, the whole area was so new—so much was unknown. We didn’t know what we didn’t know, but it wasn’t as if there were a lot of people around us that had years of experience or knew a whole lot more.

Seibel: So what happened? The field is not full of women anymore; when did that change?

Allen: It took me quite a few years to identify the cause. It happened in the late ’60s, at least in the environments that I was in. I had left Research to be involved with the ACS project and went to California. Then I came back to the Research division and found it a very, very different environment than the one I had left essentially eight years earlier.

There was a significant glass ceiling. There were processes in place, lines of management. And the management structures had changed and decisionmaking had become much more formal, particularly about what projects to do and how to do them. And the number of women had changed and the position of women in the organization had significantly changed, and not for the good. And I was not happy about it, obviously.

In 1970, ’71, ’72, I was 19 years or 18 years into a career that was just full of fun and opportunity. I never saw myself as advancing, but I felt I had the freedom to do what I felt was right and to work on interesting things in roles that I would enjoy. And I came back and found out that wasn’t the case.

Seibel: Do you think that glass ceiling had, in fact, been there before and you hadn’t bumped up against it yet? Or had something changed?

Allen: It really hadn’t been there previously. Recently I realized what was probably the root cause of this: computer science had emerged between 1960 and 1970. And it mostly came out of the engineering schools; some of it came from mathematics.

And the engineering schools were mostly all men in that period. And the people IBM was hiring had to meet certain requirements: have certain degrees and have taken certain courses in computer science. And so they were almost all men because they were the ones that satisfied the requirements—because it was a discipline now. The other thing that seemed to have happened is that it was a profession—there were a lot of processes in place and chains of management that implemented the processes and kept everything running smoothly. So it was a very different place.

Seibel: I’m pretty sure sexism in society at large was pretty rampant in the ’50s and ’60s. Yet in that period you were working in groups that had lots of women in them. Why was it so open to women then?

Allen: Software was the newest-of-the-new stuff that was going on. And it’s also probably still to this day considered a soft part of the science. And that’s where women gravitated. Early on they were programmers on ENIAC and at Bletchley Park. Women were the computers—that was their name. But in engineering and physics and the harder, older sciences there weren’t as many women. It was just divided that way, early on.

Then women started to come out of the engineering schools. Now the undergraduate percentage of women in engineering is somewhere around 20 percent. Carnegie Mellon would be much higher than that—they have made a special effort. But in computer science, it’s essentially 8 percent. There’s no domain that is as bad as computer science for women right now in terms of numbers. “Bad” is the wrong word—it’s low.

Seibel: To play devil’s advocate, why does it matter whether we achieve, say, Anita Borg’s goal of “50/50 by 2020,” meaning 50 percent women in computer science by the year 2020? Why does it matter whether this one particular field be representative of the population at large?

Allen: It’s such a transformative field for society as a whole. And without the involvement of a diverse group of people, the results of what we do are not going to be appealing or useful to all aspects of our society. A piece of our challenge is to make computing, and all that it enables, accessible to everyone. That’s an ideal. But it’s really where it’s going—the work at MIT on the $100 computer and the way we’re trying to enable commerce at a very low level through computing in the remote areas of underdeveloped countries.

Seibel: So clearly the closer you get to the end user, the easier it is to imagine that people with diverse experiences are going to bring different ideas about how those users might like to interact with a computer. Again playing devil’s advocate, what do you say to someone who says, “That’s all well and good when we’re talking about designing applications, but when you’re designing compiler optimizations, who cares about a diversity of point of view?” Is it still valuable to have a diverse staff even when you’re working on extremely technical aspects of software, like optimizing compilers?

Allen: Yes. In fact, that was one of the keys to the PTRAN group. A lot of women were attracted to the group, partly because there were other women there already. But it also made the group a very congenial group. And it was because of the mix—it wasn’t because there were women there, but because of the mix. These people came from other organizations here, but also other educational backgrounds.

I had people that came in from NYU—the Courant Institute—who had their own way of thinking about doing things because they’d come through the same graduate school. And then I had a couple people from MIT. One in particular—a woman—was on the very theoretical side and a very wonderful thinker in a different way. The Illinois people had some different characteristics. So even taking out the gender differences or other cultural differences, the fact that they came from these different places provided, in and of itself, a much stronger group.

Seibel: I suppose if we get to the point where undergraduate computer science is split 50/50 by gender we could actually lose some of that experiential diversity, if everyone is going through the same sort of CS degree.

Allen: What makes some of the new graduates very appealing to, say, IBM, is that they’re not staying in one discipline. They move from one discipline to another. And they can be deeply technical but very diverse disciplines. Often it’s done purposefully—a person decides that they want to connect some big fields. I’ve talked to some people like that—they see a connection between working in linguistics and working in computing. They’re very appealing as an employee.

Seibel: So how are you feeling about the “50/50 by 2020” project?

Allen: Pretty discouraged about it.

Seibel: What are the steps that should be taken to get to that goal? Do you need to change math education in junior high school? As I understand it, that’s where a lot of girls drop out of math and science—before that girls still love math.

Allen: That’s been a popular belief, but I don’t believe it. Look at the Westinghouse competitions. Women are winning those. And there are a lot of women in engineering—taking all the tough sciences and mathematics in high schools. At my little high school in Croton, New York, we had a Westinghouse person nationally come in fifth. And they have a nice science program. Six of the seven people in it this year at the senior level are women doing amazing pieces of individual science.

What’s happening with those women is that they’re going into socially relevant fields. Computer science could be extremely socially relevant, but they’re going into earth sciences, biological sciences, medicine. Medicine is going to be 50/50 very soon. A lot of fields have belied that theory, but we haven’t.

Seibel: What is it, then, about computer science that is so unappealing?

Allen: A lot of people think it’s the games and the nerdiness of sitting in front of a computer all day. It’s going to be interesting how these new social networks online will have an effect. I don’t know. But I feel it’s our problem to solve. It’s not telling the educators to change their training; we in the field have to make it more appealing.

We have to give the field an identity that expands it further than the identity it seems to have now—a much more human identity. We haven’t articulated why we like this field and what’s exciting about it and what’s exciting about the future and why it’s a great field to be in.

Seibel: So why do you like it?

Allen: Part of it is that there’s the potential for new ideas every day. One sees something, and says, “Oh, that’s new.” The whole field gets refreshed very frequently. It’s very exciting to think about what the potential for all of this is and the impacts it can have.

Isaac Asimov made a statement about the future of computers—I don’t know whether it’s right or not—that what they’ll do is make every one of us much more creative. Computing would launch the age of creativity. One sees some of that happening—particularly in media. Kids are doing things they weren’t able to do before—make movies, create pictures. We tend to think of creativity as a special gift that a person has, just as being able to read and write were special gifts in the Dark Ages—things only a few people were able to do. I found the idea that computers are the enablers of creativity very inspiring.

Seibel: You have been the first woman in many categories—first Turing Award winner, first IBM Fellow. Do you feel like there were women before you who were overlooked?

Allen: Oh, yes, absolutely.

Seibel: So when you won the Turing, did you think to yourself, “Gee, there’s another woman who should have won this a long time ago?”

Allen: Well, the very first thing I thought about was how wonderful it was. And then I started to think about all the many other women who were never recognized at all for their work. In many cases, their work was stolen. I thought about the women who had done some very amazing things that have not been recognized, even by their peers. When I approach them and say, “You need to join some professional organizations—I’ll write some recommendations for you,” they kind of shy away from that.

Seibel: So you think that part of the problem is they don’t get recognized because they’re not putting themselves in a place to be recognized as easily.

Allen: Right.

Seibel: Are there any particular folks that you would like to name—to give a little recognition now?

Allen: Well, there’s Edith Schonberg, who is a great computer scientist. In terms of technical work, it’s just one first after another on some of her papers. She’s had work stolen—absolutely brutally stolen. She wrote a paper on debugging of parallel code, which is a very hard problem. It was not accepted at a conference and somebody who had been on the program committee made three papers out of it. That kind of thing. It happens in our field and we don’t have good ways of dealing with it.

Seibel: And it happens more to women?

Allen: Yes, I think it does. They were often viewed as not going to put up a fight—that they were more isolated and don’t have the advocates who will deal with a famous thief. He was a famous thief, known but nobody dared touch it. And there are plenty of others way back from the Stretch days. There was a woman who essentially was the inventor of multiprogramming and credit was taken by somebody who eventually became a Turing Award winner.

Seibel: Would you have rather won the Turing Award, but not had to have been the first woman? There were a lot of newspaper stories: “Woman Wins the Turing Award,” which I imagine might be a little annoying. If another woman had won it ten years ago, and been the first, and you could have just won it when you did, do you think you would’ve preferred that?

Allen: Well, I can’t say preferred or not preferred. I feel I won it for a very good set of reasons. And it took a long time because it was not always clear what I was doing in some sense. I always worked with a group. Worked with some great, famous people often. And the work could easily be attributed to somebody else—to John Cocke, who distributed ideas everywhere. Lots of people have received accolades and awards because they picked up on something from him, as we all did.

But I was very glad to get it and partly because it was late for a woman to get it. I felt it was an embarrassment for the community that there were 50 men in 40 years, or whatever it was. So I felt it was certainly overdue for some woman to achieve it, and I was perfectly happy to be the first. But I steered a little bit clear of making a big deal out of that aspect of it. I tried to focus a lot more on the length of my career and the whole history of it.

Seibel: How does it feel to have spent your whole career at IBM?

Allen: Working for IBM Research was one of the most fortunate things that ever happened to me because IBM Research sits between industry and academia. I have a picture of a stone wall that I’m standing on and can look either way and find interesting problems and opportunities in both ways.

Seibel: From your vantage point on this stone wall, do you feel there is enough going back and forth between the academy and industry?

Allen: Well, NSF published a wonderful report with a one-page graph a few years ago which showed where several billion-dollar industries come from, like graphics, the Internet, high-performance computing, transistors. These billion-dollar industries were down the y-axis and on the x-axis was a timeline showing when it started, what was the role of industry, by lab, and what was the role of academia.

Some started in industry; some started in academia. Together, these two entities had contributed pretty much equally into building these multiple billion-dollar industries. I think the real important thing is to protect the interplay so that there’s a lot of cross-channeling of ideas, and of technologies, and methods, and investments to see it continuing.

Right now, with the focus that the U.S. has on maintaining innovation, and the importance of it, I think we’re doing pretty well in terms of interaction, working together, and solving problems together. And solving the problems that keep us from solving problems—intellectual property being one of them.

Seibel: IBM is not exactly blameless there.

Allen: Not at all.

Seibel: You must have your name on patents.

Allen: No, none. Part of it is that software wasn’t patentable. The other thing was that I was often working at the leading edge of things and the best way to get it into IBM was to publish it and some other company would pick it up. I was much more interested in getting it into products than to getting a patent on things.

Seibel: So that was easier than convincing someone within IBM to build a product based on your research?

Allen: We have a much better way of doing things now. But there was a long way, sometimes, between a good idea in research and a product.

Seibel: Since receiving the Turing Award has caused you to reflect a bit on your whole career, is there anything that you’ve realized ties it all together?

Allen: I think my career and the way I do things—the one word that kind of sums it up is “exploring.” I love exploring the edges—of ideas, of projects, and the physical earth, whatever it is—people too—and that I find very exciting.

But there’s a flip side in that I’m a starter, not a finisher. I get attracted to new things. The field of compilers was just a marvelous field because the computers continued to present challenges. And the problems being solved continued to be increasingly challenging.

Оглавление книги