Peter Seibel - Coders at Work - Reflections on the craft of programming

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.