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

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

Allen: That aspect of mentoring, I don’t get very close to these days. WhatI do do, though, is encourage a young person starting out to not jump intobecoming a manager, which is very tempting for people who have a talent inthat direction. Get a reputation for technical work. Whether it’s a nicepiece of science, an algorithm, or writing great code—whatever it is,establish a strong reputation there first. That’ll serve you well if you dowant to go to managing projects and so forth, to have learned the disciplineof 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 verytechnically 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 isable to distinguish between who is and who isn’t in the people that work forhim.

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

Allen: Well, I always like to find the people who can turn a light bulb onover my head. That’s really important for me because I spend a lot of timethinking about systems, so I like to have people that will be able, at least inResearch, to show me something new and interesting or a new way oflooking 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 areal learning experience when I find myself thinking more highly ofsomebody than the group does. If you have a good group, it’s a very goodway 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 onoptimizations and transformations. We were getting rid of just one niceproblem after another. When C came out, at one of the SIGPLAN compilerconferences, there was a debate between Steve Johnson from Bell Labs,who was supporting C, and one of our people, Bill Harrison, who wasworking on a project that I had at that time supporting automaticoptimization.

The nubbin of the debate was Steve’s defense of not having to buildoptimizers anymore because the programmer would take care of it. That itwas really a programmer’s issue. The motivation for the design of C wasthree problems they couldn’t solve in the high-level languages: One of themwas interrupt handling. Another was scheduling resources, taking over themachine and scheduling a process that was in the queue. And a third onewas 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 itsuse to operating-system kernels?

Allen: Oh, yeah. That would have been fine. And, in fact, you need to havesomething like that, something where experts can really fine-tune withoutbig 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 seriouslyregressed, since C developed. C has destroyed our ability to advance thestate of the art in automatic optimization, automatic parallelization,automatic mapping of a high-level language to the machine. This is one ofthe reasons compilers are… basically not taught much anymore in thecolleges 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 goingon, and people doing good algorithms, good work, but the payoff for that is,in my opinion, quite minimal. Because languages like C totally overspecifythe solution of problems. Those kinds of languages are what is destroyingcomputer 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 locationof data. If you look at these other languages, they stayed away fromspecifying the location of data and how to move it, where to put it in themachine. It was ultimately about its value at any point.

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

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

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

Seibel: Your career has been largely in high-performance computing. Yetby 2019, or whatever, we’re supposed to have 1,000 cores in a notebookcomputer. Does that mean high-performance computing and everydaycomputing will merge? Or will high-performance computing always be outthere doing things in a sufficiently different way?

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

And there’s a competitive element that’s just going to drive it. Butharnessing those multicores pushes the problem out of the hardware spaceinto the software space. And that is where we’re not prepared to make anyprogress as far as I can see. To harness these multicores—I think that’swhere the new language levels are going to have to break in. We should doan 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’vebuilt up not only a wonderful, amazing legacy—just astounding—but alsosome artifacts that we need to get rid of. It’ll take a very long time toreplace these and I think it’s a little hard to predict how that will evolve. Butit’ll evolve very fast if we can get some new thinking going in the rightplaces. We know how to do computations on a lot of stuff. We don’t knowhow to deliver the data to the computation elements in the machine.

Seibel: Can you give a simple example of what you mean by bringing thedata 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 theunderlying operating systems and support systems. And often the referencesare at an element level.