Summary of Weinberger interview

Peter Weinberger joined AT&T in 1976 after teaching mathematics at the University of Michigan. An analytic and algebraic number theory mathematician, he was one of the three writers of AWK, with Aho and Kernighan. Being heavily involved with theory, he sees a large difference between a computer program and a theorem. Says Weinberger, “When you prove a theorem you now sort of know something you didn’t know before. But when you write a program, the universe has changed.” As a theorist, he appreciates the difficulty is takes to get a program right, but after that, he says, the thinking is done. The calculations are then faster and more accurate, and since he sees computation as one of his weaknesses, computers work nicely for him.

This leads into a discussion of the teaching of computer science, and Weinberger certainly has opinions on how it should and should not be taught. His main problem with computer science is that graduate students are “on average lazy.” This is mainly due to the fact that there is no sense of discipline in the subject. The field of computing has been moving very rapidly since the 1960’s without any sort of real direction, and this results in an unstructured approach to teaching computer science. This lack of structure is due to many things, but one of the main reasons that Weinberger sees is that the nature of programming itself is unstructured. One can either write code from scratch or use bits of existing code and fill in what is needed. Obviously, the second method is much more common. This creates problems, though. Weinberger says that it all begins when products are rushed, which happens frequently in software development and happened with many operating systems. This results in software that works for the most part but has certain bugs or bad features. The difficulty arises when the users get used to the bug, and then, Weinberger says, “You can never get rid of the loathsome thing.” This has happened to UNIX, as features from other operating systems, such as MS-DOS, show up in the newer versions. But his self-sufficiency shows through because he says, “I’d rather complain about what they’ve done with our work than have to put up with somebody else’s work.”

AWK is (from the WWW AWK FAQ) “a ‘pattern scanning and processing language'… a complete programming language, with a syntax resembling that of C.” In Weinberger’s words, what they wanted to develop was “Some tool that would let you get stuff out of ordinary UNIX files in a way that was…more general, more useful, more database-like, more report generally like. AWK is like graphics, except it understands numbers and it understands that things could be divided into fields.” Weinberger says that there was not really any way to assign specific responsibilities to any of the three of them, since they all spent a lot of time discussing various ideas.

This meant that AWK was not developed in the structured way that other projects of its day were. Weinberger brings up Poplar, a similar project as Xerox Park which was meant to “…take these files consisting of a lot of characters and you break them apart in various ways and you process them using some language and you pass them on.” Poplar, he says, “…was a real research project as opposed to AWK, which had it’s research aspects but, you know…I wouldn’t call it a hack but what we had in mind was producing this program to use, right…a useful tool.”

As for programming in AWK, Weinberger says, “Although AWK’s language is both C-like and not real elegant, a lot of AWK programming isn’t done by getting the reference manual and writing code. What is done is by finding some AWK program that’s very similar to what you want to do and changing it.” In this sense, it’s very similar to a lot of the work that was (and is) done in UNIX, and again brings up the problem of lingering unwanted features. UNIX is full of these little things, he says. “UNIX is famous for this theory that it’s best to do 80% because the last 20% is way too hard.” In order to combat this type of problem, UNIX, AWK, and many other projects at Bell Labs were approached in a way that was neither purely theoretical or based purely on previous code. “There’s an advantage, which is you can explain what the theory gives you. And there’s a disadvantage, which is you have to put up with the weaknesses of what the theory gives you. And for many specific problems there’s an ad-hoc way that covers much better and we’ve been on, I think, both sides of that.” Weinberger is not afraid to admit that theoretical approaches are not always the best.

Another project that Weinberger worked on, after AWK, was developing the FORTRAN 77 I/O library. He says, “There’s essentially two things that are real aggravation in FORTRAN. One is the lexical analysis…and the other is the wretched FORTRAN I/O library dominated by the god awful format statements. I thought about for a while and said I know how to deal with format status.” Things did not work out quite as planned, however. Being the first UNIX FORTRAN compiler, the library was around for quite a while. Then, in about 1986, one of the employees at Bell Labs complained about strange FORTRAN errors, and when Weinberger looked into it, he found his buggy I/O library. “That’s,” he says, “a story in favor of portability in writing in C, which is, by now, fairly well understood.”

Weinberger is still at Bell Labs.