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.