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.