An Oral History of Unix

Michael S. Mahoney

DRAFT
2016-01-01T16:02:56Z

01-preface.html aho.html cherry.html condon.html feldman.html fraser.html kernighan.html mcilroy.html morgan.html morris.html ritchie.html tague.html thompson.html weinberger.html

Preface

This is a compilation of interviews conducted by Michael S. Mahoney, Professor of the History of Science at Princeton University. The interviews were recorded on tape during the summer-fall of 1989 & transcribed later by various people.

The original files from which this ebook was constructed were taken from Professor's website at http://www.princeton.edu/~hos/Mahoney/unixhistory .

Al Aho

The interview date is unknown

Aho: I have a question that I have - maybe you've already uncovered the answer to this - and that is... How did it get started? Do you have, at this point, a feeling of, "What was it that sparked the idea, in Ken's mind?"

MSM: I have a general idea what sparked Ken's mind. I want to know more about it. In order to know more about it, I have to know more about the circumstances surrounding Multics. My sense of it is that Ken liked working on CTSS, liked working on Multics. He liked the machine on which he could continue to do that. And the question was how does one go about getting hold of that machine and developing that system.

Aho: I had joined the Labs in, I guess, early 1967, and Thompson and Richie had their office right across the hall from mine. Yeah, there was another graduate student I had met at Princeton in the registration line, a person by the name of Jeff Alman, and we got to know one another quite well at Princeton. And then, upon graduation, he came to Bell Labs; I came to Bell Labs. We were working on various aspects of formal language theory, the automata theory - theoretical computer science at that time. I used to go up into the attic, into the sixth floor, where there was this machine that Thompson, and then shortly a few others, were working on, and I was interested in writing papers. So, very quickly I discovered that this was a much nicer way to write papers than the old traditional way that we used to have of giving handwritten notes to the secretary.

MSM: Let me back you up a bit. You got your Ph.D., you finished your dissertation in '67?

Aho: Yup.

MSM: On indexed grammars?

Aho: Yup.

MSM: And who's your dissertation advisor at Princeton?

Aho: That was interesting; I was an undergraduate at the University of Toronto and I had done my senior thesis in the area of minimization of Boolean functions. And I did a lot of reading of research papers, and I noticed there was a person by the name of McClusky, whose name was on a number of these papers. And then when it became time to think of what graduate school to go to... I didn't know where I really wanted to go, so I thought that MIT might be a safe place to apply. And then, I saw this person at Princeton. So I said, well, I might try applying to Princeton. No, I had sort of tentatively accepted MIT. Except McClusky kept sending me these very warm personal letters, saying, "Wouldn't you like to come to Princeton and work on a small campus. We can do great things together." And all I ever got from MIT were form letters. So after a while I said, "This is crazy! Why do I want to go to an impersonal school when I can get all this personal attention from this professor at Princeton?" Well, shortly after, I arrived at Princeton. Then McClusky said, "I am going off to Stanford." But it was a fair exchange - Stanford sent a young assistant professor, by the name of John Hopcroft, to Princeton, and he inherited McClusky's students. And there were two students that McClusky had from the year I had come. And, fortunately, Hopcroft only had one Ph.D. research problem, so he gave it to this other student. That problem is still open; it hasn't been solved. And he left me to my own devices. So, I spent a lot of time groping around for what would be an interesting thing to write a thesis on; but, actually, that groping around was, I think, a very valuable experience 'cause, once you learn how to find problems, it's a very valuable skill for later in life. After you graduate, nobody gives you problems.

MSM: Now when you went to Princeton's electrical engineering...computer science...was it called it then or was it still...

Aho: It was just called electrical engineering. But there was...there were several options that you had in the department - one of them was the computer science option. You could also...there was a solid-state electronics option, a communications theory option...that...those were the three main things that students took. You had to specialize in one of these areas. And then, at that time, I guess in the - I don't know if they still do it in the department - for the general examinations, you had to take one major area and two minor areas. An option for one of the minor areas was mathematics. So, a lot of students took computer science as a major, and communications theory and mathematics as a minor.

MSM: Is that what you did?

Aho: Yes.

MSM: What did you go to get from the mathematicians?

Aho: My graduate education at Princeton consisted of a great number of forces from the math department. The electrical engineering department didn't have very many computer courses at that time. So...

MSM: I was going to say, "How did you know what computer science was? How was computer science then?"

Aho: There was hardly any. Probably the most influential thing that took place was, one summer Jeff Alman went and worked for Seymour Ginsberg out in California, and Ginsberg was very active in formal language theory at the time. So when Alman came back, he essentially taught Hopcroft, and me, formal language theory. And that's how I slowly started getting interested in this area of language theory. And at that time, the Chomsky hierarchy of grammars was very popular. People had the type zero to type three grammars. And, I had some interest in the compilers at that time, and I noticed that with the context-free grammars, the type two grammars, the Chomsky hierarchy, you couldn't express certain constructs of programming languages. So I said: What you really need to add to a grammar to get constructs like, "You have a string, and then you would have a repetition of that string, so you can, say, declare integer string, and then you can use string as an integer variable in some expression." That repetition construct is sort of one of the classical constructs that people used to say that languages of that form cannot be generated by a context-free grammar. So the idea of index grammars came out of, "What kind of mechanism would you like to have, or need, to be able to express constructs of this?" So, one way of viewing index grammars is that they are context- free grammars with certain symbol table information attached to the non-terminals of the grammar, and then it's very easy to generate constructs of the form "wnw" (?). What was kind of interesting was that, in this work, I discovered that...and I didn't discover it at the time I was working on my thesis but shortly thereafter...that indexed languages - those languages generated by index grammars - were the first in an infinite hierarchy of languages that exist between the context-free and the context-sensitive. You start off with the regular sets, you have the context-free languages, you have the index languages, and then, the other languages in this hierarchy are obtained by essentially putting a "duplicate" operator on memory that one can view, just as with context-free languages. There's an equivalent way of defining the same class of languages with push-down automata, so that any language that's recognizable by a push-down automaton can be described by a context-free grammar, and vice versa. There is this duality, likewise with index grammars, that any language that is generated by an index grammar, you can define an automaton, called a nested stack automaton, which is capable of recognizing that language, and vice versa. This is sort of one of the key results of the thesis. One way of viewing a nested stack automaton is that it is a push-down automaton with a duplicate operator that you can duplicate the stack, and then start working on the duplicated stack, and then you can duplicate the duplicated stack, and so on.

MSM: In the beginning it is almost a power set of push-down automata.

Aho: Well, you can get a stack of stacks, basically. And the nested stack automaton has sort of an efficient way of implementing the stack of stacks, and you can think of it as sort of almost like a cactus. That's why some people are calling it cactus automata, at the time. But then, going up to the next level of generalization had these nested stack languages. You can then duplicate a stack of stacks in one operation, so you can have stacks of stacks, and now you can see what the generalization is going up in this hierarchy. And the interesting part of it was that these...all the languages generated by these mechanisms had the same kind of decidability and closure properties. And, a little later, the Europeans... The work in Europe in particular, in language theory, went to biologically motivated examples of languages people were looking up - what phenomena could account for the striations on snail shells. And, they looked at grammatical mechanisms for being able to generate patterns of this form. These grammatical mechanisms were called Lindenmayers systems, and it turned out that there was a close relationship between certain kinds of Lindenmayers systems and indexed grammars. So, for a while, this was very popular as a certain sub-field of language theory. So, it was...very interesting...part of my life, a very interesting experience. And in fact there are still people who write papers once in a while on various aspects of index grammars and languages. And, this family of languages was shown to be an example of what was called the "Super Apple" (?). Some work that Ginsberg and Greibach had done, subsequently looking at automata theory for various classes of automata in a very general setting, a very algebraic setting. It's a very elegant, beautiful theory, and it was a nice way to get started on scientific career.

MSM: Okay! Well that leads...obviously to the next question - which is what was the appeal of Bell Labs to someone who was...a work of such a decidedly theoretical...

Aho: Well, I mean Bell Labs had a great reputation. And, also, McClusky had consulted for Bell Laboratories, and he had brought some of his graduate students on tour to Bell Labs. So we saw some of the work that was going on. Even when I was at Toronto, I took engineering physics as an undergraduate, and in our senior year we had a field trip, that we would go and visit various American research institutions. So, I went on this - in fact I organized - this American research visit in my senior year. We visited, amongst other places, Bell Laboratories. We also went to Brookhaven and GE, just to see what an industrial research lab was like. And, certainly, if one looked at the scientific literature, there were a number of papers--key papers--that had been co-authored by Bell Labs scientists. So it had a good reputation as a place to go and do research. The other attractive part of it was that Jeff Alman had just joined Bell Labs, too, and John Hopcroft had a close connection. He was working here for the summer, at that time, so that wasn't that much different from going from Princeton to Bell Labs in terms of the people that I knew. I had also...when I came interviewing...I was very impressed with Doug McIlroy, who was my boss for many years. And he was just a peach of a person to work for. He understood everything that I was working on, with just the most fragmentary descriptions. And...he had...he essentially taught me to write too, I think he's one of the finest technical writers that I know of. He has a flair for language, and a flair for economy of expression that is remarkable.

MSM: So you came in '67... At that time, if I understand correctly, Doug and Ken and Dennis and Joe Osanna were working on the Multics project.

Aho: Yup.

MSM: And what was...what you people you...if I understand the way things work here, you were told to look around and find something to work on...

Aho: Well...

MSM: How'd you go about that process?

Aho: What Doug McIlroy did in terms of introducing me to the people in this department...he just said, "Oh, here is Jeff Alman sitting across the hall from you." And, Jeff and I worked very closely together for the first few years that I was at Bell Laboratories. We were writing four or five papers a year on various aspects of language theory and automata theory.

MSM: So essentially laying down the content of the books...

Aho: What we were doing was trying to develop a theory that would account for certain kinds of computational behavior. We were exploring what kind of power various kinds of automata-representative devices had. We were also very interested in algorithms, and studying algorithms from the point of view of, "How fast can you make them. What are upper and lower bounds on the speed with which certain problems could be solved using various models of computation." And, more interestingly, we were also trying to see if there were some general classes of techniques that could be used to solve problems. And, there were sort of two prongs to the work initially - there was the work in formal language theory - and we had a certain view that a number of these techniques could be applied to compiler design. So, in the early '70s, we wrote this two-volume sequence, Theory of Parsing, Translation and Compiling, that attempted to distill the essence of automaton language theory with applications to the process of compilation. And, I think this was one of the interesting demonstrations of putting a theoretical foundation onto an important practical area of computer science, that people in programming languages and compilers are, I think, an indigenous part of computer science. What language and automata theory did was they provided a theoretical foundation that could be used to design algorithms for the translation process. And, more importantly, people could then construct tools to help build components of compilers. A few years later, in the early '70s, I had a very interesting experience with another colleague, who was in the computing science research center at that time. This person had gotten his Ph.D. from Columbia under Eilenberg; he was a category theorist. His name was Steve Johnson. But then he had come to Bell Laboratories to work; he had developed a fascination with computers and computing. One time I remember he came into my office waving a book written by Elgot and Eilenberg, entitled Recursiveness, and what he said to me was, "I understand you know what the theorems in this book mean, but you don't understand the notation." He says, "I understand the notation but I don't know what the theorems mean - why don't we read this book together?" So we very quickly read the book, and discovered that it said well-known things in a well-known notation, namely, theorems of recursive function theory, couched in category theory. But, a more interesting part of that interaction was Steve asked me, "Well, what are you working on?" And I was saying, "Well, there are these things called grammars, and there are these things called automata, parsing methods for various classes of languages." And, he was interested in writing a C compiler at that time. And, he said, "Well, could you make a parser for C for me?" And I said..."using these techniques"...and I said, "Why sure!" And, I foolishly decided to construct the parser by hand, implementing one of these LR parser construction techniques. And I had a huge sheet of paper - big piece of cardboard - on which I carried out the sets of items construction - usually while I was watching television, 'cause it is such a trivial and mind-numbing task. And of course I didn't get it right. And I gave this piece of cardboard to Steve, and Steve would then encode it into his computer program. After a while he become so frustrated with me, that I couldn't get it a hundred percent right, he wrote a program that automated this parser construction technique. And that how the tool yacc was born. And yacc had an interesting experience in those early days that there were the people who understood how to write compilers - people like Dennis and Ken. And, I guess back in the '50s there was a feeling that the real programmer knows where every bit is, and there was some mis-chewing of higher level languages, because we couldn't get the same kind of efficiency. On the other hand, people who were newer to the game, and also people who weren't so concerned with extracting every iota of efficiency out of the machine, gravitated to higher level languages - FORTRAN, in particular. In the late '50s and early '60s, the same kind of experience took place with yacc that people quickly discovered that you could very easily construct a parser for a language by writing down the grammar, and then yacc would translate the grammar into a parser. A few years ago, writing a parser for a language was considered worthy of a Ph.D. thesis. So here came along this device that sort of automatically did what you used to be able to get a Ph.D. thesis for. And there were some people who recognized the potential of constructing special purpose languages for various application areas. And, one of them in particular was Brian Kurnighan. Brian's office was right next to mine. And, he had been interested in computer typesetting. This is a field that Joe Osanna had pioneered. And Joe had written this text formatter which got to be known as troff. There was an ASCII version of it in roff, prior to that. Brian wanted to extend the capabilities of troff to handle other specialized constructs - equations - and, later, various kinds of graphical constructs. But, I kept saying to him, "Well, it is very easy to write a grammar that describes the structure, the syntactic structure of mathematics that appears in documents. So, why not write a yacc generated parser for this?" So then he and Lorinda Cherry developed this troff preprocessor that got to be known as eqn. And this became again one of the standard tools in our typesetting arsenal, when a lot of people are writing mathematical oriented papers around here. And eqn made the typesetting of mathematics, or the printing of mathematics, just as easy as speaking mathematics. Kernighan had this philosophy that language should be like what a professional uses to communicate, the description of those objects over a telephone. So you could write "'a' sub 'i'" - that's a way of describing the mathematical expression "a" with the subscript "i." And also, looking at some of these application areas... In mathematics if you write "'a' sub 'i' squared" or "'a' sub 'i' suit 2," this can be written in three different forms: You could have "a" with the subscript "i" squared. You could have "a" sub "i" raised to the power of "2." And many people who do professional typesetting often like to put the superscript "2" above the subscript "i." And...it was...at that time...Johnson, Alman, and I were looking at techniques for being able to parse ambiguous grammars. And, it turned out that having the ability to use ambiguous grammars allowed one to put in syntactic constructs for special cases. These syntactic constructs for these special cases would make the grammar ambiguous, 'cause there was a general mechanism in the grammar for already specifying it, so you added another production which specified the special case construct. And then we added a parsing action conflict rule to yacc saying that, if you could take the choice of reducing by several productions, then choose the one that you have designated as the special case construct. So you could automatically optimize certain kinds of language processing by first very quickly writing a grammar for the general case, and then as you saw the special cases that needed to be done, you could insert productions into the specification. The semantic rules for processing, and then as a consequence, the human interface improved to a number of the special purpose languages, because there were constructs for dealing with some of these special cases. And you got the kind of output that you wanted. And this was a development that took place in the early '70s. So many people became quite devoted to the various compiler construction tools. There is another colleague of mine, at that time, by the name of Mike Lesk, who had a great deal of interest in special purpose languages, as well as various kinds of information processing and information retrieval mechanisms. In a compiler, one of the first things - tasks that you perform - is you take the sequence of input characters, and you chop them up into words, the lexical units that make sense. So if you write an identifier like "floors," those letters are to be grouped together and treated as a lexical unit. The task, or the part of the compiler that combines sequences of characters into lexical units, is often called a lexical analyzer or scanner. And, since we had developed a parser generator, I had been interested in pattern matching techniques of various kinds, and Mike had come over to me and asked, "Could I use one of your finite state machine approaches to doing lexical analysis?" And I was amazed at how quickly Mike could program any application. So, within a period of a few weeks, he had created this first version of lex, which had taken one of these pattern matching algorithms that I had used in some other UNIX programs, namely egrep, and encapsulated them into a lex program which could be used in a very convenient way with yacc, so that the automation of the front end of the process, the front end of the compiler, the analysis part, was now virtually complete...that you could automatically...you could specify the lexical constructs of a language using the notation of regular expressions - another formalism from formal language theory. You could specify the syntactic structure using a context-free grammar. By the combination of these, then you could design a front end that would map a stream of symbols into the intermediate representation, from which then the code generation work could take place. The work on pattern matching...

MSM: Can I interrupt for a second?

Aho: Sure.

MSM: This all fits together so well, and I recognize what you're doing, 'cause I have used lex and yacc in code generation. I sat in on Ravi Sethi's compiler course, at Princeton, in '83, and have done that little PASCAL exercise at the end of the Dragon Book. So, it is interesting to hear you talking about these tools. And, it all fits together so nicely that it seems almost the obvious way to go. But it wasn't at the time, when you came. It wasn't the way people went about things. And what I hear as you describe it is...you said...you used a phrase earlier, "provide a theoretical foundation for compiler construction." And there are two ways in which one provides theoretical foundations for things. One is to come in and watch the way in which people are doing things, and then say, "Okay let's...let's formalize what you are doing." And another is to come in and watch the way people are doing things, and say, "No, there is another way to do this that will put you on firmer theoretical foundations, and in the end make your job easier." How clear was it that would make the job... There is an attitude of almost meta-programming that seems to lie...be part of UNIX. And, I am beginning to wonder whether that grew up here first or whether this is something that emerged here at Bell Labs, whether it is something that people brought with them and consciously tried to institute, or implement. Am I making...

Aho: Yup. All work occurs in a vacuum. And, as I had mentioned, when I first came, I was quite theoretically oriented, but the work was motivated by various kind of language processing. Chomsky, what he defined, is families of grammars. His initial motivation was to find some kind of syntactic representation for natural languages. Although there is some debate at this point of, "Did he really want to do that?" But...and when I was at Princeton, I had taken a course from the...I believe it was the physiology department...it is tough to know where some of these professors are actually housed...

MSM: And that's the nice thing about Princeton...

Aho: But, we talked about Chomsky's work - transformational grammars. The first two languages - programming languages that I learned - were Snowball 4 and IPL 5. And IPL 5 was taught by this person from...I believe it was the psychology department...

MSM: Who's in it?

Aho: I don't remember the name at the moment. It goes so far back. But, when I came to Bell Labs, the structure of languages became much clearer to me, and one of the things that I had worked on were various formalisms for translation - syntactic directed translation schemes of various kinds. And this was again work that I had done jointly with Jeff Alman. And, by studying some of these devices, you could see the power of certain formalisms for being able to specify a translation. Now if you look at a compiler, one way of abstracting it is that it's just an input-output device - you put in a source program at one end, and what comes out at the other end is a target language program. Even if you open the lid of a compiler and look in at, you see that the compiler consists of a composition of phases. And each phase in itself is a translation of a certain kind. There is a translation that takes place in the lexical analyzer going from the stream of tokens, as they are inputted - as a sequence of characters into a stream of tokens - then the parser takes that stream of tokens, and checks to see that it has a certain syntactic structure, and then produces some kind of intermediate representation as output. And then the subsequent phases take that intermediate representation and map it into object code. So, one of the things that we noticed was that a translation mechanism based on regular expressions or finite state machines could be used for the lexical analysis - modeling what a lexical analyzer did. What a context...what the syntax analyzer did could be modeled by a syntax- directed translation, where you write a grammar, and associate with each production a semantic rule. Well, that was a notion syntactic directed translations were known. But the key insights that we obtained were how to make this process go efficiently. In the mid '50s, Knuth had published a paper that essentially defined a large class of grammars called the LR(k) grammars. What people had done prior to that were defining various kinds of parsing strategies, and people had defined various precedents schemes - operator precedents, wheat precedents, mixed strategy precedents, and so on. And then there were certain kinds of bounded context - kinds of parsing strategies - but Knuth, I think, in a stroke of genius, said, "This is the natural class of grammars that you've all been groping for... And here is its definition. Not only that, but if you restrict yourself to this class of grammars, then here is the procedure for being able to construct a parser from that grammar." Now the problem with Knuth's paper was that the parsers that you got out of it were enormous. And then, work took place in the late '60s and early '70s of how to make that process more efficient. One of my colleagues at Princeton had done work on a certain restricted class of LR(k) grammars. In fact these were the simple LL grammars. This is work that he had done jointly with Hopcroft.

MSM: Who is this?

Aho: Al Kornjack.

MSM: Okay.

Aho: So, the talk of parsing methods and searching for a class of grammars that was big enough to describe the syntactic constructs that you were interested in, but yet restricted enough so that you could construct efficient parsers from it, was the name of the day. And, the methods that are used in yacc were a refinement of the methods that had come out from Knuth's paper on. There was a student at MIT, by the name of Drimmer, who defined the simple LR grammars. And one of the things that what we discovered when we wrote the theory of parsing book...what we discovered was that the literature - the scientific literature, if you could call it that - was very inaccurate. These objects were so new, and the techniques for dealing with them were so incomplete, that many of the claims that were made and published about various parsing methods were just wrong. The proofs did not hold. So one of the things that Jeff and I did was to attempt to understand what kind of techniques could be used to analyze these formalisms, and also to put a clear picture into the scientific literature - what was true and what wasn't. So that was a very interesting project, writing that book. And I discovered subsequently that that book came to be one of the hundred most referenced books in computer science and mathematics--although we certainly did not write it from that point of view, at that time. But it did give, at least me, a good foundation for talking about algorithms - reasonable algorithms that could be used in devices like lex and yacc. There was another event that took place in the early '70s... I had mentioned I was working on algorithms. Hopcroft and Alman and I had entered into a second...into a writing project. Hopcroft and Alman had written a language theory book, earlier. And I had written this book with Alman on the theory of parsing, so we decided that we'd enlarge the class of co-authors, and write a book on design and analysis of computer algorithms. I was very interested in algorithm design techniques at the moment, at that particular time. And, one time I happened to be giving a talk on techniques that could be used for constructing algorithms. Before, people tended to look at problems in isolation. But, the same technique could be used for many different problems. And, it became convenient to say, "Well, there's a general algorithmic design technique - divide and conquer. Take a big problem, break it up into chunks, try to find solutions for the chunks, and then combine these solutions into a solution to the problem as a whole." It's a technique that has been used since antiquity. But, just calling it "divide and conquer" is good enough because I can say to you, "Have you tried 'divide and conquer' on your problem?" It saved an enormous amount of conversation. Likewise, in pattern matching, algorithms in the area of looking for patterns in text, you could construct very efficient algorithms by using certain kinds of automata. When I had joined the Labs, I had mentioned that Doug McIlroy was my first boss. He had a passion for words, and we'd often talk about very unusual words, like, "What's the longest word in English...that has no repeated letter?" Or, "What's the longest word in which the letters goes up in alphabetically increasing order?" With certain formal methods, it was a bit trivial to specify these kinds of patterns. And, I guess I was also interested in crossword puzzles at that time, so I decided to implement one technique for constructing a regular expression pattern matcher that would very quickly look for regular expression patterns. The reason this is particularly effective for crossword puzzles is that, if you know that you have the third, the fifth, and the seventh letters of the word are such and so, then with regular expressions you could very quickly search the dictionary, and find all words that have that combinations of patterns. Regular expressions also allow you a much richer class of patterns than those. But that seemed to be one good motivation for it. And my idea was to use a certain technique for constructing deterministic finite automata from the regular expression, and then use that deterministic automaton to do the pattern matching. It was very similar in style to what yacc had done, that yacc takes a description, in this case a context-free grammar, and transforms its into an automaton that does the processing. So, this two-step style of pattern matching - you take the pattern, then you construct from the pattern, a recognizer, then use the recognizer to do the analysis - is a very potent one.

MSM: And this work was done after yacc?

Aho: It was contemporaneous because this is basically the idea in lex. And, I am very poor at remembering the exact dates at which things took place, and I really didn't keep a log in those days of when I did these things. So, I don't know exactly when these ideas occurred. But when I did the first version of this regular expression matching...pattern matching program...Doug McIlroy in the previous year had had a summer student who had taken a classical algorithm for constructing a deterministic automaton from a regular expression, and look for these patterns. And it was written in machine language. I was astonished to discover that the program that I had written ran several times faster that what this machine language program did. And, in fact, this sort of became an avocation of mine for a number of years subsequently, and the improvement in performance of that program has gone up by almost two orders of magnitude. Most recently what Andrew Hume had done...he put a technique called the Boyer-Moore Algorithm into the grep programs. And now we can search an 800-page book, looking for any key word or phrase, in a fraction of a second, with these fast patterns matching techniques. The early versions of these programs would have taken almost a hundred times faster to look for these patterns. And, also now that we have the new machines, the combination of better algorithms and faster machines has been just dramatic. But I was going to mention a story that... When I was working on the algorithms book, I was giving a talk on algorithm design techniques. There was a woman in the audience who worked for the technical information libraries, and she had written a bibliographic search program. They used to get a tape from the government that had various citations on it, and bibliographers could then specify some kind of search prescription consisting of Boolean functions of key words and phrases. And then the program would look for all citations that satisfied that search. Sort of the night before, some gun-ho bibliographer had a search prescription that had had over a hundred key words and phrases, and there was a six hundred dollar limit on the program of how much time it could consume. So, after using up that six hundred dollars, it had not yet finished printing out all the titles that satisfied the search. So she mentioned this story to me, and I said, "Oh, why don't you, with your set of key words, construct a pattern matching machine, and then the pattern matching machine will look for all of these key words in parallel. And by the way, here is an efficient technique for constructing this pattern matching machine." So, a month or two later, she came back to me and said, "Remember that program I had written? Now, it costs twenty-five dollars to do the search. In fact, every search costs twenty five dollars - that's the cost of reading the tape." So what had been a I/O bound...er, process bound problem, had become I/O bound, the way it should be. And also, at that time, I took that algorithm and implemented the UNIX program fgrep with it. And, there was a lot of interest in words. Lorinda Cherry was interested in writing, and I think this interest came from Doug McIlroy, who treasured good writing, good diction. So, she wrote a program called diction which would look for instances of questionable words and phrases in one's writing. If you used constructs like "irregardless" or "emotional feeling," it would flag every sentence that contained an instance of one of these questionable dictions. The fgrep algorithm was ideally suited to that kind of application, as well, where you could take a set of key words and look for instances of these key words. So, this kind of technology that was based on language and automata theory had a variety of applications. And, these applications are still unfolding--the most recent application of these string pattern matching ideas took place in a program that was written by a summer student who came here from Stanford. As I had mentioned, back in, I think it was '84, I had spent a sabbatical at Stanford, and had taught the course on advanced compilers, and there was this bright graduate student in the audience, by the name of Steve Chang, who subsequently came to Bell Labs for a summer. And, during the summer period, he developed a program called twig, which did for the back end of the compiler what lex and yacc did for the front end. That with twig one could take essentially a tree rewriting scheme...no, generalize the notion of the syntactic units to be trees, and one could view the process of code generation as taking an intermediate representation in the form of a tree, and then wallpapering it with little templates that correspond to machine instructions, or sequences of machine instructions. And...what twig did was...it would take a intermediate representation, and see if it could decompose this machine...this intermediate representation...to a collection of subtrees. And it used a dynamic programming code generation algorithm that Steve Johnson and I had developed in the mid-'70s. This is an algorithm that was the foundation of one of the PCC compilers. And, in fact, if I may take a digression on that... The portability of UNIX stems from several factors: one is that it was soon written in a high level language, C, which Dennis Richie had devised. I had mentioned Steve Johnson had this interest in C compilers, and then tools for automating construction of compilers. One of the things that Steve and I did, after we had done yacc, was to look at algorithms for code generation. And we had developed a dynamic programming technique which would allow one to take a tree representation and map it into an optimal sequence of output code for a machine. And we developed the theory of, under what conditions would the output code be optimal. And we tried to extend the class of machines for which this kind of code generation technique could be used. And it turned out that it fit a large class of machine architectures.

MSM: Is this the reason for Steve's interest in a C machine? Joe Condon had been telling me that Steve had been used to architectures for a machine optimized for C.

Aho: Well, it's again...what interesting technology...what you could do once you had these technological tools available. We had published this paper on code generation - optimal code generation - I guess at one of the theoretical conferences, and then it was published in the JACM. But most importantly, the PCC 2 compiler had used this, say, code generation mechanism, and it became possible to re-target this compiler to other machines fairly easily - all you had to do was specify new code generation tables that corresponded to the new architecture, and then you would have a compiler that would translate C into that new architecture. Since the UNIX operating system was written in C, it could then be moved very quickly to this. And both Dennis and Richie and Steve Johnson were very interested in portability, at that time. Well, now that we had this tool of being able to re-target a compiler to a new architecture, people in the mid '70s started looking at the question of, "Well, what would a good machine be for executing C programs?" I think this was a question that Sandy Fraser had also been interested in initially. Steve Johnson looked at it in depth. And, there was a young researcher here at the time, by the name of Dave Ditsel, who was consumed with this question of what would a good architecture for running C programs be like. So what people did was they would search a space of architectures for one that would be effective in running C programs. And they were able to do this in a much more scientific way by taking a C compiler, re- targeting it to this hypothetical architecture, and since we had a body of real C programs we could look at...these were the ones in usr bin. We could take those programs to see how well they would run in that new architecture. So they repeated this process of looking at an architecture, how good it was, then iterating. And the reduced instruction set computer that we called CRISP was born in this particular fashion. So the time CRISP came out in the early '80s, it was well-honed for running C programs. At least in the AT&T environment, we had an enormous investment in C programs, at that time. So, it was a particularly effective engine for running C machines. And, now, as you are well aware, the RISC machines have produced a dramatic increase in price-performance, in terms of what one can buy. And, this work arose out of compiler technology, to some...to a great degree. When I was at Stanford, there was a professor there, by the name of John Henessey, who was very interested in compilation techniques...to be able to take advantage of RISC architectures, and he had been involved with the MIPS company that makes one of the very efficient RISC chips at this time. So again, all of that work I view as stemming from the availability of a certain kind of technology. And this technology is in some sense rooted in a formalism that gives it a degree of efficiency that you might not have with more ad hoc methods. Well, with ad hoc methods you can do anything, but...at least my point of view is that, if you have a scientific base on which you can measure performance, and you can iterate and improve your algorithms with this scientific understanding, and then build an engineering design theory on that, you are going to be unassailable in the work and some of the compiler construction tools. Pattern matching algorithms seems to give some evidence to this. The other aspect of this is that it improves software quality in a significant way, and productivity in a significant way, 'cause you can write a compiler much more quickly using these tools, than if you had to do it from scratch: none of these stories that the first FORTRAN compiler took dozens of staff years to produce. Whereas now you could construct a compiler - a significant compiler - as part of a classroom project in an undergraduate computer science course.

MSM: Of course you are writing it on a machine that has, to all intents and purposes, unlimited memory. The first FORTRAN compiler had to go into a fairly small...

Aho: That's true, and it is still true that constructing compilers - good compilers - for languages like ADA are substantial efforts. But on the other hand, coming up with a preprocessor, or, a little language, is an activity that in many cases can be done over the course of a weekend.

MSM: 'Cause one of the things that struck me right from the beginning was when I first learned something about UNIX and its relationship to C as a function of...that you can stay out of assembler...as independent of the machine as you possibly can. Learning that UNIX was running on VAXes, or two-thirds of the VAXes out there were running UNIX. And then taking the VAX architecture handbook. Because even though we weren't supposed to write in assembler, it was a good idea to at least know what assembler was about. And see this instruction set on a VAX-11. It was an assembler's dream. Evaluate a polynomial: that's an assembly language instruction. And I thought, "Wait a minute... It doesn't fit! And then there's a discussion about the push toward, and the way in which RISC architectures had turned out to be the ones that work best with C. It seemed to make sense. Just let the compiler do the work."

Aho: Well, when I was doing this work with Steve Johnson, Johnson used to go around and saying he should get the language designer, compiler writer, and the machine designer into the room at the same time, because the system will be so much better. The tradition, up to that point, had always been: some engineer went off and designed the machine, and then some committee went off and designed a programming language, and then there was this poor compiler writer that had to spend an enormously frustrating experience of mapping that programming language onto that machine architecture. Certainly if one looks at the popularity, or lack thereof, of ADA, there are constructs of ADA which are very difficult to compile. If one had done a prototype implementation at the time the language was being defined, then it would perhaps have been a...different in certain aspects. FORTRAN...the lexical structure of FORTRAN is very difficult to analyze using lex, or any of these automated tools. The newer languages are much easier to lexically analyze and to syntactically analyze. So, from one point of view, the technology has shaped the structure of today's languages to some degree. PASCAL was defined so that it could be easily compiled. In fact, one of...I think one of the reasons for the enormous popularity of PASCAL was its availability. It was easy to construct compilers and to move compilers to a lot of machines. So the ubiquity of the language stems from the fact that you were able to obtain compilers for it.

MSM: So that language design ought indeed to keep implementation in line is what you want to say. 'Cause there was a school of thought in the '60s that, especially among European designers, that you design the language and not worry about the implementation.

Aho: That's very true. And some of that philosophy still persists in the specification of protocols these days. That protocols are being designed by committees without keeping an eye out for performance or implementation considerations. And, that may be too much of a purest attitude to get the kind of efficiency or perhaps interoperability that one would like to have. One of the great things about... Well, you talked about UNIX being a spirit. The one way that I view it is that there's a great deal of Darwinism in UNIX. If one looked at how certain commands and languages came into being, it was because someone had an idea. Say like Kernighan and Cherry for this language for typesetting equations. They got a rudimentary form of the language processor to be up and running, and then they let their friends use it. Then the language evolved on the basis of usage patterns. That, as users gained more experience with the language, they would be able to say, "I'd like to have these additional features." Or, "These are some awkwardnesses in the language." So there was a Darwinistic evolution of the language, and, in fact, of the UNIX system itself. That it is satisfied a certain user's needs, and there was enough time to refine the system so that it satisfied those needs - I thought, quite efficiently and quite elegantly. There is this "European approach," if you want to use that term, or this more dogmatic approach to language design, where you have some august committee that meets for a period of several years to come up with a language specification. They...write a document. Compiler writers work off that document for several years to produce a compiler, only to discover that there may be some infelicities in the language design. And, the process is much more cumbersome. Natural languages evolve, and I think, "Why shouldn't programming languages?"

MSM: But two things...there are two things that I want to pursue further. Back up a little bit, and then I want to get back to this business of languages... I want to confirm whether I heard correctly. Essentially, when you arrived during those early years starting in '67, and you established your presence here... And you and Jeff Alman established your presence. How long was Jeff here?

Aho: He was here for three years.

MSM: So you were both around when UNIX got started. At least for that first year you were both around. What I hear is that...you have people like Ken and Dennis who are interested in this new operating system. Dennis is interested in languages, interested in getting this into a high level language. You are a resource for a body of theory, of which people are becoming ever more awares. And, is that how the connection is made, that is...? Dennis and Ken haven't brought anything like this theoretical background to their work, out of there own background.

Aho: No...well, Dennis had worked with...his doctoral dissertation with Albert Meyer, who was a distinguished theorist at MIT. So he certainly had an appreciation for, and understood theory. My initial interactions with UNIX, and were those as of a user, and I really didn't interact with Ken and Dennis on a technical front. Except I would always be in the UNIX room using the system, and I would watch their process of development. There was a great spirit in that UNIX room, in the early days, of a lot of camaraderie and discussion. The real catalyst, I think, for getting, injecting these ideas in...these theoretical ideas into UNIX, I think came out of my interactions with Steve Johnson, and also the... I suspect the insights that I gained from Doug McIlroy, who used some of the early versions of the programs that I had...I was interested in experimenting with some of these pattern matching ideas. So, he had been very much of an early user of these programs as I was developing them. If I had appreciated the significance of what yacc would have done, I would have written the program back in the late '60s, rather than waiting for Steve to do it in the '70s. Because it made an enormous difference.

MSM: But you can...that was a difference after the fact.

Aho: Yes. And, I really didn't appreciate the significance of what you could do with it, at the time, in the '60s. And I don't think anyone did, because the...what made a lot of this philosophy...a lot of these tools go was the framework that UNIX provided. That you could have pipes on which you could take the output of one program, and transmit it as input to another program. So that the notion of filters was something that evolved during the '70s. And these...I said I was very interested in formalisms for translation. What you could then do was you could compose these translations along.

MSM: The pipes were really an implementation of that notion of translations...

Aho: Yes. Doug McIlroy, though, I think is probably the author of translation...of pipes. That he had written, I think, this unpublished paper when he at Oxford back in the '60s. I don't know whether you have seen it or not.

MSM: No I haven't. Because I have talked to him about pipes, but he didn't mention a paper. I'll have to get it from him.

Aho: You should read this paper because it's UNIX pipes. One of the interesting things about Doug is that he has had these great, seminal ideas which not everyone knows about. And whether his standards are so high that he doesn't publish them...or what? But it's remarkable, the...

MSM: He's emerging as the gray eminence.

Aho: Yup. No, I...UNIX would not be the way it is today without Doug. And, also, I don't think the work that I would have done would have had the encouragement, had it not been for someone like Doug. For example, this algorithm for bibliographic search... If I remember, on some Friday afternoon, I went into Doug's office, as I said, "Here's something that looks kind of cute." And I only had about two minutes in which to describe the essence of how you construct this pattern matching automaton from the sets of key words. There is a slight technical detail that you have to appreciate on this, the construction of this failure function - which has some, actually, deep mathematical implications on properties of patterns and strings. But, I just mentioned it in the most cursory fashion imaginable. I discovered a week or so later that Doug had given a talk on the basis of this two- minute discussion. And he had the most wonderful set of viewgraphs constructed for this talk - which I subsequently used. So, Doug's abilities to comprehend work on a broad front, and also to appreciate the economy of expression that theoretical models gave to the work, I think was very supportive.

MSM: I think that one of the continuing themes of this manifest...in the range of tools that are in UNIX (?)...the order in which the tools were developed. But it is also manifested in the way people think. Is this notion a language? Sure, when Brian was describing...talking about eqn, he said that mathematical typesetting had really been an exercise in finding the right language. And I had always thought of it as a problem with graphics on the page. And Lorinda said, "No, no. The graphics is easy. It was a just a question of language." You said, earlier on, I talked about Brian wanting to design it the way people talk. And, you talked about the continuing interest in the printed word, or, the lexical word - orthography in language as written down. It's a view of the world. It's a language synergy of the world, which is quite different from the view of the world that we talk about mathematicians not talking to one another, but pointing to things, or moving things, or, visual images. Has UNIX - I don't want to say ignored, but... Has UNIX tended to emphasize that linguistic turn and leave aside questions of more visual patterns of thinking? Has this been conscious among people, or...?

Aho: Well, I think you have to bear in mind, when UNIX was born, the input device was a teletype machine. That...and what people were searching for were dictions by which one could use that kind of human interface to the machine. So, taking abstractions that represent various aspects of human endeavor, and translating those into ASCII strings was the question of the day. When one entered a document, one had to take two- dimensional limitations like that of mathematics and find a linearization for it. The common denominator, in UNIX, for information is the file - a sequence of bytes. And, the byte stream has, as Thompson puts it, the nice property that you can compose functions on a byte stream. Take a byte stream as input, and produce a byte steam as output. It's very easy to construct a filter. That is just a sequence of byte stream to byte stream mappings. Um, well, people have searched for what is the two-dimensional analog of the byte stream. And, I think a Turing Award could be won for getting the right abstraction - something that is as ubiquitous as the byte stream for one-dimensional input - what should that two-dimensional representation be? And, what seems to be happening is that there are many two-dimensional representations if you go off into the area of CAD, the design of tools for VLSI design. The circuit can be looked at at many different levels of abstraction. You might be interested in the logical properties of a circuit, or the electrical properties of a circuit, or the layout properties of a circuit. In each case, you want to have different dictions for talking about these different levels of abstraction. It is the common denominator that links them. Files on UNIX are universal, but they might not be the most efficient representation. So what we are seeing is, I think, a mention of abstractions for dealing with different application areas. But the abstractions that are used to talk about electrical circuits are quite different than the abstractions that are used to talk about chemical structure diagrams, which are quite different from the abstractions that people use to talk about music. And, it may be the case, and, in fact, I feel it's the case, that what we are seeing with computers is just a mirror of human activity, and that information comes in many different sizes and shapes. These sizes and shapes represent the different aspects of human endeavor.

MSM: So UNIX began as...with the teletype as the major interface, with the file as a stream of bytes. You used a Darwinian image before. Is UNIX wedded...so wedded to these forms of data that it won't...it can't adapt to, let us say, a more visual way?

Aho: No, in fact, far from it. I think UNIX has an enormous amount of flexibility. I don't know whether you've talked to Dennis about the evolution of the UNIX system, per se, but version 10 UNIX that we run today is significantly different from the early versions of UNIX. What became very clear, very early in the game, is that computing is a worldwide fellowship. Computing is not done in isolation. We like to have access to other people's ideas, programs, information. We like to have it conveniently accessible from whatever appears on your desktop, or whatever you have on your phone. And, you'd like...at least my view is that you'd like to have what appears on your desktop to be very much like the telephone, in that you have access to the same services no matter what telephone you use, and, that it has a human interface that's easy to understand, and gives you the connectivity that you'd like, to both other people and to information and computing resources, and whatever other kinds of information resources that you want. There is a lively debate going on of what kind of graphical user interface do people want. And, it may be the case that there is no single graphical user interface that's going to be good for everyone. On the other hand, I suspect there are going to be common elements that everybody should understand so that, or, at least the basic functions people can use this tool productively in their lives. Text is going to be around for the foreseeable future. So no matter what kind of graphical user interface that you're dealing with, you are going to have to be able to deal with the word, as it appears - certainly as we know it today, as it appears in books and papers. And UNIX is very well suited for that. So you are going to need that kind of mechanism, which is, I think, well represented in UNIX. But, I suspect we are going to have our different user interfaces that one can overlay on the basic computational model that UNIX presents, depending on what kind of application are you are interested in. Certainly, people are visually oriented, and I think that being able to manipulate computation and resources in visual forms is going to be important. But, from another perspective, these are just...just manifestations of language - more complex languages than we've had in the past. But, we are dealing with different kinds of syntax; but there is a syntax there, and there is a semantics there. The basic principles that we have understood in terms of syntax and semantics still apply, except that we have to use more powerful mechanisms to describe them. And, the semantics are more complicated, especially when you are now dealing with issues such as concurrency - objects that can appear at different times or simultaneous times. Arriving at the terminal, you have to have some mechanisms for being able to cope with that. From one perspective, that's just a mirror of society, that society has set up certain protocols for guiding interactions; as we are having this conversation, there's a certain implicit protocol that we follow. If there were five people in this room, we...we'd exercise a certain protocol.

MSM: Yeah, there is...there are certainly protocols that we follow. And there are exchanges on the one hand, that the overt manifest exchanges. The way the exchange of words... We also, of course, give a lot of signals off to one another. We have both been maintaining fairly intense eyeball to eyeball communication here. Watching one another's gestures, and that's been part of the conversation. How we steer the conversation, of course, is not being caught on that tape at all, and therefore will never be caught by the transcript, and, yet, we'll be [MISSING SEGMENT] a full understanding of it. I am not suggesting that...you know...obviously...we have the faintest idea of how one captures that...

Aho: Yes.

MSM: ...record of language, record of that language, or whether it's...one wants to try to get computers to do that.

Aho: Well, I think the great challenge today is to improve the ease of use, and the effectiveness of use of the machine. And, if one can find successful ways of harnessing two-dimensional inputs and, in fact, other forms of input - why can't we combine voice?

MSM: That's been a longstanding dream of the Labs, hasn't it? You know we can talk to these things, and get them to talk back.

Aho: Yup. And, in fact, if you look at some of the work in Jim Flannigan's lab, it's remarkable what progress has been made in terms of speech synthesis and recognition. The big trick, and there is also another development that is taking place, and this is optical character recognition. We can put devices...paper into scanners, and have that automatically be translated into forms that can be manipulated by the machine. We can deduce the lexical structures of what's on a sheet of paper. But the thing that's really required to make both speech understanding and OCR fly is to harness semantics, and that's going to be a long time in coming. That if you want to resolve the ambiguities that are present in our language or interactions, which humans do naturally as a matter of course, you have to understand what's being said. And I suspect...you know it's rather remarkable that all I have to do is say a few sounds, and you immediately recognize my voice. Why is that?

MSM: I thought you were about to say that all it takes is a few words and we communicate. But the thing is that the two of us walk into this room, with the world, each with our own experience of the world. And it's an experience that at various points is intersected. Not that we've intersected one another, but, rather, that the world we've experienced has been in some cases the same world - reading the same books, meeting the same people, being in the same places. That has also aided communication. Both aids it and also can block it - lack of communication because of the false cognates.

Aho: I think of it as a symbol table. We have a large shared symbol table.

MSM: Okay.

Aho: Did...it might be interesting, in fact, this is a view that I have, and it's clearly shaped by what my background was. What is the view that you've gotten from the other people who were involved in UNIX in the early days?

MSM: Well, what I'm getting is the shared view - that people do tend to think in terms of languages. They do tend to think in terms of tools. There is this property of UNIX that struck me from the first time I encountered it. As someone interested in the origins of the so-called software crisis, I knew the problems of programming, and someone who had been pulled back to the subject by Joe Weizenbaum's book, and the marvelous view of a hacker, and this whole notion of people's sitting and hammering away at this machine, and writing code that works almost as a black box, and needs a black box for the person that wrote it. Now you encounter something like UNIX, which on the one hand represents really extremely sophisticated and clever programming. And then, on the other hand, if not theory driven, at least rooted in theory, and sensitive to theory. Programmers' development tool, yeah, but, also, it seemed to me a reflection of explorations in applied computer science. What I've been trying to get at in these interviews, among the many things that I've been trying to get at, is how that...do you...seem to be. The problems with programming elsewhere make it clear that it's not natural. This is the sort of thing that may just happen, it may be managed, it could be a question of place and time, and so on. I'm getting glimpses at it, but the phenomenon seems to be clearly there.

Aho: I'll certainly be interested in your insights as you digest more and more of this material and accumulate more and more of this material. Could UNIX have happened at some other place...? Or did it take a place like Bell Labs, which had a tradition of hiring people who have both breadth and depth, and a mathematical proclivity?

MSM: That's a good question, and it's one of the ones that has to give answers. There is an obvious...as I have been thinking about this...in what form will all of this take? There's some obvious contrasts. One of them is prompted by the recent book, Fumbling the Future, which is about the failure of Xerox to go with Alto. If one wanted to think about comparisons of environments - that research environments were supposed to be unhurried. "Let's get a lot of bright people together and give them time to figure out what they'd like to do, and see what comes out of it." That, you know, Xerox PARC is the obvious place or comparison that I'm about to make. And an interesting conversation with the person that did the first paintbrush program. He was demonstrating up at SIGGRAPH over a reception at the computer museum.

[BREAK IN THE TAPE]

Aho: The math center has long had a mission of doing work in fundamental areas. Starting off with the work of Shannon, and there's also a certain consultive aspect to the work that the math center used to do that we would be treated as consultants by the rest of the company, who could be called upon to help out, to help understand phenomena that was important to the telephone company. But, they were given a charter in which there were no holds barred in how they solved those particular problems, and some very innovative solutions came out of that. I think that kind of tradition was inherited by the computing science research center. And I think it's a good tradition to have. That...there were also very high standards for the work and the people, that, no matter who came in, you were expected to be the forefront of your field, and be able to interact with the forefront of your field. There was probably also an implication that the real contribution was not just writing the paper, or, in fact, in many cases papers were never written. But, the real contributions were the ideas, and the refinement of the ideas, and showing people how to use these ideas, to solve problems of interest. I think that attitude still persists: people are interested in solving problems, but solving them in ways that no one ever thought of before.

MSM: And in sharing the solutions with each other. A fairly small group that has a remarkable longevity.

Aho: Yes, um...

MSM: One doesn't see that kind of stability outside of an academic department. Think of the people who were involved. Here I am, twenty years after the event, coming in and working my way down a hallway, and getting most of the actors who were involved in it - and have been involved with it over the intervening twenty years. I can't think very easily of another situation in which that would be the case.

Aho: I think its freedom, the focus, and the stability, and also, I guess, the funding that supports this kind of activity, that there's a catalyst that takes these ingredients together and, once in a while, produces remarkable innovation. Datakit, I think, has also been, if one were to use the embodiment of Datakit, the fundamental idea is virtual circuit packet switching. This is what Sandy Fraser has his fundamental patent on. It was an idea, and then there was some chance to show what you could do with that idea. In the Karmarkar's algorithm, I guess, is another example of, "Here's an idea, and then there's an opportunity to show what you can do with that idea." First and foremost you need the idea.

MSM: But there's also...it seems to me there are certain ideas that emerge in this environment, and those that are not likely to do so - because of an internalization of the institution's mission and goals.

Aho: That's undoubtedly true. And, we're certainly not going to produce innovations in Chaucerian poetry.

MSM: Also...is there...I think Lorinda noted...not particularly enthusiastic about AI either.

Aho: I guess I have two views of that. A lot of the work that we do, and a lot of the work that Lorinda has done, many people, and many people in the AI community, would also call AI. But, there's more of a bent that we are interested in solving problems than, perhaps, putting the fancy buzzwords on what we're really doing. And I guess, also, people here tend to be somewhat jaundiced in terms of making claims before the experiment that demonstrates the results has been done. I think there's a great tragedy in a lot of work in certain areas where people make claims that can't be justified by scientific experiment. I give AI people a great deal of credit for attacking problems that most scientists just wouldn't go near. But, I also feel that the field may have done itself a disservice by making unsubstantiated claims, which one wouldn't do in a more scientific tradition. One of the publications, I think it was, perhaps, the American Math Monthly, talked about, "Was it necessary for AI to be able to make these outrageous claims for the survival of the field?"

MSM: I want to see that...

Aho: Umm...and, there you go... Sure, find it in the library. I found it a rather interesting perspective.

MSM: Well, there's...there's an article of an issue of Daedalus, which is the journal of the American Association of the Advancement of Sciences...no, no...I'm...I am sorry, that's wrong. What do they call themselves, that outfit in Boston? Anyway, it's about the artificial intelligence...well...the state of the field, the debate going on. An article by Pappert, about, in essence...

Lorinda Cherry

The interview date is unknown

MSM: Well, how did you get into Unix? When did you first get involved in it?

Cherry: Well, Unix didn't exist, I don't think, when I left for Kwajalein. And at that point I was to resolve with Nolton. And, as I say, I was gone for about a year, maybe a little more than a year. I went and did like six months in Whippany, four months in Kwaj and then back, took another couple months to escape from Whippany. And when I came back, Unix existed in some very, very early action [inaudible]. I remember Doug sitting me down at a teletype and telling me to type. A big, old, clunky teletype. And I think the idea at that point of what they thought I was going to do was build Unix systems, that was the assembly version used at Unix. And each system had to be hand-crafted with the proper device drivers and stuff like that. And I did build a couple of systems, one that we, I've forgotten for what group they were for. But I did build a couple of them.

MSM: Now when was this, can you give a date?

Cherry: '72? '73? So that was a job with assembly-language Unix

MSM: Yeah, I think it went over to C in '73.

Cherry: So this was '72 then. And I ended up working with, still doing lots of text stuff. All of text tools were developed. And with Bob Morris and Lee McMahon, doing the Federalist papers from this paperback, all of them, taking turns typing.

MSM: What was this, to redo Mosteller's stuff?

Cherry: This was to see if we could confirm or deny who wrote which papers.

MSM: Yeah, this is Mosteller's statistical analysis of authorship.

Cherry: We never did come to any conclusions, I don't think, but we developed lots of tools for processing text in the process. And this led to some other statistical stuff that led to typo, which is one of the early spell-checkers, really was a typo checker. It worked based on trigram statistics. And there was some compression stuff based on trigram statistics also. And I can't remember which came first, whether typo came before the compression or if the compression made life to typo. Way before spell, again I could find a year on that. When spell got good, typo got dropped, although it still turned out to be a somewhat useful program.

MSM: For other reasons or other applications? The serendipity factor in Unix seems to be quite high.

Cherry: Yes, it is. Very high. And there was this flavor, other people probably talked about this, but it was group dynamics all going on up there. We were all up in the sixth floor. Although I think I worked mostly in my office and visited the sixth floor with questions, [inaudible] the sixth floor. But there was this attitude, there were all these little tools built, and it was the idea of pipes that just kinda, of stringing things together, that was all neat and wonderful. And there was this attitude that he who touched it last owned it. So if you needed pr to do something pr didn't do, and you went and added it, you now owned pr. And so if some other part of it broke, you owned it.

MSM: You were now pr's support.

Cherry: You were pr's support. Yeah, so a lot of the programs floated from person to person because somebody would add a feature to sort, and they owned sort. Somebody else would add a feature to sort and then they owned sort.

MSM: Actually, let me back up a bit, because you talked about coming back from Kwajalein, breaking away form Whippany and then said they put you in front of teletype. But how did you know about this at all. I mean, did you seek to join the group or were you looking around for another assignment?

Cherry: Oh, see, well, I transferred from, the Kwajalein experience was, I really loved my job and I was not thrilled with it, going into Kwajalein in the first place. And my husband had done two tours of Kwajalein and really wanted to go, and the chances of coming back with what at that time seemed like a large amount of money, 'cause he didn't pay taxes at Kwajalein. And we would be a two-salaried couple at Kwajalein and there's almost no expenses in Kwajalein; their housing's free, your entertainment's free. You buy food and you shop. You buy things and you store money away.

MSM: Not a lot of shops in the quarter-mile area.

Cherry: You did a lot of mail-order. Everybody bought crystal and china and the best electronics. Go and you name it, they had it there. No car to support and actually there were only about four technical women on island, that whole experience. It was interesting in itself. They didn't know what to do with us, there were various perks that they didn't feel one couple should have twice and I figured I worked for it too. That was the way it went. I fought a fair number of battles, going out there, but I had transferred, I had worked for Nolton but in Flannigan's area for about a year and I finally managed to get transferred into this area. I took myself to see Morgan, but don't print that. And so I had been, I guess, in this group for about a year when we got the opportunity to go to Kwaj. And I extracted from Mr. Morgan a promise that when I came back from Kwaj I could come back here. Now I didn't know if whether he'd still be here or whether he'd remember his promise. And then we were supposed to do a 18- month tour of Kwajalein and my husband had an ulcer that kicked up after two-and-a-half months and they were not willing to let him go to Honolulu, have the surgery and come back. They just said "out." And so we were there basically two-and-a-half months, actually. And we hadn't sold our house and it hadn't rented, so we had a place go back to live. But we'd sold our cars and he'd sold a boat, and all the stuff you do when you go abroad for eighteen months, we'd done. We shipped off all our household goods a month before we were supposed to go, and everything you consider essential, you can't live without, you pack it all up in a box and ship it. Well there was a strike on the West coast and so our box went from New Jersey to the West coast. We lived without our stuff for a month, we got to Kwajalein, there was a strike. The stuff got to Kwajalein a week before we were due to be shipped back and so everything we considered essential to life was in transit for about six months. Just unbelievable. I mean we opened the container to shove some stuff in that we bought, and we left stuff there, we left the dishwasher there with the bicycles and stuff. It was a very traumatic experience.

MSM: It must have been.

Cherry: And I got back to Whippany, and they wouldn't let me escape. I mean, they had done all this personnel and who was shuffling where and whatever, and they wouldn't let me escape for a couple months. But as soon as they let me escape I was back here.

MSM: What attracted you here, to this group in the first place? What were you going to work on?

Cherry: I had been doing support programming, FORTRAN programming for Flannigan and Schroeder, who were down there. Almost exclusively FORTRAN programming and after about a year-and-a-half's worth of FORTRAN programming, I realized that this could be speech signals or soy beans, it didn't matter what it was. And it was very boring for programming somebody else's ideas and that time I wanted to do systems work and couldn't get transferred inside and actually sent resumes outside to a bunch of places and was overqualified for all of those jobs. It was in the days when everybody was training their own. They'd bring you in green and train you on their programming language 'cause they'd bought the system with no software so they had their own unique system. And so it wasn't easy to be mobile back then, not like it is now. So I hung out there a while and I managed to, I don't know how I ended up working with Ken. That was real interesting work that led to those pictures behind your head there: 3-D ball and stick models of atoms.

MSM: So you were working with Ken Thompson?

Cherry: Ken Nolton on graphics. We did E-flicks and we did the atom stuff, those were the two main projects. I'd done some graphics and some other stuff. I can't remember how I got in with Nolton, except we did some signed processing with Manfred Schroeder also back in those days similar to this stuff. I believe that [indicating a photograph on the wall] was done by Leon Herman. But Schroeder and I did a similar picture, maybe even before Herman did, I'm not sure now, that was used in the Experiment in Arts show at the Brooklyn Museum that had some [inaudible]. I believe that's the first time I met Herman, and we did the cover of the program in this style with a picture of the Brooklyn Museum but with a text of the dates and name of the show and that whole business. But the same idea. And we'd done some other picture processing, I think it was an offshoot of Speech. And that's probably how I ended up working with Ken. Also Jim __ was not happy doing what I was doing. So he was like, let me loose to something else but don't quite let me loose, that kind of thing.

MSM: So you got involved in Unix essentially as a programmer, assembly language programmer.

Cherry: And did bunches of several little tools, most of which have since totally disappeared. There was a form letter generator and form letter editor. Either Bob or Doug was one of the ACM editors, so we did this thing for all their correspondence and stuff. It died 'cause no one was interested in rewriting it in C when everything went to C. dc, the desk calculator, and the storage applicators were translated into C. And every now and then we still find bugs in them. It's been fifteen years and we still. About a year ago, we still have the assembly version around here. I can go to the assembly when I got a bug report. I went back and it was in the original design. It wasn't one I'd created in changing everything to C. Divide, it's always the divide element. It does digit-by- digit long division and getting it right used to be very hard.

MSM: I'd mentioned how people found their projects. You get a good person and then give her a chance to find her project?

Cherry: They don't give projects here. You invent your projects. Now I was promoted to MTS in '76 and so before '76 I was almost always collaborating with someone and it was mostly me doing the programming, although we certainly it. I mean, Brian and I both did programming on eqn and that was a real collaboration. I think a lot of the stuff I had with Morris was more an honess to his programming, and then from '76 on I was a full member of staff and it was a somewhat different kind of collaboration. The compression project, I did all the work on that. I came with a phone company. They had this giant phone book and it had this wonderful possibility for compression and the way it was stored you could compress pieces of it and store it in little blocks and they had major update problems and a bus schedule to meet and all sorts of other stuff. So it was like, how can we compress this cheaply but save ourselves a bunch of disks? And that was where some of the ideas for the trigram stuff, to take the largest strings based on trigram statistics.

MSM: What are trigram statistics?

Cherry: Three-letter combinations. The way that worked was if you had a word ten letters long you do a running three-letter statistical computation and you get ... and you can go off and grab the statistical string that had the greatest payoff in terms of compression and...

MSM: And they get compressed by what?

Cherry: You take the whole string, if your ten-letter work had maybe a trigram that was six letters long that had a high enough count to be worthwhile, you pick that entire six-letter string off and store it in a dictionary and replace it with a byte and then with an index into the dictionary. And then we further Huffman-encoded it. There were several levels of compression, and I don't remember all the details anymore, it was a long time ago. But the thing that was so unique about it was using trigram statistics to pick the strings 'cause this stuff, as I remember, had data as well as ASCII, I think a thing that ordinary compression techniques that were known at the time, it didn't work. We wanted to see if we could compress strings that were longer, you know, as long as possible. I think trigram statistics worked well for that. I think typo must have grown out of that, as opposed to the other way, now that I think about it. I think that trigram compression stuff came first, then I think the we said "aha, I bet we can use that for finding typos." I would have to go back and look at something and see which way, which was the chicken and which was the egg, on that one.

MSM: You then got involved in Tech preparation?

Cherry: Yeah, eqn came about right after Hannah got troff [inaudible]. You could do this stuff, but how could you do them. As I remember, Brian had a summer student who worked on the problem for a couple months. And he left and it was still good so the two of us picked up and started working on it. Brian may remember that differently than I do.

MSM: I talked to him about eqn, we started to talk about [inaudible], a problem in language, I didn't think about it as a problem in graphics.

Cherry: No, the graphics is easy. The hard part is getting a language that you can teach to a math typist that will just flow off her fingertips to complicated graphics. I think the language part of that is what was neat about it. It's still what's neat about it. The graphics part of it, I think Tech is still better as far as what EQN does and what Tech does. From a mathematical standpoint I think you'll find Tech better, but I don't think Tech stuff is anywhere near as natural to work with. That may be very prejudiced, I don't have a...

MSM: As a historian, well I don history of math so it has a certain amount of math typeset in there. So I'm used to EQN. I must say it's good enough that I'm not tempted to go through the work of learning Tech and make the transition.

Cherry: Yeah, I've had to learn Tech in the latest thing I've been working on and I've found it very painful.

MSM: You said you got your Masters at Stevens. Is it in math or computer science?

Cherry: Out of the math department, but in computer science.

MSM: Did you have to design that program yourself?

Cherry: No, it was in place. I finished that in '69.

MSM: Did you find that curriculum by and large supportive of what you're doing here? Was Stevens' idea of computer science was and this research groups' idea of what computer science was, the same thing?

Cherry: No, the computer science aspect of what I took at Stevens, things like Turing machines and numerical analysis, which I didn't care for even as much as I love math, I could not get into that. But there wasn't really a compiler course. It was very early in their computer science. So although it had computer science leanings, it wasn't much of a computer science curriculum really. Much more heavily in math. When I started that I was in Flannigan's area and that was quite appropriate 'cause I was working with all the engineering, quark models, and differential equations, and simulations stuff. And so it dovetailed into that perfectly. And no, it didn't fit here at all. But I don't know where you could have gone for a curriculum that would have fit here. In fact, I'm not sure that anyone who was here at that time was really a computer scientist. I think everyone's training was in something else - it was in math or engineering. It was sort of a pre-advanced degree of computer science. Programming courses, yeah, but not a lot with theory out there beyond the Turing machine.

MSM: So the theory sort of caved the group while you were here working.

Cherry: I think so, yeah.

MSM: Did you notice it slipping in the door? Did you see it coming?

Cherry: Certainly, a lot of the compiler theory and stuff. I think it sort of came __. Compiler theory's gotten very strong and I don't think it was back in those days. I'm not a real good theory person, I'm a practitioner. I'm off to write programs with any excuse or any activity. A lot of the things I'm involved in outside of here still end up involving programming. Maybe that comes from working here.

MSM: Oh really?

Cherry: When I was showing Dobermans, I did statistics on judging, published articles on some of the, did publications on who did what to whom and whether judges seem to have color biases, whether judges would put up puppies or they would only give points to the adult dogs. Some very angry people, if you show them what the statistics said.

MSM: The reason I was asking that was that one of the things that struck me from the beginning about Unix was that on the one hand the elegance, professionalism. The coding, on the one hand, really clever coding. On the other hand, the way in which everything seems to have, if it's not driven by theory it at least has some theoretical point to it or at least some theoretical foundation to it. So that it's highly disciplined and has a purpose.

Cherry: There's certainly some discipline in what's allowed to hang around and what isn't. One can watch that in whatever manual is produced and Doug starts throwing programs or people start, rather than document this file were going to remove it. It's not really necessary, there's another way to do it.

MSM: But what constitutes documentation? I mean, does a documentation have to be of a certain , does one have to justify in terms of practicality? I can find a use for it therefore it stays?

Cherry: That's hard to say. If you look at the Berkeley Unix system and some of the commands that are similar, the same in Berkeley as what we have here but you look at the Berkeley manual they've added 85 flags to the Cat command or something. It was a very simple elegant thing that did a very simple job. I guess we've always had the attitude that it has to be really useful to be worthwhile putting in. Maybe just 'cause it was a smaller group than at Berkeley or maybe people in Berkeley, everybody needs to find a niche so they've got to put a flag on something, I don't know what the environment is there. But I think it was here to prevent featurism. I think that's the difference between the two systems. And I think that undoubtedly has to do with the university environment where everybody has to do something as opposed to the environment where in some sense everybody had to justify what it is they were doing to your cause. And there is also some hesitancy 'cause it you touched it you owned it, you thought hard about whether you needed to add that flag or whether there was some other way around it. Whether there was some program. You said "I'll find some other way to do this 'cause I don't want to own this program."

MSM: How long did that continue? Owning?

Cherry: Gee I don't know when that went away. It persisted a while after things were in C. {} It was certainly the attitude. And that did give you pause. [laugh]

MSM: It seems like a {} marvelous, marvelous way. I've got to think of some way to impose that on my colleagues. You teach the student you own her. [laugh] she's your responsibility. The text preparation program, if I understand correctly, was some thing that got started up as a joint venture with human...

Cherry: I thought it was with the patent department

MSM: my understanding was that the patent department took over the device but that it originally started with something {McMahon} and Max Matthews.

Cherry: That may be how they got Lee, {John Degrew} who did a lot of, as I said, statistical stuff and things of that nature, but Lee I can't remember exactly when He came on the scene. Um, may be on line somewhere because we put together some stuff for him {} and some dates and things. So I may have been on line. It was um all done from people's memories. Although some of it certainly from the employment records and when he actually switched cause he was, he was department head in {ops} center for a while he did the snake there and I think he came to us from there although he may have made he may have gone through Max's area on the way to this area. I'm not certain.

MSM: How did this, the um statistical analysis of text was this a research interest that people had or was it written by some practical ...

Cherry: I think it was research sort of the attitude back then at least my attitude and what I thought was sort of the prevailing attitude um and I still consider it, its still an attitude, um if asked what it is I do I see what kind of neat new things I can make the computer do and in those days the computer wasn't doing a lot, but it was super-interesting and there was a lot more stuff you could make it do. And things just kind of evolved from sort of that attitude. Oh, we've got all these new tools what can we do with them? One thing we can do is some statistical analysis of text and see where that leads us and we can do it on gobs of text now instead of the hand-counting text that had been done Now that computers had upper and lower case that's another thing that changed with UNIX but um was the case recognition. DOS still doesn't recognize case in some sense. DOS {} its command line which is upper case you can type lower at it and it will type upper at you. But there's the case distinction I think we've been ah something was new and that lets you do different kinds of text analysis or statistics that then had been done before. Interestingly enough I had a call from somebody from Adobe um about a month ago looking for some text statistics. Because they took out {} their caching stuff on the on the ah printers. Bob {lianov} had {} our own text statistics in {ATT} tech um you know that accounted for punctuation and blank space and upper/ lower case things of that nature.

MSM: Is this {writer's} workbench or were you involved in that project?{}

Cherry: I'm certainly grandmother of that project. Um That was another serendipity Um project um that all evolved from um a program I wrote for finding part of speech running English text. And part of speech project started because um {Brent} Aker had the office next door to me and he had just gotten the um the votrex machine and there was some um I think Doug wrote the speak program that ah {} through that machine and there was interest in adding proper intonation um {} intonation to emphasis ah to speak and {Brendan} was working on that and you need part of speech to do that properly you need it for syllabic stress perfect and perfect and that whole class of words that's stressed differently depending on {part of speech} and you need to know the part of speech to know which word in the sentence to stress um and so Brendan was working on the stress part of it and I was working on the part of speech part of it and ah he left to go teach at Michigan before the stress part of it uh ever materialized and I had this part of speech program languishing for something to do. And Doug talked to ah a guy who was actually working at Princeton Bill Bestry {} in the English department and one of the things he had his students do was count parts of speech in things. {} we can do that automatically and so part of speech program that turns out a few, there are various things you would count and look at using parts of speech to decide whether you've got a compound or compound sentencing sentences types, so the part of speech program turned into the style program. We added some readability stuff {from the books down the hall}and we read as many things as it made sense to count and at that time um there was a human factors group in Piscataway um to which Nina McDonald was a member and I think she worked here maybe for a summer while she was {} before she finished her degree and her husband worked here and one of the things that they were suppose to do was um one of their main jobs actually was look at documentation and decide whether it was reasonable from a human factors standpoint. {} They were interested in funding some way to ah getting all this stuff um you know what can we do we analyze this stuff and decide. And so we ended up working together. By {} for them and they put this layer on top of style and diction um and the whole thing turned into writer's workbench and that was sort of a back and forth with this development group and they'd do things and I'd take it and send it back did a {very much extended year probably} maybe more than that kind of back and forth with them. Gee what new thing can we measure or what new thing can we find um it never really did check grammar because you need a you need a real parser to check grammar. And so it does as much as it can with out having a real parser. There's the problem of having a real parser that's going to parse incorrect English anyway. That's not a problem I think is going to get solved in a big hurry {} Somebody has one that's using {} and a dictionary that does a fair job at some kinds of grammatical {} That was a fun project because Lance Miller at IBM was developing epistle at the time we were developing writer's workbench. The two projects paralleled and we'd go to we'd go to conferences and give talks and he'd give his epistle talk which was based on a real parser written in LISP, it took three minutes to parse a sentence and I would give my writer's workbench for style and diction talk and at that time part of speech program was running at something like three words a second on a rolling seventy and so it was feasible to parse even on 1170 it was feasible to run this on a reasonably large paper. And it wasn't feasible to run a real parser on reasonably large paper and everything's gotten faster um probably the part of speech program wouldn't have been developed at {} cause it was very constrained and design requirements from where it got its basis name when it was part of this small string of programs that was learning to speak to the {vocoder}. Um and what was what turned out to be interesting the parallel continued and writer's work bench went to Colorado State for a sort of a beta test in their English department and they use it and loved it and you know it has sort of since become a project {its..} its out there in English departments um IBM did their beta test I think at Chicago and it fell on its face because it was presented with this incorrect grammar that the students were writing and the parser couldn't cope with it um and I think the whole thing ended up getting canned [phone] and parts works because its got a press-on- regardless attitude it's going to assign some part of speech and go on and it may not be write, but statistically across the paper it will be. And its that press-on-regardless instead of taking ah building this tree that's got twenty different possibilities that you know a real parser ends up having to do um that just doesn't fly in the face of ah student text.

MSM: Is writer's workbench being used?

Cherry: I believe its being used. About every six months they try to resurrect a group um or they assign somebody else to it so it must be still out there lost track of it and ah the person who's in charge of it seems to be a moving target the actual technical person who owns it but I believe its out there in {} being sold in {} and some high school and college English departments. I haven't talked to Colorado recently to find outs what's happened, they are still writing papers about it so that must say they're still using it.

MSM: We talked when we were going through having {} how we were going to spend the big IBM grant for computerization at Princeton back in 1984. The idea was gee we ought to get writer's workbench. It turns out when people think about computers and education today first off, the scientist and engineers know exactly what they want to do

Cherry: Right, the humanities folks do not

MSM: And the humanities folks don't

Cherry: And they're afraid

MSM: {} To use it as ah writing as a tool for teaching writing and then the question well what tools have we got for doing that and ah that's where it sits right now. I was wondering if other schools were {} I ran my own stuff through style the other night so

Cherry: Uh-huh, at the time we were working on style and diction Andy Tannenbaum was here and he was across the hall working on a book and they're some interesting human factors, things about diction in particular um he had done the first couple of chapters. And he ran the program on the first couple chapters and it gave him all this output and it worked and what happens if you use the tools and you're in a large writing project at any rate is the kind of wordiness that it points out to you. You stop writing=2E So it self-destructs. By the time you write the last chapter, you're not writing that kind of prose anymore. My feeling about a lot of those tools is there value in education um is as much pointing out to people who are learning to write that they have choices and make choices when they do it. They don't think of a writing task as making choices per se. Once they get it on paper they think it's cast in stone. So it makes them edit.

MSM: Yeah, that and computers exacerbated that problem. I've f{ough}t a like {mad} against the proliferation of laser printers on campus. The computer people all want them in there and my attitude has been, "Look, you keep telling them to use the word processor because they can then treat their writing tentatively and they can go back and make corrections and re- write and re-write um and let's set aside the whole problem of yes its easier for us to re-write but its not any easier for us to re-read

Cherry: Yes

MSM: Um but when you put a laser printer there they get it off the laser printer and it looks so good it...

Cherry: must be okay yes it must be okay cause it looks pretty.

MSM: That's right {} from my point of view I'm getting the same junk

Cherry: The same garbage, only it's pretty [laugh]

MSM: But it does, the hardest thing with students is getting them to appreciate a sense of voice, that is, you talk to different people different ways, you gotta have an audience in mind, you got to choose what you say on{}, you're not writing for me. This paper doesn't sound like you, have you ever tried reading to your roommate and asking your roommate if it sounds like you [laugh by O]. "No, I've never thought of ever reading my paper out loud." Not even to yourself, I bet. "No, not even to myself" Well, why don't we start there. And you know so fundamental

Cherry: Yeah

MSM: Then we'll start working on writer's workbench. When we've got you with some sense of audience then we can talk about what readability index might mean or we'll talk about variety of sentence length

Cherry: Yeah readability indexes are real iffy, questionably things the reason writer's workbench computes readability um first of all, they wanted it in there and I said, "Okay we will put four different readability. I grabbed every readability index I could and put all four in there, because it's obvious when a it computes four different ones that it's a moving target. And when they put the section in {} prose, um they were going to report readability to the decimal place. "No decimal places, just give 'em rate." Cause you get supervisors around here who will say, "No I want at this readability index." So I made them give a range or at least not report it, report it in such a way that it's a questionable number. I think it says something about text um but I don't think you can write to one. {} Nor do I think you can go back and revise to one. It has to do with voice and audience, word choice - you can choose monosyllabic words that everybody understands and get a high readability index and you can pick small words that nobody understands and get a low readability index and you're going to have the opposite effect on whether people can understand the document.

MSM: Did UNIX lend itself particularly to this kind of work, er, was this the sort of thing one could have put on any system?

Cherry: It lent itself to the kind of work because it was time-sharing. You could do stuff in the background. It's hard to remember not having multiple windows and multiple things and so it's hard for me to step back. Computing today is a lot different from what it was then but computing then it was my first experience with a time sharing system. I didn't do very much on the Honeywell system {} um but it was still slow and um maybe part of that whole UNIX thing was that there were just a few of us on this machine and response time was pretty quick and you could think about doing things that would take forever and they wouldn't charge you or wouldn't take forever but{} some other environment There was no charging so you didn't think twice about running something which used to happen if you had a computing budget there was no computing budget involved with UNIX. We were inventing ways to use all these cut little programs that would string together. That was all in the concept. Um {} using other programs, very special, specially developed programs that do their own little task very well, adding to that, that pipeline. I can't remember when I didn't think that way, but there was a time I didn't think that way I know it [laugh]. And that kind of thinking sort of came along.

MSM: Yeah, {} that's happened with {}. Basically laid down my question.

Cherry: And so, yeah I think all those nice little pieces if you wanted to sort something you didn't have to think about writing sort, sort existed. And you could think about may be using "said" to call out exactly what it was you wanted to sort um. Just the concept of putting all these pieces together was new. Those kinds of programs didn't exist except as big monolithic things. And so I think that did lead to a lot of the interest in doing some of the other text stuff that hadn't been done before and things like that.

MSM: {} Textual flavor to UNIX.

Cherry: yes.

MSM: It's just sort of built into its basic design.

Cherry: {} because we were all editing programs. We wanted to it, the editors and things all came about they were off shoots of other editors um {}. Maintaining programs is maintaining text. {} of a group that's maintaining and writing programs which we view as text and publishing papers um I think that's where a lot of it came from. They were tools that we were gonna use ourselves. And that's different than writing a system for somebody that where you don't plan to use it. It's not part of your day to day living. Also it's a funny group. I've had a friend who works in acoustics now and talked to later. It was a McLaren a real, live McLaren seven liter. [laughter] {What a thrill [from somewhere else]} You got it. I had a ride around a race track in a seven liter McLaren two weeks ago and I'm still walking around {} hot. Um in some sense it's a very tolerant group from a computing standpoint. Um {} down the hall who use computers in a different way. Um would not tolerate a lot of what we would tolerate and that's because we all belong to the programs and if you're intolerant of somebody else' program they're {} going to come back to you when they find your bug. Um {}the person that lent most to a lot of the flavor of um maybe not the flavor of the programs, but the robustness of the programs is Bob Ross. I was asking Doug if he wouldn't {} talk to him. I think you should. Bob was a person that if you thought you had a program that worked you went and said, "Bob, I think this program works." And if it was expecting ASCII text he would feed a {core} dump to see what it would do. He would do the absolute unexpected to your program and you would end up going on and making sure your program survived whatever it was could be feed. And he just had a tendency to break things intentionally. That's his specialty, just like security's now a specialty, breaking programs is now a specialty. [laughter about son ] He did not fall far from the tree.

MSM: I thought it was so ironic. I re-read {} came to talk to Ken I re- read his Turing ward lecture and I thought how ironic that it should be about Morris' son who...

Cherry: No, it's absolutely appropriate, absolutely appropriate. Just the kind of {} nut, really the kind of thing I don't. Morris Sr. wouldn't have had the bug in it.

MSM: [laughter] Okay.

Cherry: He would have tested it enough to not have the bug in it. This is the next generation computing you're looking at here.

MSM: [laugh] I didn't think there was entropy in every situation

Cherry: Right. But no Bob had this unique ability to be able to break things and he'd break 'em and they'd get fixed. I really think that's one of the reasons that the tools are so powerful because they're so good. And they're so good because they're very, very robust. And ah you feed them things they don't expect and they at least

BREAK IN tape, switch sides

Cherry: The 11/45didn't have hardware protection. So you'd write a program, and this was where some of the inter-communications stuff came from I think um. Before you typed 'a.al" to try that program you broadcast I'm going to type "a.al" because you might bring the system down. You never typed "a.al" from home because you might have to go in and flip the switches to restart the machine. {laughter from M} And you know when you were editing something it was a write early and often. It was somebody's going to try something that's going to bring the system down, and ah that added to the interaction a lot. You have to interact with everybody. You had to tell 'em you're about to run your new program that may well bring the world down.

MSM: Well also that ah gets backs on the notion of tolerance to though because

Cherry: Yep, you had to be tolerant {} you looked I mean you did a lot more I mean programming then was very different because you really eye- balled that thing before you typed "a.al" in hopes that it wouldn't bring the system down. Cause it was an embarrassment to bring the system down three or four times in an afternoon. You got a reputation, you didn't want that reputation. Um so there were some group dynamics that worked there ah I think the ah fact we all had terminals at home or shortly might have terminals at home {} without things like the UNIX write command you needed the write command anyway to tell everybody you were about to crash the system maybe [laugh] ah but there was a fair amount of dialog that was pre- mail um there was a fair amount of dialog that went back and forth. You had a question and you'd write to somebody and they'd write back.

MSM: So they started talking to each other...

Cherry: Talking to each other through the machine. Very early {} Very early on. Um I mean it was a necessity because you could bring the world down. But it did change the, it added group dynamics that wouldn't have been there in other systems {}

MSM: You never worked on a system like CTSS

Cherry: No. {} No, we had TS setup in the GECOS time-share system and worked on that. {} I don't remember just {} that was down there and that was working on your own project and when you were {} there was no real reason to communicate.

MSM: But the reason here was in part just because you had to let people know you were about to try something.

Cherry: That's right.

MSM: Well that's another way of being hard{} determined, when you talk about the extent to which the hardware has given shape to it.

Cherry: Yeah um and things in the operating system changed as a result of typing things. If you remember typing split, so that some huge file could {} papers I don't remember how long it was but I had this huge file that was too big to edit. The editor wouldn't take it. So{} split it up into pieces or maybe I was splitting it up into pieces for something else. Meant to type split 100, split it into a hundred files, and I typed split 1 ran it in the background, hit return, and went home. [snicker] Got home and I now had this directory full of files named with unprintable characters that I couldn't delete. And I couldn't, I couldn't use the wild card characters, that's vocabulary coming from MSDOS bite my tongue, I couldn't us * and ? cause it produced lists that were too long and it took me all night I think to get rid of that mess that I created and I think I crashed the system in doing that as I remember. The system ran at a I node {} something {} changes. But you know there were various things like that that happened and you said, "Whoops we need to change that or we need to test that or whatever." And part of that again was this group of people pounding on these programs in ways that I think programs are usually not pounded on um.

MSM: {} bout the tolerance. It's also a UNIX way of doing things.

Cherry: O yeah.

MSM: {} ethos

Cherry: There's a UNIX attitude.

MSM: a UNIX attitude and ah, do you have a sense that that's blocked people from following other lines that ah does UNIX hold people back?

Cherry: Gee, I don't know. I think in UNIX. [laughter] So it's hard to say. But it is an attitude. I {} the number of times I've wanted to be able to grep a newspaper or a book for something I know is in there. But there is no physical version of grep [laugh] {} vocabulary um. I don't think it blocks. In that the basic concepts, the thing that make UNIX UNIX, at least to me, is the notion of building blocks and breaking things into small pieces, divide and concur type thing and having those small pieces do a specific job very well. I don't think that's blocking ah, somehow that makes more sense than writing a monolith which is the other side of it that I keep encountering. I just bought my mother a new PC. I'm having to learn some MSDOS, which I did not want to do. I keep hitting these monolithic programs which I can't get out of and I can't make them do what I want to do. And I don't think MSDOS, I think differently, I don't think PC, my instincts aren't there, and I don't want to read the manuals=2E [laugh] I want to be able to sit down and do what I want to do and I can't do that. It's very frustrating.

MSM: That's funny because though I, I learned UNIX and CMS before I ever learned, before I ever had a personal. I nonetheless went the IBM route and I'm glad I did. Um, but it's always struck me the reason for that is that DOS, I feel more comfortable using DOS because of the UNIX.

Cherry: Well, it's UNIX-like. It's UNIX flavor and it's UNIX-like, but its not enough UNIX-like um. The idea that . is an idiom and doesn't mean star dot, the dot is not literal. The idea that that's an idiom offends me.

MSM: I see.

Cherry: You got a real meaning in UNIX. Um there are lots of little things like that ah that are just backwards. I can't get pipes to work on it.

MSM: That's why I like it.

Cherry: And well, then I must have it set up wrong. {} I can't get it to find the second command in the pipes without having a full path name in it. Don't know how I {} talked to some people who say, "Well, people don't use pipes in DOS."

MSM: I use it all the time.

Cherry: No as I say, I might have it set up wrong. I've only had this machine for a couple days to myself.

MSM: What I've done is to go get Polytron's PC version of AWK.

Cherry: That's what I need is AWK.

MSM: Okay. It's nice, you can get it for 85 bucks. And it follows the, in fact what they do they say its 85 bucks if you don't need the manual. If you already have the manual you get it at a lower price cause the manual is the manual.

Cherry: Yes, okay.

MSM: And ah, so you can do things. For instance DOS doesn't come with a um way of finding out how many bytes are in a directory. It'll give you total number of bytes on the disk, but not in a directory. Turned out that's a very simple program, if you pipe it from directory.

Cherry: Oh yeah, I program in AWK lots. I program in SED also which is a little strange

MSM: It, it did respond well to a UNIX mentality which is well I'll just take the output for directory and now I'm going to have to strip off the first two lines. But I'm going to get this text and therefore this column is going to work...

Cherry: As I say I may have the configuration table setup wrong it's entirely possible. But I couldn't get it to recognize more at the end of a pipeline without giving it a full path to it. I was very annoyed. It would recognize it with a full path and it would recognize it if it were the first command but not if it was in the pipeline. So I don't know what I've done wrong. At any rate that's a diversion. Except one of the things that blew me away when I bought this machine. I bought {} the 1200 with a hard disk. And it's the size of your case, in fact your case looks very much like it's a carrying case

MSM: Yeah, now I have. I have an 1100+

Cherry: That's why the case looks familiar.

MSM: My 1100+ case fits right next to it.

Cherry: Right, but it would fit in it. {} That machine is so much bigger and so much more powerful than the 11/45we started on. It took up a whole room. That just blows me away. It just blows me away. [laugh] It weighs ten pounds and its got a hard disk, a twenty meg hard disk. And it costs two thousand dollars. I just can't believe it. Not all that long ago we were announcing to the world we were about to type "a.al" because there was no protection on the hardware. And I think the biggest program you could run was 64K or something crazy like that. So it's, it's changed so much.

MSM: My daughter just got rid of her PC from several years ago. Bought one of these two-floppies to take back to school. She'd like to{} rather.

Cherry: The other thing that boggles my brain is that it's battery powered. I'm trying to learn how to use this thing and{} I'll just take this thing in the living room, sit on the couch and play with it. [laugh] That concept still blows me away also.

Joseph H. Condon

The interview date is unknown

MSM: How did you get involved? When did you encounter UNIX?

Condon: I don't know. I mean I guess I was in. I moved out of physics and moved into a project for Hank MacDonald. Local area switching, and that was in room 13. It was in this hallway on the fourth floor. That was one of the systems used on some of the computers. Later on there were other people who had small operating systems running on Honeywell 516s. It didn't really do any real numerical computing. It was just an operating system that somebody else provided that had the right properties and was easy to use. I've never been much interested in the operating system. When I finally did join this group, which were really because of political personality problems with Hank MacDonald in Division 13, I came over and asked Sam Morgan for a place to sit and something to do. From there Sam found problems. So I was learning UNIX at that time with commands that were there.

MSM: When was that?

Condon: I don't know, maybe fifteen years ago.

MSM: The early 70's.

Condon: Yeah, the early 70's. Anyway, Bob Moore who was in the group would come around and say, "How do you understand what these commands do? The manual pages aren't all that clear." He would say, " What do you think is the reasonable thing to do?" Try some experiments with it and find out. I think that was a very interesting clue. At least his philosophy and some of the other people's philosophy, of Dennis's also, of how system commands should work. It should work in a way that is easy to understand. It shouldn't be a complex function. Which is all hidden in a bunch of rules. The field of cognitive engineering with the idea, I think the concept of cognitive engineering is in later or was independent of these guys. The idea is that people form a model. You present them with some instruments, tools, like a facet, electric stove or something like that and demonstrate how it works. They then form in their heads a model that shows how it works inside to help them remember how to use it in the future. It may be a totally erroneous model of what is going on inside the black box. What in fact is going on inside, I think Bob Morrison is telling me, I know he felt this way, is that the black box itself should be simple enough. Such as when you form a model of what is going on in the black box that's in fact is going on in the black box. Write a program to try and outwit and double guess what they're going to want to do. You should make it such that it is clear about what it does. Nobody's ever talked about it. As far as I know, I'm the only one that's ever discussed it.

MSM: Maybe other people will.

Condon: You tell me.

MSM: It's interesting. It's of a piece of what people have been saying. Indeed a piece of what myself felt as I've encountered it. This notion of people forming models and things. In an idea some engineers grasp it whether they verbalize it or not and others don't. A fellow, Don Norman was doing this.

Condon: Yeah that's exactly cognitive engineering.

MSM: Talking about the design [interrupted]

Condon: Most of it's bullshit but there is a core of good ideas you have to pay attention to.

MSM: It's funny because I was thinking of Don Norman as I was driving up here today. I heard him give a talk last year. I went out to dinner with him and one of the things that bothered me about the talk was that I somehow felt I knew all this. I wasn't being surprised and I wasn't being told anything that brought me up short. Now, to some extent because, when I do the history of technology, I am conscience of the models people use and one of the themes in my course is to get students to learn to read the artifacts around them. Some sense these are statements. Any piece of engineering design is a statement. By the designer without the user. What is it going to be used for? Who's going to use it? What does that person have to know? What can that person learn? Who is it going to be used with? Is the person going to be using it alone or in conjunction with other people? These are all embodied in an engineering design. They, maybe a lot of them, default assumptions and they may be wrong. But, they are there. Maybe it's because I tend to think about this. Although, I must say in a couple of cases there are objects that tell you what they do and there are objects that don't. A door and its got a handle and you can grasp it. It already tells you, you're going to open the door towards you. You just have to play with it. You have to push away. If its got a twist handle on either side you're not getting any information out of it. That I found an interesting notion. There is a problem of user interface. How much can a machine tell you about the user? One of the things that Bob Morris remarks that what you think is reasonable. What you expect the reasonable thing to do is play around.

Condon: Go play with it yourself. Natural phenomena that I'm trying to figure out. He has a certain way in mind of how programs could be constructed. Because, I have no problem with doing experimental physics and trying to figure out what god intended and because he does things in simple ways. Einstein said God isn't malicious. Hokum's Razor doesn't work. Most programmers on the other hand are malicious. Doesn't work unless the guy who wrote the program write ID==. (Laughing)

MSM: Doug Ross says, somewhere in one of his writings, "Nature has no problems. It's only humans who have problems understanding nature." (Laughing) None the less there's a shared, well like Bob Morris says something like, do what's reasonable. What's reasonable depends on a community of people. One community will find one set of things reasonable and another will find another set reasonable. He was making assumptions about what you would take to be reasonable behavior on the part of the computer. The basis for that is that people at Bell Labs tends to think about problems the same way. Did you, for example, have the same expectations as other people? Let me phrase it in another way. When you started using computers what was your model?

Condon: I understand mostly what goes on in that black box all the way through wave equations through the circuitry. My problem was to abstract away the detail. Literally, yeah I know what goes on. How the servos work to run the arms of the disk drive, coding.

MSM: There's a jump from knowing at that level to interacting with the model of computing that the machine presents as opposed to its physical characteristics. What model of computing did you bring with you?

Condon: The assembly language code on the 650. As a kid I even worked with serial mercury delay lines. (Laughing)

MSM: You go back that far.

Condon: As a kid.

MSM: Where was that?

Condon: (not clear) We lived on the grounds and we could see them just over a hundred yards. (Laughing)

MSM: So you grew up with these machines?

Condon: Yeah, but more of electronics in general. Computing was just another branch of electronics engineering.

MSM: You say you came over here from area 13.

Condon: Yeah.

MSM: Why did you choose area 11?

Condon: No, no. All that's...

MSM: You came in this as twenty...

Condon: No, no. At some time we added the, ten or twelve years ago, we added the extra digit and everything began with two ones. It was called eleven. It used to be called one. The old system 13 became the new system 113. (Laughing) When I first came to Bell Labs I was in metallurgy. Fifteen, one-fifteen, ok. I came at about the same time as the split. It used to be physics, metallurgy and chemistry all under one executive director. Pysics became one executive director. Chemistry and metallurgy became the other executive director. I did solid-state physics and metals at low temperatures for about five years. Got interested more in the electronics engineering. The project of how we should do telephone switching in the local area network. What is happening in the sixties was in the decades prior to that. Technological advances made great strides in reducing the costs of transmission. Which meant that we were making money hand over fist in transmission. We just could not walk up to the FCC fast enough and get them to get the rate reductions fast enough. So that in fact we were not doing eight percent, nine percent on our money. As we were supposed to be doing. If opposed to doing twenty five percent even though every time we came closer to a rate reduction to get it back. But, technological progress was much faster than political progress (Laughing). We were forced to make all this money. (Laughing) A lot of that money was turned back toward research and development of transmission systems. What was going on in the local area to get it from the central office out to the home and what was going on in the home and the new local central office building has changed since the mid forties. Even that technology most of which had been done prior to the Second World War. Most of the design of the No. 5 Crossbar was done prior to the Second World War and wasn't reviewed much or anything, sort of pressed in. Manufacturing techniques were updated and pressed into service in a hurry after the Second World War. It hadn't been changed until now. There was work on ESS no. 1, which was viewed as a high features and of metropolitan market out for suburbia. So, it was taking a look at what could be done in a central office-switching department for that part of the company that hadn't been looked at. There was nobody developing since it didn't make money. So, we found some things and what the major thing that we found was that you had to look at the whole problem. The traditional way of cutting up between local and on premises equipment and main distribution frame and switching and what not, had to all be looked at. Which got nowhere in this company. Outside plant was done at Palmdell and local area switching was done at the Indian Hill and there were some outside plant things done in Merrimack Valley and the instruments themselves were done at Columbus and Chicago. The lines had been drawn and you could not go back and look at them again. But, we had no difficulty when we were done publishing a few papers because the guys at the Indian Hill said, "Let em publish, let em lead the competition astray." (Laughing) We had great influence in Telecom and Northern Telecom and whatever Western Electric is called now. Great run for the money on ESS No. 5.

MSM: Northern Telecom has just installed a telephone system for Princeton. Keep our fingers crossed. Those of us who have single lines can make connections with the computer, as of the beginning of this week, nobody with a multiple line unit could make contact with the computer. They make contact, but they couldn't get the signal back.

Condon: Yeah.

MSM: You are supposed to be able to take everything off the jack in our office. I want to see it. (Laughing)

Condon: Yeah. Those change-over things are really severe. Really severe problems. You hire special people. I remember ten years ago, Fitzgerald did something. He had been promoted to a rather grand office in front of the new building. I had known him because he had been interested in something about aids for the handicapped. Which was also a nasty problem inside the Bell System or what's left of the Bell System. A friend of mine Dave Hagglebacher was up there with him. He was glad to have somebody to talk to. He's a pretty big guy now. It turns out, he was official spokesman for software XYNZ and a few other things. He had nothing to do. Doesn't go to any meetings, doesn't get any memos, he can get right up there and say, "I'm not aware of any such plans." (Laughing) I know nothing of that sort. That's what his job was. He had three years to go before retirement. Spending all his spare time playing the stock market out of his office.

MSM: Imagine having a job where it is a job not to know anything. (Laughing) When you came over from 13 to 12, got into this group as you put it to find friends in the project. Why did you pick this group? Was it just because you knew Sam or did you have something in mind by coming over here?

Condon: Well I'm much more involved in hardware. Understanding the analog, the digital and the digital analog conversion problems, all those filters and determine if the right current is flowing or not flowing through the customers line. It's sort of a system to understand the hardware system that I am interested in. It was the only other group in research that was doing this sort of thing. The other option was to stay in 13 and move to Holmdel. The nature of the problem was management of 13. It was real trouble. MacDonald was the assistant director and the director was about to retire. Stay in 13 and stay in that laboratory and move to Holmdel. I was moved, although I hadn't experienced engines myself there were a number of people around to say that it was eventual. I was the fifth or sixth department head to work for. I was there for three or four years. A good finishing point.

MSM: This was switching systems.

Condon: Switching systems.

MSM: I never thought of this area as being, at least from what you're saying now, as being particularly hardware.

Condon: No, It's not. In fact the only guy who was doing it was Sandy. In fact, when Sandy came and started doing data communications I lent him my technical assistant. Who was in the second quartile of technical assistants that were in my group. I had a large number of TA's, STA's.

MSM: Did you bring your group with you?

Condon: No.

MSM: You came over by yourself and set up the group?

Condon: That was one of the other things I felt was wrong. Is that the Hat project of big hardware project, research type of thing ran into the same type of thing that the stories you hear about the pyramid. Up near the top of the pyramid, you can't use all of your people. So, the only other thing to do was to start another pyramid. (Laughing) I had this army of people that keep busy and when it comes time to write up the project, really what did we prove, and what did we find and all that sort of stuff. There are twelve guys out there who can't contribute to that. They have to be kept busy. The right way to do research is to build the intrastructures such as to make it such that people could do their hardware project and then use it. Sandy had done a very interesting thing to it. He started out, he called it the draw package. Steve Wong picked up and called it UNIX Design Systems. So as to get the computer to do a lot of the trunk work, helping you design something, designed something and get it through the wire map stage. I had tried to export that. I had seen it and tried to have it picked up at Denver Labs. Just couldn't get the ideas across. Sandy had put it together. In those days the Tetronix 4014 terminals had storage units eleven by seventeen inches. Landscape and he used that as the graphics input, and those cost 15 or 17 thousand dollars back then. So, it's quite an expensive terminal. Yet, it's cheap compared to an STA. So, Sandy's idea was that the designer himself sits as Sandy did at the terminal to manipulate the knobs and do that type of thing. But out at Denver the NDS level designers scribbled on a piece of paper and handed it to a STA to make a modification to his drawing. What they did was replace the paper work with the STA, and went to the sign up sheet and signed up for the 4014 terminal. (Laughing) It was still not clear what the feedback mechanism was, whether the hardcopy came out of the computer and went back to the MTS for checking. It was still the old structure. Just the SDA's using this new tool which was meant for Sandy himself to use. It was built because Sandy wanted me to build hardware and so with being in this division and Sam Morgan's laboratory. There were no TA's. The TA had reported into my department. Later he was transferred over. I guess at the same time he was promoted to MTS. Switched over to Sandy's lab. It seems to be the other Sandy picked up on that. People write programs around here because they want to use them. Can hold an existing operating system on the PDP7 because it had operating system in order to run the programs. The PDP7 actually belonged to me. When I was a (unclear)

MSM: But it's yours

Condon: Yeah, but I got rid of it fast.

MSM: Had that PDP7 been used or what? It was a graphics workstation but it wasn't running Sandy's programs.

Condon: That's right. That was before Sandy even worked here. PDP7 was bought for graphics or something or other that Bill Minkey wanted to build. Bill Minkey was one of those guys (unclear). The PDP7, Kent and Dennis kept fooling around with it. That was something that they did. There was another PDP7 that we had enacted. That was a connector. It was called STARE. Xerox LDX long distance xerography. It was a facsimile system and was really quite impressive. You had to have these private wire things that did several hundred kilohertz bandwidth. Hank had this idea of a specialized machine to do the raster conversions. That was actually contracted out to Xerox to develop that. They were interested because of the product. They never did make it into a product. Since Xerox had IBM machines they built this thing with an IBM connector. This PDP-7 acted like a connector with one end acting like a TE635 tape system, acting like an IBM 360 tape system, and the PDP-7.

MSM: When you took over as department 13. Dick Cannon, and Dennis were already working on that PDP-7? How does one end up working on another department's machine? Do you say, I'd like to use your machine?

Condon: Well, I don't know.

MSM: They were on it.

Condon: Yeah, fancy graphics stuff.

MSM: But, your department maintained it?

Condon: You know, begger's market.

MSM: It's not always the case.

Condon: You do if the budgets are really tight it tends to get that way. You know, when things aren't tight, not a problem.

MSM: And they came all the way to 12? Did you look for a project in 12's area?

Condon: Yeah, cause I knew that I was interested in special purpose projects and one of the first things they did was take a look at project with Al Aho's stuff. Possibly the use of a special purpose machine to pattern recognize, GREP. Those things don't fit into UNIX. You got the problem in multi processing and the same in restoring the state of those machines. You have an extra piece of hardware. It has to be enough for the few registers in the floating point. There will continue to be problems in the co-processors. The microprocessors now delete induced instructions that machines tend to have a large register set. All operations are done between registers. So, there's a tremendous amount of internal states associated with a process. Which then needs to be tucked away when you do a process swap. Floating point tubes are separate in it own set of registers. If you are going to do anything complex you want a double precision floating point registers, sixty-four bit things that move across the bus in addition to 32 bit things. It's getting to look like we're turning around in a circle once again. Where in fact, multi processing systems will be made, such that there may be fewer of your micro processors and your multi processor, physical processor. Which are actually doing the time sharing type of thing. Swapping and changing processors and it's often batch for the other pool of fax machines over there. Just won't do the thing. Nothing happened to them. Then I worked with Ken on Chess where its not a problem. Because there be one chess game going on at one time. It's not practical to make the rule that there is only going to be one search of the dictionary at a time. The first chess machine did not make much significant improvement in chess. It violated the rules of UNIX. It was one that touched the hardware directly.

MSM: It doesn't help their creditability?

Condon: It doesn't help on the CHAOS creator, and a tape unit and it crashes and it never gets anded back. That's the real reason why user code goes through system calls to get to hardware devices. Either the whole system crashes or it kept track of the resources. Some days we had ashes but most of the time we kept track of the resources. That's the real reason why user code goes through system calls to get to hardware devices. That adds enough extra cycles that you don't want it to. You know it was Camden who made the rules, it was Ken Broker who made the first piece of chess hardware.

MSM: What implications does this system set for hardware design? Is there, there's LISP and then there was a LISP machine. Is there a kind of UNIX machine?

Condon: I'm really not the person to talk to on that. But, there were some starts in that direction. Steve Bourne thought that it would be interesting to specialize design of a machine that knew about C, not about UNIX. That would make it easy to compile. I don't think that turned out too much different. PDP-11, C is nothing but an assembly language for PDP-11.

MSM: It was the nicest assembly language he's ever programmed. (Laughing)

Condon: For a PDP-11, certainly not for an IBM machine which has six bit characters, pack six bits per word. It's not a language for a 709 or a 7894.

MSM: We have it up and running on our 370. Have you ever tried that IBM requirement version? I have no idea what was happening.

Condon: But then Steve was unhappy with the computer aided design tools that Sandy had built.

MSM: Why was that?

Condon: That they just were not powerful enough until he got off onto working on the design tools themselves and never did much on building the machine, the C machine. Steve did a very good job of improving the design package. He added three things, they were all in circuit design macros, CDM's. It was a macro capability, you could define a page of schematic diagrams as a macro and substantiate it on another page where it looked like a box like any other chip. He did a library look-up with a method that retains the library private to change PIN mnemonic names into the actual physical numbers that the physcial side needs. Then he introduced arrays of names such that you could have a single line of a name which expanded out to 32 names and then you had a 32 bit address and that could be wired into a single box with four names on it and ray of 10's on that that would expand out eight ways. All this would expand out 32 ways to match the 32 names of the signals coming in. It automatically generated it down to the physical level such that everything was connected up. A lot of the older hardware people still refuse to do that. They will draw the whole thing out. You can't do that without introducing error.

MSM: So your happy your using the tool.

Condon: Yeah, yeah I am happy. Part of the problem was when you come around to debugging the circuit, you get the scope probe onto searching a key number. It doesn't do much good to have the schematic diagram with mnemonic. Clock pin on this chip here. So the documentation is a bit harder to deal with. But I think I have found my own method to handle that.

Condon: There's a steel cabinet nearby, in the lab someplace. So, all the schematic diagrams and a catalog of the names and number translations, but only for the parts that I am using on that job. And that's a standard thing all written in a Shell script. Find out what chips you're using for that job, make the catalog on pieces of paper which then get laid out flat on magnets and that steel door. My lab is down this hallway. I had a big project where the two steel cabinets were not in a convenient place. So, I had a ten foot white board installed across the hallway from my lab. Across the hallway is the graphics side. So, I used the white wall, the wall had lights installed. Floodlights in the ceiling that would point down to it and get illumination. Steve did the design package. But then never did build the machine. Then I believe that Steve Johnson started off doing something about a C machine. But, it was about that time the 68000 chip came out so he got off working on his old deal, working on compilers. The portable C compiler was always slow and produced bad coding. I don't know what went on. I think the idea was he made this common machine. You figure out a machine which has the operations that you find in all machines before it becomes a fairly minimal machine.

MSM: Yeah.

Condon: Then you compile for that. That generates code for the specific machine. Sort of like reducing your problem to the idea of the Turing machine and then emulating the Turing machine in your real machine. It is just going to lead to slow, bad code. But, that's his field and somebody else's feeling and I really shouldn't be commenting on it.

MSM: Well, it's interesting to how it looks, well after all, it comes back to this notion of what's reasonable?

Condon: Yes. (Laughing)

MSM: That I think there is a theme behind it that Ken talked about during lectures. During the lecture Ken talks about software that can code and write a program that will write itself. He said the B compiler was essentially written in B. The C compiler was written in C. UNIX is not written in UNIX , it's in C. And the idea I gather is to get down to the absolute minimum and wind up writing them all in assembly language emulator to get the whole thing to bootstrap itself. What struck me when I first encountered UNIX and C was that it seemed strange it should be running on a VAX-11. That's the one we are using down at Princeton. Because the whole philosophy of UNIX seems to stay out of assembler. Get a VAX handbook, look at it, magnificent structures. The assembly line which programmers dream. But how many of those calls will any C compiler ever call on these assembly language routines and solve a problem? That's what I had in mind when I asked about it. The C machine, the UNIX machine, in my sense the RISC machine.

Condon: It's not clear what RISC is. RISC is a term like artificial intelligence. It's a jargon word that tends to get used for everything. Because the VAX has three address instructions and most of the project what you call RISC now only deal with operations between two registers or three registers, and certainly not with the memory locations. Then Johnson started out with and dropped it. Then we got the young summer student Dave Dixel and the young tiger was ready to take on the world and he was going to design the computer. He worked for Steve Horn for awhile. I don't know I wasn't involved with him. But, then later he came and worked with us and worked with Ray and made the CRISP chip, all that's left has gone to SUN Microsystems. We were having a difficult time following up on the CRISP project. I don't think we found the correct team to work together. It's a single chip microprocessor with quite impressive speed. You know, technology keeps advancing such that it's outdated now. However, there is a, they do have several concepts in there and I would really do a disservice trying to remember it. The basic idea is that they have caches. First one is that they have a cache which holds it in decoded instructions. A full Ninety six or a hundred bits of micro code and the mechanism by which small loops just stay inside that cache and execute out of that cache. So that it doesn't have to decode those instructions. There's the in front of that, prefetch and decode unit. I get a kick out of it, down inside that level it looked like a 650 because part of the micro code instructions were the next micro code instructions. (Laughing) We were going at that Full width. My goodness we have seen that before! (Laughing) Then there's another cache, called the stack cache and that's what makes it a B machine if anything because of the way C uses the stack. The idea is that a certain region of the stack is kept in this cache on chip. It is a certain block.

MSM: Sam is pushing very hard.

McIlroy: If you are at all interested in the technology transfer part of this thing you can meet those people.

MSM: Thanks, Doug.

Condon: Yeah that's fine. So think of the stack as a big long piece of paper with quotations on it. There's this little window which it you can slide up and down and what's in the window is on chip memory. Most of the time you're going in up and down on the stack if the cache is big enough you just stay on chip. But then there is a set of special instructions and automatic stuff such that if you actually start down further than the window, it automatically moves down there, flushes out the stuff that's on chip and the main memory and then, VAC is always before read anyway. So, there are some special instructions there to help out on Stack management. There are variants on that whether you have two stacks, one for the user and one for Kernel space. There are some real subtle tricks that you l have to do about process swapping. System calls and process swapping. Now the advantage of this is the difficulty with most of the RISC projects which have large register sets on chip, is that as technology improves you get a finer line and you are able to put more on a chip, but you're not able to put more on chip. They can't put more registers on chip because they don't have any way to talk about it unless you change the width of the machine too. Or you're reserving for the future. Where is this concept of these caches. Just make the caches larger and then you have less transfers to off the memory.

MSM: Is there a point at which you had to think about computer design as opposed to start to think about computer design? The sorts of things you are talking about sound like the sort of thing that would go on. Whole line of Microprocessing research got started up at a certain point. Was it going on when you came over here, or was it always a part?

Condon: Yeah, it was going on here. I think that's the way you manage research. At least around here it is that you sought people and you bet on them and also if they wanted change too. Steve Horn decided that at one point learning hardware design and learning how to do the hardware to build up special purpose processor to do a special processor for C was the correct thing to do. Never finished that, but he did a good job on introducing new concepts into computer aided design. What you do to change the direction of research you want it to go into to is by the type of people you hire. Sometimes we have had announcements from the top, look more in that direction. Some people sort of pick up the change, start studying in that direction and start moving in that direction. Mainly it's what people themselves want to do.

MSM: How has this influenced your own choice? You say it's okay to catch your breath, but then stay.

Condon: Yeah, and I'm interested in hardware design and I am still interested in that kind of thing of how to put together the infrastructure and what should the infrastructure be that you have to create in order to get some hardware project done. What you need to do without having to have a hundred people on your staff. So, that you can still do it with the eye level of MTS. Only a very few support people here. Because, when you start going in those directions it's chaos out there as far as computing goes. It's like, how do I transfer my data to you. Write it on this piece of paper and kick it with a steam hammer. (Laughing) We will enter it in our computer. How should I put it on a piece of paper, this piece of paper looks like a FORTRAN coding form.

MSM: It is interesting because if I hear you right you were looking for the sort of thing in a hardware design, and a software design.

Condon: That's right.

MSM: Which is a shared environment.

Condon: That's right and I'm still trying to work on what Steve Horn started to do. I mean he had come through and he knew what to do. Behold, to expand out names was exactly like the shell. The same guys so it's that concept of thinking about how you want to set things up so that you will get the work done. Which are an important thing to do and an important thing to try and to get the younger guys to step back and do the metal level.

MSM: Okay.

Condon: Very few people do that. They get in there and do the work. There are very few that think about what is the tool you want to make in order to get it to work. They're used to doing that at the (not clear)

MSM: Certainly that is what struck me.

Condon: Even as a kid. It wasn't by my father, it was by other people. Even as a little kid I was taught, there was a guy, instrument maker, who taught me to think, you want to make a tool to do the job. So, there was one time when a data kit went bad and what it was a power supply that went out. First time in ten years or so, data kits had a power supply that went bad and they just couldn't and so now how do we change our power supply? We have gotten this new power supply and there is a bunch of guys standing around and there was no screw driver which we'd reach down in there and I said "Oh yeah, I know what to do". Went upstairs to where Max Matthews had a wood shop, took a big old file with wooden handle on the end and went over to the grinder and ground down a cold chisel point and reached in their with a hammer and whacked off the edge of the screw and boosted out the power supply. (Laughing) Gee, what a wizard Joe is. But everyone does it around here at the some level, but at getting a screw out Joe is a wizard.

MSM: This is fascinating because we're back to models of thinking and what has struck me is the software tools concept. Its seeming roots in the machine tool industry. When I asked Doug, whose paper on mass produced software was one of the papers that got me going on this question. With all this software crises around, what are these production models people are using. So, when I was talking to him about it in June I said, "what images did you have in mind." Thinking in terms of a screw cutting machine, but you have to develop the tool. And when I was thinking of mass-produced software designing tools that would allow us to turn out models of varying ways. It was a good thing, it didn't work. There is that tool making model that seems to underline dealing with humans. That it is a toolkit. What you do working on UNIX is crafting tools. It looks like the machine tool industry. One of the...

Condon: Well no, it's got to be the instrument maker. Because, the machine tool industry is also all tied up and going out and doing market surveys and seeing how big the business will be. If you do that, I don't know what happened to that file that was ground into a cold chisel, come back into the bin of files. Only used once. Removed the power supply, if you had to do the marketing survey to find out it never would have gotten done. But, we would still be standing around that cabinet taking the whole thing apart and doing it with the tools out of the stock room.

MSM: One of the interesting models from the 19th century was the growth of the American Tool Industry. How do you start off with a machine tool industry as of 1845. Each factory had its own machine shop. Design machines for their particular factory. By the end of the century you have an American machine tool industry that numbers some 500 concerns. As he investigated he found the phenomenon known as convergence and that is that the sewing machine Company came to one of these machine tool companies and said, "Well we need to drill a hole, I need to reproduce those twist drills." The machine tool industry designs a special grinding machine that grinds out twist drills. That machine company has learned how to build a generic machine tool for grinding out twist drills in various sizes which than the sewing machine people pick up, and the bicycle people pick up and so what comes out it is generic, generic product. But, then leads to rapid defusions of this particular technology. By and large it seems to be what the software industry has lacked. Some mechanism for getting generic experience, generic tools out of special solutions. The UNIX seems to be one of the areas that have succeeded.

Condon: Yeah, it's how you get rid of things too. Ask Doug, I don't know what the answer is. But, I'm sure there must have been. Every system has it. Something to bring the file on the screen. Some place or other somebody discovered that the command to catanate two files into a third file name when you left off the file names defaulted to your terminal with only one file. You didn't need the special command any longer. You threw out the old command that just listed a single file onto your terminal. (Laughing) Right now, Doug has some news item on the computer saying it is getting too thick and proposes throwing these things out. I don't recognize a one. (Laughing)

MSM: It's time to clean out the cellar, the garage. What do you use this tool for, I haven't the faintest idea. The way you described it though, I take it you still haven't got your headquarter equivalent of the UNIX environment.

Condon: No, and it has to be one of those continuing things. The manufacturing technologies that are out there keep changing what you want to do. They change their interfaces too.

MSM: Unix has never seemed to be a visually oriented system. Is that a part of the problem?

Condon: Yeah, it was a hot topic fifteen years ago. Editable graphics packages. Talked and talked and talked up the idea and nothing ever happened. There is no such thing and everything is so dependent upon the device. I really don't feel that a pen plotter, where you change the pens and what not and Sony Trinitron tube where you have to lay it down in raster scan order, fills colors and the pen plotter draws these little fine lines. Subtract away the differences between the two. (Laughing) I never believed in this and I still don't. Nobody gives papers on it any longer and I certainly don't see any commonality. What I just spoke of was just output devices, when your talking about interactive graphics type of thing. That, I don't know if anything will ever shake out.

MSM: Over here you write, the problem is finding a language to describe the process of design. So you can talk about designing language even though talking about is ultimately a two or even three- dimensional layer.

Condon: Yes.

MSM: I am surprised that Brian and Day talk about typesetting as a problem with language. They did ultimately was to devise a language to talk to others. Is it correct that engineers are searching for a language to talk about, talk about circuit design?

Condon: I think that's what we know what Sandy did was a good job and what Steve did and it has evolved and I think we're in fairly good shape of our own type of things. I see standards committees about this information go in this column and this information goes in that column. Committees that are meeting this year, it seems sort of strange to me. (Laughing) But, that's what they're trying to bang out, a standard by which it can transfer a formal standard, to transfer information format from one manufacturer to another. Because the existing ways are just absolutely terrible. The Gerber language which is pretty standard for the circuit work. Originally this machine ran with stepping motors and you could do horizontal, vertical sweeps, forty-fives only. We had this set of optical apertures and some of them you could have an incandescent arm so it was a brush you drew with. It has these wonderful commands done in its level and changed to apertures so and so. Later they got fancier and had to fill spines. It was getting pretty unwieldy because it all grew out of the original language for the stepping motors. Very interesting numerical notation where the units were thousandths of an inch. Since you are making circuit boards everything comes out in multiples of a hundred. So, naturally it's a numeric system where you could strip trailing zeros but you can't strip leading zeros. Because the biggest unit we that we could talk of was 99.99. Five nine thousands of an inch, if you talk about one inch your going to put (Laughing) Any more trailing zeros to strip than leading zeros then they have to carry that across historically and in everything else they do. That's one of the standard languages that allows you to double expose or do things together and cut away anything that was already there. Ever Gerber doesn't use the language built around that stepping motor technology. But, they don't even make their film exposures that way. Everybody wraps the film on a drum and does a raster scan conversion in the computer and then uses a little laser on a screw thread moving down to expose the film. That's the technology that's taken over some. If you want real precision, you keep the film flat rather than wrapping it on the drum. Real precision is better than a thousandth of an inch. That's a thousands of an inch film six feet on a side, that's one big raster scan conversion which they do it and lots of maps are made with that technology these days. Even when you get to the half tone shading on the map a half tone. Another graphics exchange is that all language that was used to drive a 44T raster display, or not raster but vector command language. That flattens the world, there's no structure. You're handed one of those things on the computer, the only thing you could do is plot it out and let a human being sit down and figure it out what the structure is and re-enter it. That's what that world looks like. (Laughing)

MSM: That's the one your trying to get around?

Condon: Yeah, so I essentially shipped film.

MSM: What time is it? It's one o'clock.

Condon: Yeah.

MSM: Go to lunch.

Stuart Feldman

Saturday, September 9th 1989

[...]

Feldman: They'll take care of themselves.

MSM: When did you join up with Bell Labs?

Feldman: That's actually a complicated question. I think I used to hold the record on summer jobs. My first summer job at Murray Hill was in 1965. Basically I've had either summer jobs or consulting agreements or even term time jobs. Continuously until 1973 when I got my Ph.D and decided to go to work in cellular labs.

MSM: Where did you get your Ph.D?

Feldman: MIT in 1973 applied mathematics, theories of galaxies. Essentially no computing in the thesis, computing is a side interest.

MSM: When you worked for Bell Labs summers, was it computing jobs?

Feldman: All my jobs were in Center 127 and its various incarnations.

MSM: How did you get there in the first place in '65? You were only a sophomore?

Feldman: Well, actually it was much weirder than that. The connection actually came through Stan Brown, who was at that point a department head in mathematics and later in computing when that formed. He came in to a careers day at a prep school I was attending at the time and so the connection was made. So I just visited and sort of go on what's called a industrial lab type visit. I liked a lot they invited me to come back. They tried offering me a job the first time and that didn't work, because of child labor laws. (Pause) When I turned sixteen, they were able to hire me. That was the end of my freshman year at Princeton.

MSM: Where had you learned computing? You obviously knew it then.

Feldman: I probably represent the first generation of computer brat. I took my first computer course when I was either eleven or twelve. There was a NSF sponsored program at Columbia University for high school kids basically called the Science Honors Program which for curious reasons I ended up applying for. I was in eighth grade and taking a summer course and I just decided I love computers. I dropped chemistry, which was my previous scientific interest. I took a bunch of computer courses and sort of wondered around there weren't actually computers to play with in those days.

MSM: You did this. You loved them. You did this during your summers.

Feldman: This is when I was in the eighth grade.

MSM: In the eighth grade? But you didn't concentrate in it in college or grad school?

Feldman: No, I got a respectable degree instead- in the real science astrophysics at the time. I spent a lot of time at the comp center. Most of computing I learned was basically learned informally in the gutter. Ah Three AM at the comp center at Princeton was a wonderful place to talk to people and I just did that a lot computer nerd, if you wish. I did a lot of programming in computing associated with academic courses. But there really wasn't much of a computer science curriculum available. I think I took one other graduate course at Princeton that was computer related. I happen to been taught by my first Bell Labs mentor Jay Goldstein. A wonderful man. I guess the only other computer related course I took was one graduate seminar in automata

MSM: Hopcroft?

Feldman: No, this is at MIT. Papert and Minsky. It was an amusing course.

MSM: Was this Minsky's course on which the book on automata, finite and infinite

Feldman: No. This was actually a graduate seminar relating to perceptions at the time. Their book was just coming out. It was an amusing course because it could be summarized as Seymour Papert would come in with a new false theorem each Monday night. The purpose of the course was to fix it or place it. I don't know if this is pedagogic device or simply ill-founded speculation. But, it was interesting, but not my sort of thing. I am a programmer at heart. Rather than a theorist. Other than that, the only academic background that I have in computing is that I taught computer science courses at Berkeley and Princeton.

MSM: Did the computing scene at MIT attract you at all?

Feldman: Only a bit I actually had a moderate amount of knowledge about that part of that scene, because I had actually worked on the Multics project. When Bell Labs was part of it.

MSM: You had worked on one of them?

Feldman: When I was an undergraduate a bit more weird personal history. I believe I had the first time sharing terminal at Princeton installed by Bell Labs for my use.

MSM: You had it. That's marvelous.

Feldman: It was installed during my junior year. They installed one at the computing center I used. Basically they did it because the comp center didn't have any time sharing access of its own at that point. I was actually using Project MAC at MIT. They had to drop a tie line to Princeton. The tie line and the computer cost far more than I did. I seem to remember I was paid three dollars an hour. Ah They put it in the comp center partly to keep the comp center happy and partly because of, I believe, private worries that I might just drop out from computer woes. There was actually no danger of that, and I graduated perfectly expectedly in astrophysics. By senior year, they allowed me to move into my dorm room.

MSM: Now what were you doing on Multics?

Feldman: I was actually specifying part of the I/O system a weird thing for an undergraduate to be doing. I learned an awful lot about systems and systems ideas, by doing it all of a sudden. I had absolutely no basis for it, but of course neither did anyone else in the world, so that was fair. The stuff I did I don't think it ended up in the final version, but it was actually in the intermediate versions. I was involved in a large number of discussions on the I/O system.

MSM: So, you already

Feldman: So I already knew a fair number of people at Tech Square. Separately I was also the project I worked on when I was a grad student, and for which I was originally brought in, was algebraic manipulation. The work that Stan Brown had concentrated on. The ALTRAN project. I actually wrote the first math and execution library for that. And therefore, we had a lot of discussions and so forth with Joel Moses and friends at Tech Square.

MSM: Working on MACSYMA?

Feldman: Yeah, he's the author of MACSYMA. Therefore, I had also had those random personal connections. So, I knew a little bit (Pause) more of what was going on. But I was never actually interested in the LISP or depacker school anyway. I did a bit of LISP programming as part of a course. But I never really spent a serious amount of time on that as a grad student. I actually spent most of my academic time worrying about galaxies. (Pause) This history means that I have a sampling of what was going on at Bell Labs starting in the mid sixties. But, this is a view of a non-career student who was sort of like a bad penny keeps showing up Notices what's going on but doesn't necessarily know flows. Any of the politics, that sort of thing is that they don't effect non- permanent people.

MSM: No, but

Feldman: I was also too green to know to notice if there was a fight going on.

MSM: But you must have been sensitive to change - to malignant changed atmospheres.

Feldman: That I could probably tell you about. I was just putting in this disclaimer that you are getting the twenty-year old memory of someone who wasn't watching very carefully.

MSM: I'm also getting the memory of someone who came in at quantum intervals, and might even be more sensitive to changes than people who were there.

Feldman: Yeah, I would show up at Christmas and for the summer to complete... plus odd days talking to friends. So therefore I warn you that I am not the best witness. I may have longer tenure than many people involved. But I wasn't hardcore.

MSM: What was happening toward the late sixties?

Feldman: Well Multics had clearly folded. Multics was a brilliant project. It had some wonderful ideas. It's almost time to bring them back. Many of them have reappeared. But as a corporate investment per se, it was a disaster in that it did not provide the service that was promised. Various people who thought they were going to be able to use it, of course didn't. The fundamental problem was that Multics was too ambitious for the hardware, and to some extent the software technology of the Multics era. Multics simply cannot run satisfactorily on a fraction of a MIPS computer. And that's what the hardware we were going to be using was. Um So therefore, that had tailed off many of the real Multics people had actually dispersed. Ah It's something I only noticed a little later when I look back. It was probably obvious to the people who had been involved. But again, career moves are not the sort thing I noticed anything about. Ah two people who had been extremely peripheral to Multics, who are Kent Thompson and Dennis Ritchie. Kent had been involved, I think, in doing some of the I/O stuff. You know he implemented one of the first working printer confines. Dennis had been interested in some of the compiler stuff, but I don't think he had done anything at that point. They were sort of around, caught up in the maelstrom. They were real interested in computers. There was also a sort of move to start doing something else using operating systems, and to get a good system. There were a bunch of requests for I seem to remember a long set of arguments, and I can't place the time at all. It may have been after I had gotten there, but I'm not certain. __ versus a PDP, maybe a ten or eleven, and I don't remember

MSM: At first they wanted a PDP-10 on a sigma seven.

Feldman: Okay, thank you, that's the discussion I am incorrectly remembering. And this was basically, 'Let's get back into this business and do something interesting' And just for us no promises of providing comp center service, or a bit of organizational confusion that the computer center originally was part of127, from where it came from. And then it was split and put into area 88. At the time, I think 82 was its number. But, our director, Sam Morgan, another prince, by the way, was given the unenviable job of wearing two hats. And the Multics support group was going to be somehow part of that whole deal, I believe, and the original plan and by the time it was split, basically the Multics machine was being run gelded, as GECOS machines. Providing perfectly usable, utterly uninteresting service. Now there's an awful lot of cute things that the computer science research group did on that machine that made it a very interesting environment. But as a operating system environment it was vanilla. How so, it would be a major digression to go on to other great things that were done. So that machine was running, so there was service available. But there was nothing adventurous, there was nothing interesting

MSM: Well, you'd lost control of the computers

Feldman: And also, as you're quite right, it wasn't ours. It was the nice service of actually running things which let no one say bad things about (it). I, too, may have used one of these computers. However so, I was actually running cheerfully on GECOS when I started working there, for example, because I actually had some things that I wanted to be working on.

MSM: Now what were you doing at that time?

Feldman: When I first started I guess I continued my ALTRAN efforts and basically I wandered around for a number of years doing a little bit this and doing a little bit of that with no particular direction or major reward or hassle looking for different things to work on.

MSM: This was starting

Feldman: Starting '73. I started full-time in September '73.

MSM: Let me back up you a little bit. During the time that Ken and Dennis were putting together this new operating system they were playing with how conscious were you of that?

Feldman: Certainly I knew about it. It wasn't (not clear) lunchtime conversations had a lot of this stuff in it. It is an important socialization thing you should know about probably relevant to your discussions. There were, and until recently, still continued to be, two lunch groups in the computer group. There was the eleven fifteen and there was the one o'clock.

MSM: And I've interviewed both of them. (Laughs)

Feldman: A remarkable continuing grouping basically the one o'clock tended to be the systems group. That was the latest you could eat in the dinning room. And that was driven by the fact that for half the people in the group it was breakfast because they showed up at eleven or twelve fifty-five. And then there's the other lunch, which was, you know, people who actually started work at more classic times like eight and nine, and that bunch tended to be starting around eleven fifteen, and the tables would be begin to filling at eleven thirty.

MSM: Largely theoretical

Feldman: No, that was the everybody lunch. That was the default lunch. But there was nothing exclusive about these. If you showed somewhere between eleven fifteen and eleven thirty at a particular table in the cafeteria, you knew that's where the computer people would be. And if you lined up for lunch at twelve fifty or so, they would wait until a large group to form so they could build the right tables for us. I think we were not a trivial part of their income. Then you were in that lunch group. This was in no way selective, no way exclusionary. It was just that certain people almost always went to one or the other, perhaps based more on stomach grumblings than on scientific segment. If you went to the later one, you were likely to be in the middle of all kinds of weird discussions. Then of course there were just the informal ones at lunch today. 'Like what's going on?' I remember some fascinating speculations about Ken Thompson in the late sixties about the right way to build a time-sharing system instead of the way Multics was. These observations had nothing to do with the way UNIX worked, either. They were based on some absolutely clever observations about how to drive a machine that had a wonderful drum. (Pause) So therefore I was vaguely aware of all this stuff, but only peripherally and during its early period. I actually saw Space War being played in the closet, for example which is the real war UNIX.

MSM: You mean this Space Wars when they had Space Wars up on that seven, they also used UNIX too?

Feldman: Well, that is where Ken got sick and tired of not having UNIX.

MSM: I see. Trying to bring Space Wars up.

Feldman: Well, he was writing Space Wars and he got sick and tired of having no support. So, he built a few things. That is, I believe, the origin where UNIX came from. Because he built a few things, and they looked kind of reasonable and then a real computer was gotten. It was the PP-9 originally.

MSM: Well, where did this concern for the file system come from? Was that a topic of discussion?

Feldman: Well, remember the file systems were not an original idea. (Pause) Even just forget the fact they're in the literature, for the moment. But just current experience, Project MAC had a rather weird, not really tree-structured, two deep file system. For every name also had a two complement identifier. Multics had a very complex file system, which went the opposite end from this, and had a very messy directory structure in which you could represent a remarkable number of important things in the directory structure. Very complicated access control, very complicated linking control. The ability to close a fault the first time your file was accessed. All kinds of wonderful things. All this list of wonderful things caused the system to sink into the mud. Of course everything costs programming effort, and everything requires you to program around it. Everything takes cycles. Many of these ideas have reappeared in other forms. So, in some sense UNIX, the UNIX file system was the reaction to both of these, if you look at it. It had the flexibility. It had the essential tree flexibility of Multics. But a real dirty idea for implementation, which was to say that the file space was flat and then there was a simple name conversion above it, and if the directory structure had nothing in it. The directory structure consisted of, 'here's a name and here's a file number.' Whereas the file structure for Multics, if memory is correct, was probably a full page. The PL/1 structured declaration.

MSM: Right.

Feldman: And of course, there was zero, but this a full general multi deep, and it even had a weak link mechanism with a nice cheap idea of a hard links. Which falls out of the implementation, of course. But, it's in some sense a reaction to the annoyance and weight of dealing with Multics type things. Whereas the full recognition that two deep isn't enough. Anybody who built a project on Project MAC, quickly found out that they were losing track of things, because they didn't have an easy way to have multiple directories. So, I don't remember any discussion, it just happened between visits, more or less

MSM: Okay. So, you joined in '73, looked around for project

Feldman: Things that were interesting to work on that sort of came by.

MSM: Was there any sense of direction with the group at that point?

Feldman: No. As always, it was a highly fractionated group. They were people doing things. So, there were a few of us still working on ALTRAN at that point there were interests in just getting there was a numerical analysis group that was heavily FORTRAN, and still is heavily FORTRAN-oriented. I had a lot of friends there, because I'm actually interested in science and scientific computation, going back to my other interests. Also, I was never a numerical analyst, but I actually did several times in my career, do numerical computations for which I wanted the answers some of them while I was an undergraduate at Princeton. Also, of course, as a graduate student. And there was a theoretical group of a few people who tended not to be interested ever in programming if they could help it. Unfair statement, but that was sort of an appearance. Then there were the people who like making machines do things. There was no top-level management direction that I could see that said: 'Alright, you eighteen guys are to do this.' First of all, overall the group was small. It was actually, I believe, under some significant management pressure to shrink or die or something after Multics left such a bad aura. I have no idea of how the managers managed to keep things on an even keel. That they did is amazing, and of course extremely lucky. That is the sort of thing that I didn't notice anything about. I was one of the last hires for many years. There was basically a hole in hiring as Bell Labs went through a bad patch, involving ABM and such. And also, computer science was not actually in good aroma. But there was no Various managers subtly and unsubtly would suggest you ought to do something interesting and would point to interesting projects. I would look at them and decide whether I cared or not. But nobody said, 'it's your job to work with so and so', perhaps they ought to have - they didn't - luckily, from my point of view

MSM: They claim it's part of the ethos that you don't do that sort of thing, you let people strike their own

Feldman: So, I did a bunch of weird and random things (Phone rings) And some of them I did on GECOS. Then there was this other stuff coming by, which looked like a more fun environment to work in. So, I asked if I could get a login.

MSM: Namely UNIX?

Feldman: Yep. And UNIX was sort of a service at that point. Not a real public service, but you could get access if you asked.

MSM: And this was the research?

Feldman: Yeah. This was running on the 1120, I think, when I joined it. Which meant, of course, you had to be not interested in having a lot of file space, since it didn't have any. It was a five or ten meg disk, among other things, and so forth. We've gone through that size three or four times in my life time already. Some things just never change. But I just started using it because it seemed a nice place to work. I had gotten used to using things like run-off and QED, back on Project MAC days, so I wasn't used to editors and typesetting. My handwriting's illegible. So, I've always wanted things that proofed things. And my typing's error filled, so a fast but high error rate. So, nobody could benefit more than I from the advent of editors and text formatters. So, I've become sort of addicted and dependent as an graduate already to their use. So, it's natural to follow the evolution, as those things became available, courtesy of Osanna and McIlroy, I guess, on UNIX. So, I sort of wandered on to there. And, of course, you've got a lot better service and you didn't have to beg for money, because it was our own machine. So, when I did some other projects, I did it there.

MSM: I see. (Pause) When did you start to make your own contributions to it?

Feldman: Well, I never really wanted to make my own contributions to it. It was just sort of, you did things and they worked and they appeared. This was a completely open environment. You told the people you've done something, and they were either interested or they weren't. You just sent mail to people or talked in the hallways. So, my probably most interesting thing is a little program called make.

MSM: Have you used it?

Feldman: The history of that is very straightforward. I was actually at one point I can look it up in memos, but I assume around '75. I was helping out a guy in materials science, I believe. They were having some problems. There was a lunch time discussion about how it was impossible to use this computer program which took forever to run on a time-sharing system in Holmdel. And it was written in PL/1, and it didn't run very well, and it gave bad answers and it gave them slowly. And I, based on no information and just sort of pure lack of humility or something, said: 'I'll rewrite it for you in the next day or two. Where is it?' And, you know, the bad news is they sent me a copy.

MSM: (Laughs)

Feldman: Okay. It was a 750 line PL/1 program. It was one of the worst programs I had ever at that time seen. It had examples of all the worst programming style you could have. But, I translated it into Ratfor through great pain. I was actually the first getting Ratfor, among other things I had done.

MSM: For your own computing purposes?

Feldman: Yeah, and then I took a look at the algorithm being used and my jaw dropped. It wasn't surprising the thing didn't work. It shouldn't have.

MSM: (Laughing) There are structural reasons for failure.

Feldman: It was using one of the least plausible ways of minimizing a function onto MAT. Take three values out of a hat and see which one you like. (Laughs) That's not the best root finder you might encounter. So, anyway I ended up getting sucked into writing a program which could actually be used for (calibration). This was beta ray stack scatter, a technique for measuring the thickness of films. They would do a calibration in the morning. This was not a theoretical device. This was something they used at Western Electric. But and Bell Labs people were trying to make it work right. Anyway I ended up providing computer support for it, because I was one of the few people around who knew enough vague physics and enough vague mathematics and enough vague computer science, and it was at loose ends anyway. So, I found myself actually writing a three thousand or four thousand line Ratfor program. This was not a heroic project we're discussing. However, it was tricky and there were various things that kept going wrong. So, I was actually banging away for a number of months. I found myself in a standard situation when I would go home for dinner at six or so. I would simply do an rc. no __. In other words, recompile the whole world in the background, shut up, and then drive home. It would take through the drive home and through dinner for anything to happen. But this is because I kept making the classic error of debugging a correct program because you'd forget to compile the change. And, this is getting annoying. Then one day Steve Johnson came storming into my office in his usual way. This wasn't the big trip, he's going to take you all over, saying basically: 'Goddamn it, I just spent the whole morning debugging a correct program, again. Why doesn't anybody do something like this' and we would be talking about dependency and __ in another context. I said, 'Yeah, I think I might do that too.' Then I sort of just did it. He pushed me over the edge over something I was sort of subliminally annoyed about, that I kept making this error. I ought to do something about it and this meant recompiling everything, every evening. Although, on our case strategy didn't save you a bunch of time, when you've already made the same error. So, he's coming in storming about that I started writing on the board: How about if it looked like this? I had an absolutely abysmal idea. He said, 'no, it needs more details. Thank God most of those disappeared. One of the reasons make was so simple was that It was only supposed to solve my problem, and help Steve too. So, I did it. I found it very useful for my little problem. But, very rapidly, I found myself adding junk. After a week or two, I rewrote the entire thing after an idea that I would include macros. I'd occasionally give a lecture on the origins of make one of the things I __ is that I woke up at three in the morning, saying macros, got out of bed, turn on a terminal and did it. And if I'd only gone to bed before, I might have done it better (phone rings) It's got the worst network processor known to man (phone rings). It suffered for a decade for my stupidity. But anyway, so I did it. I remember giving a computer science show and tell on it, you know, one of the obligatory things Other people started using it. And since everybody has the same problem, it took off. I added bells and whistles and fixes as various people came by. Dot __ got added specifically after Ken Thompson wiped out a very complicated link structure by accident, and he asked for it. I said: 'That seems ugly. I'll put it down anyway.' Obviously I was going to oblige Ken, an old friend.

MSM: How long did you own it? In that sense of having to support it?

Feldman: Forever. One thing that basically the people who wrote things owned them pretty much. So, make was just mine. Since it's a fairly small program, there was no big deal. Various versions of make got done by other people, starting maybe a decade later. Or maybe six or seven years later. make itself, I guess, is around 1976, give or take one... The paper is in the late '70's, but that was a very good thing that I published the paper - it's a heavily referenced paper. It came about because somebody said, 'Would you be interested in publishing this report as a paper in S, P and E?' I'm rambling on

MSM: No you're not.

Feldman: This is purely I'll tell you one or two simple stories about it to give you an idea of the environment. After a few months of its being used locally it spread around to other UNIX systems. UNIX was already in use lightly throughout the company. Somebody came up from the first floor support group; they decided to try using make to support their system releases. And somebody came into my office saying, 'I'm having trouble with this make file.' And they dropped this 1500 page make file on my desk, you know a thirty page listing. My jaw dropped. I said, 'Goddamned it works on that.' Of course, I'd never used a make file longer than about 15 to 100 lines. It was never a designed to do anything

MSM: So, you never had, like, a source control system in mind?

Feldman: No, I'd never planned it for maintaining UNIX. And what they had was _, which is the worst case, of course, but it just rattled on and on and on and my second thought was that I was glad I had a symbol table, which I had done only out of pride of craftsmanship, since there was no need to It's embarrassing to not have a hatchet symbol table and just do a linear search. Pure guild rules, that it's just creepy to do it that way if you might ever want a big one. But I never really pictured somebody coming in with a symbol table with a thousand items. Pure example of the tool took off and because it took off so fast, I never went back and fixed many of the design errors because I didn't want to screw up my fifteen person user community.

MSM: Your reference to guild rules interests me. Here you take up

Feldman: Obviously I'm baiting an historian.

MSM: It's that guild that I'm finding most interesting in the course of these conversations, because it struck me right from the beginning when I first encountered UNIX several years ago. What you have here is a system that on the one hand contains some really clever and ingenious coding a certain hacker quality to it. On the other hand, if it's not theory-driven, at least as theory sensed, and as the works quite evidently in some cases have been working out. Some fairly fundamental and profound and theoretical ideas.

Feldman: Oh yes.

MSM: And that's a rare combination in computing.

Feldman: The glory of the system is, people wanted cleanliness and simplicity. Can ___, and it was their ability to say 'no', or 'that's wrong' that causes the system to be what it is in the early days and disappeared when it turned out not to be useful. The Einstein line of everything should be as simple as possible, but no simpler. It was probably a guiding implicit rule. You alluded in passing to a custom in the UNIX room of the last person that touches it, owns it.

MSM: Yeah.

Feldman: make was the one I sort of kept, because I was sort of fond of it anyway, and people would just come to me to fix it anyway. Whereas the mailer kept moving around because nobody liked it. Every time a new person

MSM: That was the hot potato.

Feldman: Every time somebody would join the group, they would say mail doesn't work right, and, 'I'm going to fix it', and everyone would say 'good.' Especially the current person who had the tar baby. No one has ever been happy with the mailer before. This is a fact. This is a matter of twenty year's history. The guild rules, that was sort of we ought to do things right. A linear search list, which is one of the things UNIX gloried in for decades. The directory structures were linear and all that. make was clearly doing a compiler-type activity internally. And therefore, it ought to do certain compiler-type data structures. And therefore, before I sent it out, I ripped out the linear searches I was using, and I put in the extra ten lines to ___ as if dumb hashing takes a lot of smarts. Also, hashes was one of the first things people knew about the first major hashing paper came to Bell Labs, as it turns out, but

MSM: Were you conscious of its being a sort of Bell Labs way of doing things? Were you sensitive to a contrast with what the guild rules were at Murray Hill, as opposed to everywhere else in the world?

Feldman: No. Let me there are several answers I should give there. First, I was not terribly well traveled at the time, as were the scientists, as well, in the CS community. So all the computing I really knew, I picked up in the gutters at Murray Hill. And therefore, I represent one of the flowers of that particular culture. I've attempted to look around a lot later. At that time, much of that I picked up. But, this is also not just a computing atmosphere, but the scientific atmosphere of Bell Labs. This is sort of the tail end of the golden age that people think about. Of course, it's always the golden age if it gets old enough the relatively free environment and all that good stuff. But I really had picked that up. I'd had the amazing opportunity, because I started basically the end of my freshman year at Bell Labs to be able to compare several institutions of magnificent renown. Murray Hill, Princeton, Cambridge and I didn't see that Murray Hill came in third in quality of staff or in quality of atmosphere. I'd had dealings with Princeton, with the math department and the astrophysics department and the computing center. Since I'd spent as much time as possible in each of them. So, it was an interesting atmosphere. The guild rules are just sort of you ought to do things right, and if you're writing a computer science program you ought to write it that way. I just sort of said, 'Aw shucks, maybe if someone will ever want the symbol to get big and having everything take quadratic time in the main loop is going to be embarrassing. So, maybe I'll hash it.'

MSM: You talk about obligatory show and tell. What were the show and tells like?

Feldman: Well, they were obligatory. They were simply scheduled alphabetically, manually. A carried-over tradition from the math center, I believe.

MSM: That at least once a year, you had to have something interesting to show people

Feldman: Yeah. Well no, you had to give a talk anyway.

MSM: (Laughing) Well, your expectation was that it would be interesting

Feldman: The purpose was to increase communication, and also to make sure everybody did talk about something. It was the manager's responsibility to make sure you were doing something at all, but the assumption was The original intention was that they were to be three, easy, unprepared people __. And sometimes you could just use them for random discussions, so I scheduled shortly after I did make, so I just talked about it. I remember using another session, probably did me no good managerially, but it was technically helpful. Say I'm stumped on how to do I/O and the EFL language anybody got any ideas? more or less any suggestions how to go about it? Attendance was widely variable. Some speakers always got a high attendance, Mike Lesk, for example, always gave wonderful talks to people who'd attend anyway, whether or not they were sure what Mike was up to. Other groups would be attending more coteries; when the theorist talked, typically the audience was mostly theorists plus the people who always go to talks anyway. When the analyst talked, usually only the NA type people plus me would show up. However, it was completely variable just on Tuesdays at two, I guess, and you just show up. They ranged anywhere from dull presentations to highly combative slinging matches. I'm afraid our center picked up a reputation for knifing speakers in the back. At one point Sam Morgan actually called us together and basically said we had to be nicer to people.

MSM: In the back row it was just that you were combative

Feldman: Oh, no, no. In the front also. It wasn't we didn't assault after they left. We assaulted them while they were talking. Wrong idiom.

MSM: No. I'm just associated with two colloquiums at Princeton, one the Davis Center colloquium, which is the historical research seminar and then the program in the history of science. Grad students have this reputation for raking speakers over the coals, both groups. If you really want your work exposed, you come and present it to those groups and hope you come out with something.

Feldman: Well, we got a reputation for being too rough red flag for excessive roughness. I remember Sam Morgan actually in a center meeting actually saying we had to do something about this. But you know my style happens to be like that, so I was perfectly happy. (Pause) So, there's obvious care. You didn't hit a summer student over the head. (Pause) Women, children, infants don't get assaulted. But, through the club it was fair game to argue, and argue back of course.

MSM: Yeah.

Feldman: Interesting affairs. And arguments would continue.

MSM: make was your major

Feldman: That's probably the smallest thing I ever did, but probably the best thing I'm known for. Similarly, I ended up doing a FORTRAN compiler and I did EFL. Each one of them looked sort of accidentally interesting and they took a lot longer than I'd hoped. I had fair amount of FORTRAN expertise. I can dream in FORTRAN. I was handed a copy of the FORTRAN draft standard, and was utterly and completely appalled by it, and wrote a since we printed __ on the first draft which caused me to end up being consultant the FORTRAN standard committee. I ended up it started to be super Ratfor, and I took it over and it's the first compiling thing I'd ever done. Internally, it's a real mess. It's actually got some slick and cute things, which have actually come back to haunt me, recently even. And then, since at this point I was sort of the complete FORTRAN-er. When it was decided to do the UNIX port, there were two justifications being used for buying a machine other than the 1170. One to actually port UNIX and to actually have UNIX service on another machine. UNIX was looking important corporately, and also it looked like an interesting problem; separately, the machine was supposed to provide service to the NA people. It was observed that that was fine, except that the fc was an interpreter that didn't forward and had no use outside of the PDP/11 and it wasn't very fast enough to use anyway and we needed a FORTRAN compiler. I said, 'Oh, I'll write one.' FORTRAN 77 as a language was just being codified and I wrote, I believe, the first full scale compiler.

MSM: For f77

Feldman: Yes. f77 is there's an argument about who wrote the one just before. I believe mine was the first truly complete one. I've never looked at the date; I've received a couple of letters. It was written to be portable first version. Ran on (Pause) I think on the interdata, and then it took me a month to port it back to the 11, then it took four or five days to put it up on the nascent VAX. So, for that reason, I have to be one of the first ten login ID's on the VAX? This is relevant because for a while I had a login on every UNIX VAX in the world. Because, it came distributed with the first ten user ID's, and I have to be number nine.

MSM: I see.

Feldman: And most people forgot to clean out their login files. The good old innocent days.

MSM: (Laughing) So, FORTRAN has always been part of you?

Feldman: Well, when it was needed, Ken put together fcvery early just because somebody had a FORTRAN program.

MSM: Every system had to have it?

Feldman: FORTRAN was sort of the standard language. That's part of life. UNIX has done more than anything else in the world to quash that attitude that FORTRAN is the standard language. Now, if you ask somebody, 'what language are you going to write this in? for almost any of this, C is the default answer all over the world. C can be viewed as the FORTRAN of the 70's. In 1965, the standard answer would be FORTRAN. Very recently, based on my compiler, a converter from FORTRAN to C was finally written. Partly supervised by me, partly supervised by David Gay. A rather weird inter-corporate project.

MSM: Well, I was engaged at Holmdel on a project that AT&T was not successful in. It was AWIPS, advance weather interactive processing system. Part of my job was to look into software development environments. Part of the concern facing this was that the government contractor called for roughly 1.2 million lines of government furnished code, and what we gathered was about seven different versions of FORTRAN seven different machines. A simple requirement was functional equivalence. Part of the thing we were facing if we got the contracts how are we going to unpack all of that FORTRAN?

Feldman: Well, actually that wasn't quite as bad a job as you thought, because FORTRAN had been partly standardized by the efforts of ___. A young man, Andy Hall, was around, and got hooked on that one, you now, early incarnation.

MSM: (Expresses agreement)

Feldman: So FORTRAN, which is a completely disreputable language, with all the negative attributes you might ask, redolent of the Victorian era. It Is part of my bones also, so alas there. How I just happen to you know, a number of these projects more or less happened due to lunchtime conversation, as you'll notice. Similarly, I agreed to do f77, but I said I wasn't going to touch the I/O library, which I knew was going to be too awful, and it would be too hard and Peter Weinberger, who was not a part of o27 at that moment, who will transfer a little later said he'd do that, and the treaty was signed over a french fry, more or less.

MSM: (Laughing)

Feldman: He kept his bargain, I kept mine. Every so often we'd have a discussion.

[Side B]

MSM: What thin line is between collaboration and trying to help the people you want to help? So, where were we?

Feldman: We were discussing FORTRAN, I guess, and how these things sort of happen through informal treaties. (Pause) Management was not deeply involved. I think Elliot _'s the only one who suggested someone go write a FORTRAN compiler, but no one had actually thought or suggested that I should be telling you how to do it, which sort of struck me as an interesting challenge. I did everything else in FORTRAN, so I did it and the compiler was a lousy compiler. But, it's also still in use after a decade. It's part of UNIX and you have to pay money for the other ones, and it's essentially correct. Little bugs are found only now and then, but nothing drastic.

MSM: How long were you there, a part of 127?

Feldman: Until divestiture. I was never in any other organization, not counting the fact that the number changed underfoot a bit. I moved around from department to department at management whim. But I was always an odd ball. I was peripheral to everything, so I remember one day I was called in and was told that I was being reassigned instantly because of someone else's problem.

MSM: You mean someone else's problem

Feldman: Sandy Fraser had just been promoted, and Steve Bourne, who was Denny's brother-in-law or something, was going to report to him and that wasn't admittedly any good. So, he had gotten rid of me and I was the exchange piece.

MSM: (Laughing)

Feldman: Approximately I believe there was more intelligence underlying it, Sandy Fraser was my department head for several years. Since my interests tended to be weird and various, and I wandered around

MSM: Is there a pattern to those interests as you look back? Has there been a theme?

Feldman: If there's one theme in everything I've been interested in it's been glue. Everything I've done has been pasting over errors of other people and connecting up tools. So, make is a way of getting around the fact that the command structure didn't doesn't solve the problem of keeping track of what you're doing. And make is a much better way than shell files, even if you aren't doing most things, even if you aren't interested in it's concurrency updating issues. EFL was a way of making FORTRAN look like C. f77 was possible because I could steal the code generator from the C compiler. I'd get portability that way. So, I was actually one of the early people to ride the portability wave of C. But, I was basically gluing the FORTRAN world onto the UNIX. FORTRAN had been used on UNIX, but it had never been sort of inherent. I put it in the way you could mix FORTRAN and C. That was actually one of my underlying goals to make everything look portable and clean. And many of the things I've done have been in this way of bridging the two different worlds with hacking in between, as I like programming.

MSM: (Expresses agreement)

Feldman: So, that's probably the if I have to say there's a strand to the technical things that I've done and that I'm interested in now, it's that of how do you use one technology to get you out of the trouble of another one? (Pause) And I've been quoted more than once on the line that one of the great things about UNIX is that it lets you get out of the trouble s it puts you into.

MSM: Well, you can fix it yourself.

Feldman: Yes. Precisely and granted, many of the bugs problems you got into could have been fixed by a system that was smarter. But, on a system that was smarter, if you'd gotten into a similar problem, you couldn't have gotten out of it. So, make was possible, because you could ask the file system a dumb question, and it would answer, and if you wanted to run a command, you would just run a command. You didn't have to plan it in advance, you didn't have to allocate anything, you didn't have to get Gods permission you just did the damn thing. Therefore, I just put it together without thinking. (Tape skips) So, if you would observe. Still, you could write a compiler without telling people that I was going to write the official initial FORTRAN compiler for UNIX

MSM: You just wrote it?

Feldman: Yeah. I just wrote it. I got stuck with it.

MSM: Did the mood change at all once the USG got started and the thing began to become a standard for the company?

Feldman: At this point I should be very careful. The ___ was generally summarized around the Thanksgiving animal. From our point of view, you know, the lords on the hill, we never quite saw what they were doing or why. And therefore, these answers are appallingly unfair, and so forth, and I should be careful about insulting the former employer. But somehow, we never saw anything good coming out of it.

MSM: Yeah, he understands that. (Laughing) Good luck at it __?

Feldman: So and therefore, it wasn't relevant to anything. We did things and eventually they picked them up because they were there.

MSM: So you guys just continued to build the system you wanted?

Feldman: Yeah. During the period you're talking about USG started off in the mid-70's and so they would answer phone calls and things, and that was good, because you can only answer the phones 24 hours a day. (Pause) But, as an influence on what was really going on rather than a retarding force, I don't think there was any real attitude. We didn't expect good things per se to come out of them. We just hoped they would be helpful. Again, this is completely unfair and out of school, as it were, and I had no administrative interests. I had no idea who was fighting whom for what turf, or what the corporate benefits were and all that. I only saw a small number of people that I cared about. And indeed there were some okay people in the group. There were turkeys, not a uniform appellation, it was just sort of a general assumption. The full bureaucratization of UNIX didn't happen until the '80's. At that point things were that was getting stiff. Of course, I left at the time divestiture, at which point things were getting much stickier. The ABI and ADDIS were being set up in the early eighties, and there were enough troubles there. The FORTRAN saga I have my files somewhere; a long list of attempts to get FORTRAN transferred out my hair to USG and so forth. The only way I ever got rid fully of FORTRAN was leaving the company. The first time I got rid of it half-way was leaving for a year at Berkeley.

MSM: UNIX is a way of (Tape skips) computing. It's a view of what computing is about and how (Tape skips) It includes certain things, but it also excludes certain views. What does UNIX exclude? Or do you miss anything about, or did you miss anything about?

Feldman: Well, UNIX is a sparsely furnished or spartanly furnished home. It lacks all the plush conveniences of professional operating systems. The bad news is that over the years, it has picked up much of the plushness and the lousy handling switch metaphors. It was I'm not a car expert, but it was sort of the MG of operating systems in the early days. It had just enough to get you from here to there. It was fun to play with. It didn't have the handling of a Buick or a Cadillac , nor did it have the performance of a Ferrari. It was fun. And if you wanted to do something, you did it. This openness went, however, with the fact that things were going to change under your feet. More than once, the C compiler died with me as its only user at two in the morning, because Dennis is a late night person also. And at one thirty, he might install a small bug. He was actually extremely good at this. More than once, I was the first person to be hit. And the good answer was that at two thirty, it would be fixed. That's sort of the UNIX ethic. We were living in a high-risk, fun, changing place. That hasn't been true, of course, for a decade, since it became an official product, and a major force in the universe. With all the problems of annual releases and two year bug recycles. The technical things that were missing all of the closed system properties that you got out of let's say MAC LISP assuming you wanted to be a list programmer. Like good, you got all kinds of weird services. UNIX has gotten by with the world's dumbest loader and pretty offensive debuggers because nobody was going to build anything intrinsic. I'm talking about sort of my neck of the woods, which is compilers, programming languages, environments. Ditto the image what makes the system universal is that the bytes dream and the simple file system [...] of what it works on. It's not so easy to make this thing work beautifully in a Window environment. It's been done remarkably well. Pipes just aren't simple un-typed byte streams aren't the right unit. Ditto, the file is not the perfect object. The Multics file system, in some ways, is much better at representing objects, because of its possibility of having invisible objects, and the possibility of having information associated with them. So, from my weird historic view I view some of those ideas poking back through objects. I suspect the small talk people will disagree completely, but I know [...]

MSM: It's an interesting observation, because the _ came around to show us their machine last year and they were talking about, this was UNIX with a friendly face, easy to use. And I said, well, UNIX to me means pipes and macros. Are you telling me that you can pile icons on top of one another and make macros ___? Oh, no, no, no we don't have _. They said, but you can open a command window and type a line. I said, well, I can do that in DOS.

Feldman: Yep. So, basically there's a simple attitude that you could get superposition, you could get connectivity, and so long as you're willing to operate at a relatively dumb level of characters and lines, things work beautifully. Bitmaps and stuff would have been a hard battle to make first class citizens, because they're not part of the world view. And you can't be everything.

MSM: Never.

Feldman: But if your view of the world is that you have a teletype and a computer and a disk, UNIX is a superb fit to that world. And it turns out that that isn't such a bad model all the way up to CRAY and all the way down to the PDP-11. And there aren't any PC's wimpier than the PDP-11.

MSM: I guess not.

Feldman: The market.

MSM: Okay.

Feldman: So, therefore that's not a fully fair product view. I mean UNIX is simply a superb, simple but it's a time bound concept. Computer science takes a very long time to change to pick from one installed base to another.

MSM: Thank you sir.

Feldman: Okay.

MSM: I hope you'll give me a chance to come back if I have some more questions.

Feldman: Sure, feel free.

A.G. (Sandy) Fraser

The interview date is unknown

Fraser: ... programming business and probably a few years before that. So, I'm a latecomer to the scene. I 'm really not a good source for you. But, I'll happily provide what I can provide..

MSM: I'm gonna resist the temptation to talk to you about commerce. At some time I want to talk to you about, talk to as many people as I can. See if we can recreate or I can get some sense of what was going on there.

Fraser: Well, it's a long interesting story associated with leading up towards that.

MSM: I gather there was.

Fraser: Anyway, so I came here in '69. May of '69.

MSM: At about the time UNIX was started.

Fraser: Before UNIX. And as an MTS, I sat in the corridor - I don't know where that is now - and sort of heard various discussions going on. But, I really had nothing much to do with the evolution of UNIX. I was more of an observer. I had worked for a number of years in a file system and I don't know whether any of my inputs had any impact on the UNIX system.

MSM: What did you come here to do?

Fraser: Incidentally, I arranged to come here. I thought we were working on Multics.

MSM: (Laughing)

Fraser: I was interested at the time in trying to build a distributed operating system.

MSM: Uh huh.

Fraser: At that time nobody had ever done that. There were no such things locally networked or anything. I've done some, I've just written the file system for the Atlas computer operating system of the Atlas computer, which is England's first time sharing system. I had done some arithmetic which led me to think that distributed operating system might be whim. In order to do that sort I would model it first using Multics. On my way over here. I bumped into Peter Neuman who told me that Multics had just left and so I walked into this building and to find it in somewhat of a disarray and certainly very down. It had appeared I was the newcomer to the scene. It was quite clear that we were in the course of fairly traumatic change for a lot of people. In end of the '60's you may recall there was - ah - a time of change for all universities where it used to be that the computing science research communities as often as not used to run the computing centers for the university. As the buckets grew - and soon it became less and less practical in the end of the '60's - the universities one by one started moving the computers from the responsibility of the computer centers into the administrative area. That's what happened when Multics departed. With Multics here as I understand it, it was expected that it would become the vehicle for computing service. And at that time, responsibility was held in the computing science research organization. So, not only did they lose their research project, but, they also lost the budget and the responsibility that goes along with management comp center. I can alert you to the need to explore the dynamics of that occasion, but I'm not the person to really tell you about it. But, I would say the mood here occasionally was fairly important to what happened... at that time... what carried over with the Multics and what didn't. Who stayed around and didn't. A number of people left and so on...

MSM: How did you respond when you found there was no Multics around?

Fraser: I set about building my own. It was obvious that what I needed to do was build a model that I could build a distributed system with. At that time there were beginning to be a small number of mini computers - Honeywell 516 was one of them around here. The AP224 and the PDP-10 hadn't yet arrived. I'm sorry to say that. I would make a network, a ring network as a matter of fact, to link together a number of these mini computers. I would use that as a vehicle to put a file system... My first idea was to have one file system in a computer all by itself, and then a number of number crunchers. The idea was to build a ring, which would have this file system on it and then a number of mini computers on it. That took me from ... til about 1972 to finish that. By which time Multics had become real. So, we're co- inhabitants of the building. But, you can't really say I had much to do with those early days. I was an observer at the scene - perhaps.

MSM: What was going on in UNIX ?... influencing your own design?

Fraser: Not really, not really. The file system ended up being probably the first file system that I made - a file server was an early version of UNIX which I modified, so that I could build a new (not clear) on it. That was the only way UNIX influenced it that time. Um... After that, maybe I contributed a little bit on the UNIX front when I started with Paul Jensen. He and I worked on the circuit design aids package. Which was used (not clear) inside MSI circuit boards. At that time it was very much a hand process. We mechanized it. Since then there had been many such systems of course. I'm sure that I'm a real um really the right person. Maybe I can give you some pointers on how. If it well help.

MSM: Most ...What are the things that um... What Ken Thompson had finished talking about was um. I asked him if he had any - looking back on it now - if he wishes he had done anything differently now. One of the things he said was, he wished he'd thought more in terms of distributing systems from the outset. When it came time...time to make UNIX part of his distributing system, was it readily adaptable to that?

FRA. Well what has happened I would say that the UNIX is remarkably adaptable but not particularly attuned to be distributed and UNIX, UNIX is seems to me that UNIX is not entirely, but very much a file system. The file system wasn't designed to be distributed. You have UNIX systems that hooked together. You could see one another's file systems. That's the way it appears to be. It's only recently I think that a effort has been made to make it feel like the file system conveys the network as an entity. Its a planned effort that is underway there now. There are mechanics of networking that over the last four or five years have been systematically tackled and I think it's substantially improved. Which helped... most of the implementation of the distribution system with network in general, then it was just (unclear) streams. Dave was on his connection server. Those were the two main starting points. All that's very recent stuff.

MSM: Back to what you were doing in the '60's. Before you came here, were you working?

Fraser: ...at...at...Cambridge. It was a project known as Atlas 2, or more pertinently as Titan. Um... Atlas 1 was made at Manchester University. Fairly expensive activity funded by Ferranti for whom I worked originally.

MSM: I see

Fraser: At Cambridge, they wanted to make this time sharing system. They didn't really have all the funds that were available for the Atlas 1 project. So, they had a 'cheap man's' Atlas. They also had different ideas about architecture. Much of the technology is the Atlas technology, but the architecture was somewhat different. Different emphasis anyway. And a very much stronger emphasis on software. So, this slightly different Atlas computer arrived at Cambridge at about the same time I, or a little bit before, I arrived there. They were in the process of trying to figure out how to make a operating system for it. At the time I arrived at Cambridge, it was because of my history--I I knew a little bit about file systems. So, I took on the job of building a file system, the files, the dumping system, archiving system as a whole complex of uses.. and uh... There was just a single machine thing that did lead to these thoughts about how much traffic flowed between the different parts of the system and whether it made sense to cut off the piece of the system and put it in another machine. Um, um

MSM: How did people think about an operating system at that time? Was the idea get maximum use out of the machine or to make maximum use of programmers time? Maybe I should put that in content. In thinking about this, trying to map out some general themes. It occurred to me that during the '60s' most of these operating systems had been aimed at maximizing the machines. Making the machine efficient. They were expensive items. Corporations that bought expected them to be doing the work of the corporation. Programmer was viewed as someone who serviced the machine and worked off to the side. The idea that you would design an operating system to be a programming environment, it was a rather strange notion. How did... was that on target?

Fraser: I think the situation was a bit of... Yes, the operating system was a device which would allow the person to use the machine efficiently. I would say that um. There's a person named George Feld at Ferranti who I think was a very strong influence over the early days evolution of operating systems. Ferranti which certainly influenced... a number of people in the United Kingdom, certainly when it came to the Atlas type of operating system. It wasn't for programmers who were incidental to the business. The users were the... the programmers were the users. Yes, there was a concern to use the machine efficiently, but there's a great deal of concern to make it, also make it a human one, convenient software productivity or something was not a word that was used at that time. But, the notion was implicit in (unclear). That goes back to George Felton and the ORION operating system that Ferranti had. Where for example, there were quite lengthy discussions over the uh... both the instruction set and the operating system for the machine. Looking at it from a point of view of what is the easiest thing to compute. (unclear) for the programmer to do, not only what is the most cost effective thing for the engine to do. There were a lot of things in the Atlas operating system I think that helped with that . That also built upon the day that we learned, you know, David Wheeler and Maurice Wilkes were at that time working on that set too. Which was the first micro programmed machine. There was also a machine which had its subroutine... had a really quite advanced subroutine library. Maybe they were pioneers at that.

MSM: I think they were. Because the EDSAC 1 had it out then.

Fraser: Then that was not there, because of the most efficient way of doing it. It was done, because it was the most easy way, the most convenient way doing it from the point of view of the users. I think, they had been thinking about how to structure programs and make them manageable and so on for quite some while. Although interestingly they had not... that crew had not really paid a lot of attention to the higher level languages.

MSM: Just about to ask...

Fraser: Of course Stretch? was there around that time, I've been working on programming languages before this.

MSM: Um, um.

Fraser: It worked with Christopher with various things. He didn't manage to influence that group, and eventually he went off and had his own place in (unclear) Rd. in Oxford. Established his own line of research on the CP/M languages generally. Cambridge stayed pretty much more interested in structure but less in language. For some reason, I don't really understand, for quite a number of years. Maybe that was a concern about efficiency. I don't know.

MSM: Was that all split between, those who were mathematically interested in computing as opposed to those who understood the machine?

Fraser: That could be.

MSM: Making a system work?

Fraser: Yes. Uh...there was no computer science department at Cambridge all the time I was there. It was quite recent phenomena. It wasn't a respectable discipline in some sense. It was on the corner of the Cavendish very definitely a latter arrival. It was called the University Mathematical Laboratory. It gained it first origins with a differential engine - difference engine.

MSM: Hartree's?

Fraser: Think so. I guess Miller was one of the key drivers at that and Miller was asked numerical methods. Instilled that interest in most students that came through the place. The biggest users were crystallographers. Definitely a machine for mathematicians. Even for people who did other types of activity. I wrote a checkers program - the first thing I did for EDSAC. It was looked upon as a frivolous activity. Not as a research activity. I think

MSM: What had been your background?

Fraser: Very varied. I'm a aeronautical engineer. Who is interested in computers. Although I didn't know it in high school. Didn't know what they were. That I invented a machine that had computer like attributes. Burroughs used some of that stuff to say "Hey guy here are some things around why don't you come and get involved in it?" So, I got interested in computers, but there's no way you can get an education in that. So, I took up aeronautical engineering education, as being the most mathematical of the engineering discipline at the time. Then I went to work on summer jobs working with computers. Numerical mathematical course with...uh, Miller and co. at Cambridge for a year. It was the nearest thing to a degree in computing that you could get. Then I went to work for Ferranti - wrote an operating system for a small computer. I became responsible for a language which was competitive to COBALT. We worked on that for a number of years. It was a major project for engineering. Of course...that's where I got in touch at...where I was in touch with Atlas. Eventually I was given some responsibility with respect to the compilers on the Atlas, although I really didn't do very much. I came to know both Tony Brooker, Derek Morrison and also Christopher Strachey, Peter Landin, working originally at Cambridge and then Oxford. I got involved in writing compilers for a while. Did... I think I've made some contributions in the early days of compilers. The work at Cambridge I was just talking about...

MSM: Is that compiler work theory driven at all?

Fraser: No.

MSM: More on lines of fortunes trying to get something in the machine that will do the job?

Fraser: Yeah. At that time for Ferranti was just beginning to sell large machines to commercial establishments. What was clearly needed was something that combined the file system and the programming language. So, for example, when an insurance company could... didn't have to solve the problems of file management and the like, that could have that done for them. Could express their algorithms or whatever, in a language at some reasonable level - at some FORTRAN-like level. But, very about concerned about efficiency, particularly data representation. Um, um. In the those days everything was done on tape to tape processing. So, when one wanted to have reasonable compressed data representation. One was concerned with having fields which were bits and bytes. Packing things down. So, we're really (not clear) compiler. Probably there are few that had such a broad spectrum of challenges to try to go for. We did it with very little knowledge. It was strongly influenced, the mechanism was strongly influence by I guess two things: by Tony Brooker's compiler - we used something that would derive from that. And, by a determination on my part. That the Ferranti software should be written quote a 'higher level' language. In fact, we invented the language for that purpose, called COMPL, C-O-M-P-L, which we used to write the compiler. That I think influenced our thinking greatly. It was the only thing that ever got used for anything else. But, it allowed us to contemplate more elaborate tasks, then we would otherwise have contemplated, and thereby hang ourselves.

MSM: The iron 3... [laughing]

Fraser: Yes, that was right. I have a pretty varied background. Even before I arrived there. I've written the..., they had a small computer they called the Serious. I had written the operating system for that. Called 'The Monitor' actually. We didn't call them operating systems in those days. I wrote the subroutine library for that machine. That was in the days, when you couldn't get it into 256 words. It was too big. Squeezing into a small amount of space was the sort of thing that you were doing at that time. I think what I might do is just come more directly onto the UNIX front for a minute. Doug hasn't already told you. I think it is important to know the relationship of the UNIX activity to the way that (Ariel Eaton? - not clear) was managed at the time. You probably know how that was managed then and it's not a whole lot different, but there were some particular things. Particularly as it came (break) was Multics. There were a few key players. Were not in the management structure anymore. You probably - if you want to do a complete job, you probably need to talk to them. Um, um. The person who had this job was Ed David. He was quite instrumental in making Multics happen. I don't know whether he was instrumental at all in making UNIX happen. But, he certainly created the environment that lead to UNIX. By default. By first of all what he did with Multics, by the series of things that happened in it's demise. By a discussion that was taking place when I arrived in which Ken and Doug and Jason and various people were trying to buy people a PDP-10 which Ed David eventually had turned down. Um, um. The rationale for that was (bell ringing) was going to assume responsibility (bell ringing) for a fairly large piece of equipment, than it had to do with any operating system concept. They just came out spending a lot of money on a large piece of equipment gone wrong as a research project. Ed David could probably explain to you why we didn't get the PDP-10. But, I guess that very strongly influenced the course of events. Because it was after that they turned down the PDP-10 and came and built this thing on the PDP-7.

MSM: Is there any sense that labs have try to get involved in the large designing a large system and got itself burned eventually in the business?

Fraser: I don't whether he shouldn't be in that business. But, I would say that he got burned. It may well be that these juxtapositions of these different events were sufficiently close that the proper assessment of what had gone on had not yet materialized. They didn't stay around a lot longer of course. But, it certainly had something to do with that environment. The...uh...Ken's activities as far as I know, were not supported by his management for a little while.

MSM: That's what I gather.

Fraser: That might be explainable. Another person to talk to is Sam Morgan.

MSM: Yeah we talked with him.

Fraser: He happened to be director in 1127 at that time. I think had a great deal to do with the evolution of 1127 at that time. I think that the way UNIX turned out had a lot to do with the type of person who had been hired.

MSM: That's where I was hoping we could head...in this way...(unclear) background.[pause] What it is about the Bell Labs environment that attracted you here, or how congenial you found it when you got here. In terms of the kinds of problems people were taking up, the kinds of models they had in mind,... for what computing ought to be.

Fraser: I'm an oddity, not going to help. Sorry. The reason is that I came here for two reasons. Three reasons. None of which had anything to do with computer science development at Bell Labs. One reason was when I was at Ferranti I had this theory that which says that Ferranti really ought to have a research or exploratory development software activity. I had tried to talk them into doing that. In the process of doing that I learned something about Bell Labs and come to admire it from a distance. More from a point of view of where it managed and relayed the research to the rest of the company.

MSM: Um

Fraser: So, I had that in my head. Secondly, the scene in England was declining rather rapidly. It was fairly clear to me and not only to me that the ... that the, uh,...initiative for research and networking and computing - two things which were clearly in my future. The funding and the opportunities were going to be on this side of the Atlantic. The third thing, neither of those, I wouldn't have moved for either of those two if my wife hadn't died and I needed a change.

MSM: Ah, I see...

Fraser: A combination of the three things that put me in this place. When I got here, I guess I was a little unusual. In fact, most of the people here were hired straight out of college. I have this very varied background, managing a fairly large organization, being involved in research. Teaching for awhile. So, I think I had a slightly different perspective and sort of a broader interest in the role of the research organization, than many people come here with. Um, um.

MSM: But, you came as a MTS, not as a manager.

Fraser: Oh yes indeed. An MTS [coughing].I didn't come with a preconception of, I didn't know what I was going to do in reality.

MSM: Especially since there was no Multics. [chuckling]

Fraser: Yeah, I just don't have the vaguest idea of (unclear).

MSM: What struck you when you arrived? As far as computing?

Fraser: They were in this transient state. The toy had gone. The computer room was empty. People were just despondent. Some people were leaving. There was a clear lack of momentum. People working other subjects. I remember there were a whole bunch of people, Al Aho and others, who were working on bubble automata. Um, um. Which would have never gotten very far at Cambridge, I must admit. Even though I think they were of some value. Morostov used to make comments along the line that industrial researchers had to do things of a more theatrical nature in order to prove that researchers in universities didn't have any such hangups, I think was the expression [Laughing] that he had. He tended to encourage things which had a practical, if not commercial, flavor to them. There was rather more of the theoretical here. Secondly, at that time almost nobody in the company was taking any notice as far as I could tell, of the computing science research center. Which is a blessing as well as a disadvantage. I shared an office with a Paul Jensen who was a intern that Doug McIlroy had brought in, a person whose who was given the assignment of studying the ESS1 system and trying to make certain suggestions about how it might be improved, or what languages might be used on it. Paul had a varied influence on some of the things that I did and we shared an office with him for awhile. But, I don't think anybody else in the corporation and anybody else on the ESS1 banquet cared... could have cared less about what the computing science organization thought of what they were doing. At that time, maybe I misread it, but I was very quite surprised to see how disconnected such activity was with the rest of the company.

MSM: Yet the company retained it.

Fraser: Oh yes. They have (not clear) strong, strong concurrent of long term investment in belief in hiring people. Making more aware of what's needed and leaving them to make decisions about what's the appropriate branch computer science is to pursue. In order to produce what's needed. Maybe I didn't say that quite right. A lot of individual autonomy, hiring process, in the hiring process one can steer the course of the company. But, I think particularly for the computing research science center at that time, a lot of emphasis has been put on getting...simply getting good people. Regardless of it, they didn't know much about switching or anything. There wasn't too much software. The switching business, you must remember that, of what... twelve, fifteen years before that. They had a agreement with the Justice Department not to get into the computer business. That's something you probably need to understand.

MSM: Um, um.

Fraser: It had a very broad impact on Bell Labs position in 1969 and on its treatment of UNIX.

Fraser: The Consent Decree, the '69 Consent Decree was relinquished only as a result of the divestiture agreement of '84 or '83. In that interval, we had agreed that we wouldn't engage in certain activities. Which basically meant that we would selling computers.

MSM: Did that incentive Consent Decree exclusively keep Bell Labs out of software development only? In 56 what a computer meant, and what being in the computer business meant.

Fraser: You should read the Consent Decree.

MSM: I should.

Fraser: Okay. But, let me tell you two things. First of all, the 456 - and I don't know this, all of this, this is just history. I just have a smattering of it. - Western Electric was in all sorts of businesses. We made tape decks. We made televisions. We made just a whole variety of different things. I guess there was some real concern that telephone revenues would be used to subsidize some of these other commercial products. Generally, rip off the consumer in some way. So, a anti-trust case was brought and the result was that we agreed to stay to our case, stay to our meeting.

MSM: Um, hum...

Fraser: I think that was more the emphasis. Corporate lawyers have very strong incentive to be conservative. They gain nothing from taking risks, they can lose their jobs if they lose their risks and so, as my interpretation, my reasoning,... my interpretation of why it seemed that we as a company took a ...took a very self constraining view of the Consent Decree. To give you an idea of that, the first packet switch that I built in 1970 was a minicomputer programmed like many other minicomputers have since been programmed to behave like packet switches. There were long debates in AT&T about whether that was legal. Whether it was legal for us to make and install a minicomputer that behaved like a switch. In fact, strong feelings that it wasn't legal, even later than that. So you can imagine that anything that looked like UNIX operating system was hardly regarded by anybody as a legitimate product of the corporation. We did make software, of course, for inclusion in our own systems. The operation supports systems were of that nature, but um they were strictly connected with managing the network and somehow they were more legal than a packet switch.

MSM: [chuckles]

Fraser: You can remember the days, I'm sure, when the FCC was debating whether protocol translation within the network was legitimate - in fact, it wasn't. And now the question arises, what is protocol translation. You have characters coming in on an RS232 line and you've got to feed them onto a screen - is that protocol translation? All sorts of things like that, well lawyers and all sorts of people were preoccupied with such minutiae at that time. And anything as gross as an operating system or a compiler or a language were just clearly out of court. Had a lot to do, I think, with the companies attitude towards UNIX. What we did and indeed, with its success um... Well, the...the way it actually went to universities..

MSM: I see.

Fraser: Had a lot to do with....

MSM: You mean free?

Fraser: Yes. [Laughing] And both pluses and minuses of all of that . There was no great strategy associated with it. It was a more of a question of responding to something which seemed to be irrelevant. I would say. Or something we couldn't make money from. So it wasn't (unclear), there was no cleverness in my view to what we did. Others may have followed suit and thought that our giving away UNIX to universities was our masterstroke - our bread and butter - but that was no such thing. It was just a response to some very [laughing] (unclear) views.

MSM: Now the other side of that, as I understand it, and I wasn't involved at the computing scene at Princeton University at all at the time, was the attitude of the central computer facility, which was an IBM installation. But if the engineers wanted to go off and bring home this strange operating system from Bell Labs, well then they could damn well maintain it themselves and I wanted not part of it...

Fraser: Yes, yes I...

MSM: So the university first drew no great advantage from bringing it in here and

Fraser: The computer science department is like that.

MSM: They like it for its own sake and they would have to absorb the responsibility, take on the responsibility of maintaining it.

Fraser: I think you have to understand the legal environment...had a lot to do with what the company did and didn't do.. had a lot to do, perhaps had a lot to do with... the amount of support that was given to UNIX, or not given to UNIX in the early days. Given that we had just spent a lot of money on an operating system that had produced ah... that had come to a rather unhappy end. That operating systems, per say, weren't clearly in the future of the company. I don't know what was going through people's minds, but I think that it is worth understanding...

MSM: I'm...I'm very much trying to understand...

Fraser: I think that Sam Morgan might be able to help you with that. The uh department heads, who influenced this thing the most Doug McIlroy and Elliot Hickson. And Elliot is no longer at the company, he is an MTS in this building. His role in there, I'll let you discover, I don't think he'd consider himself a key member of that group, but he did have some of the people reporting to him. I think he did influence some of the forces that were in play at the time. Doug's involvement is one that I would hope that you can uh... that you can divine...uh. I... I'll give you a hobby horse of mine... I think Doug's contribution to the computing science research center here and to UNIX in particular is uh.. substantially under-rated. It's not been recognized by any public bodies that I know. It is by and large not recognized in internal documentation. I think that it is enormous. He was a disclaimer of his own contributions.

MSM: I had this sense in talking to him personally, this (unclear)

Fraser: You have to learn a bit about Doug to understand what I'm saying. You may have the time to do that. Doug used to be a (unclear) that he no longer is.. he's department head for twenty years. He decided twenty years was enough. He is a mentor - probably the best mentor we have. Of his strengths and weaknesses as a department head, he was not a strong bureaucrat, but an absolutely first class mentor. He had the subject all over his hands and (unclear). It is my impression, without any real data, Doug has a great deal to do with the climate that made UNIX happen. And the course of events, not because he instilled any particular course of events - Doug doesn't take decisions like that - but what he does do is involve himself in the conversation and insert a certain level of understanding into the conversation that may not have been there before, perhaps from the juxtaposition of other things that he knows about. And as a result, steers the thing that is evolving, without any clear identifiable contribution. But it was certainly my impression, listening to the tone of the conversation, and so on, that the clarity of thought that led to the cleanness of UNIX, had a lot to do with Doug McIlroy. If I'm right, I would really appreciate some explanation of that, because I've had a really difficult time getting people to understand that.

MSM: Some explanation of it in ...?

Fraser: His role.

MSM: Of his role..

Fraser: In trying to get...all the credit is going to the creators of UNIX and I think that a little bit of it should have spread across to Doug, but getting acceptance of that is a little difficult.

MSM: Um hum. It seems to me that something of that sense (unclear) amidst every work that is said, there is a little bit of Doug McIlroy sticking in it. Underneath the surface.

Fraser: Yes, you see Doug is a facilitator. He had a great deal to do with the nature of the group, the sorts of discussions they had, the sorts of things they did. He had a lot to do specifically with the manual. Now you may think of that as a terrible job, but don't think of it that way. The manual was, the fact that there was a manual. That he insisted on a high standard in the manual, meant that he insisted there was a high standard in every one of the programs that was documented. When they say if they have just done to produce the next edition of the manual... the work that had gone into producing the manual.. had involved re-writing all sorts of programs in order that they should meet the same high standard. And then added to all of that, it was probably the first manual that ever had a section with bugs in it. That's a level of honesty you don't find. It wasn't that they documented the bugs but were too lazy to fix them, they fixed a lot of bugs - but some of them weren't so easy to fix, or there were uncertainties as to what they would do - so they documented that. I think a level of intellectual honesty was present in that activity that was rare. Most people gloss over the (unclear) of their system's research activities, they are not true scientists. Doug is a true scientist.

MSM: Do you think the fact that, that this was a - heaven knows how to choose the adjective here - underground operation or unapproved operation led to - I don't want to say led to it, but contributed to that intellectual honesty. That is, here is something that we can't ever market, here is something that we are doing for ourselves: we might as well be honest about what we are doing?

Fraser: Well, maybe, but there are plenty of other things that are done under the same uh with the same lack of commercial pressure, but I don't see any of them with a bugs page. It was more than that. But the fact that the Consent Decree existed, that it implied that operating system was not a product of AT&T in some way and that .. that the activity was not frowned on. I think that it was probably not funded at the level that (name) wanted it to be funded at because its future role was not clear.

MSM: I get some difference of you...some from the literature, some from the few conversations I've had that its something that I want to pursue more. About whether it was frowned on or not..

Fraser: Well...

MSM: They feel it wasn't frowning, but others were seeing frowns there.

Fraser: Well, OK, that may be an interpretation, but I tell you another person to talk to if you get the chance... You probably have to do it sooner rather than later, is Max Mathews. Max Mathews was the director of 1122, organizations (unclear) Flannigan now heads, which is a sister organization to computer science. Max in fact 1122 was primarily involved with wave form processing one way or another. Max was in innovator in the use of minicomputers for his work. He was interested in these things. Max paid for the first PDP-11 that UNIX ran on. Even though the work was being done in the computer science research center. He simply thought that somebody ought to encourage this activity. So ah, it isn't that that money was put up by somebody with an agenda, other than supporting interesting things. It wasn't even his laboratory - he just put up the money. There are many people who ah, will do there best to recognize good science and support it. Nobody's nose was put out of joint for that, that is the nature of the business. And, I think it is fairly well recognized that uh you get uh three or four scientists in a room, all of whom work on the same subject, that they can have different views about the value or likelihood of a particular line of research. And accepts that. It isn't completely out of the question that Max and his speech research activities might look over at what was going on in the operating systems arena and say 'Hey that looks interesting. I think that I'll put some dollars that way.' That's how it happened. It wasn't a recognized upline project that got authorized...

MSM: This, I gather, do you recall when it was that people generally become aware that they had something here...taking off?

Fraser: Oh, I think that even the science research center knew that they had something real interesting even in (unclear) days.

MSM: How about the rest of the company?

Fraser: [quietly] Oh, it took a while. Don't know about it now. [louder] But there are people, things grow slowly. Max Mathews obviously though that it was interesting. He had one person, Lee McMahon - who recently died - who was working with these folk, and maybe Lee was the person who go Max interested...

MSM: [Under his breath] I'd like to talk to Max.

Fraser: [quietly and reserved] It is really unfortunate. Um [pause] ya...Bell Labs tries to maintain within the research area, we try to maintain a balance between things which people simply think are good and interesting science and things which point at reasons for their application. And we hope that by having a balance that we will- it is like investing some your money in guaranteed interest and some of it on the stock market. Its probably a good policy to have a mixture of them, if you go one way too much and take too many risks you can end up not getting any return for your bucks, and on the other side if you are too conservative you're not going to get your UNIX's.

MSM: Has (unclear) changed that much?

Fraser: No, don't think so. There are a number of things. I would say the (break) emination [?] of the Consent Decree has changed a great deal. Which is part of the

[END OF SIDE ONE]

Fraser: the end of that he makes a statement of work. Um that maybe the circumstances of UNIX may never be repeated. And in particular he worries that today, even here, the circumstances would not allow so much neglect of such a promising activity. And without that neglect the polishing and redesign that went into making it what it was, would never have happened. Today and it is true that there is so much hunger for new technology, for getting it into the pipeline, that it takes a great deal of self restraint to give people the time to do a good job. And in that sense the circumstances have changed. Of course now, computing, in very many facets, is clearly much more urgently related to the product line - the potential product line is much broader. What the corporation decides to do is of course still evolving, but uh, it is quite clear that operating systems and compilers and all these things are now legal tender. We have very much more interaction now then we used to with the rest of the corporation. I would say we are much more towards the center of the focus of attention than we were. It isn't because of UNIX. It is because of divestiture and opportunity - the demise of the '56 Consent Decree, which makes that the case. Whether you can stand by and watch something of great promise slowly evolve through a really quite inefficient and understaffed um but high qualified staff, see that happen and let it happen at the pace that it has to happen in order to be done excellently. Whether you can do that or not is the question, the open question that I think Dennis raised, and I don't think yet that we can say clearly that we know how to do that. We are definitely struggling with that balance or how to balance exploitation of mind neglect, or not neglect, but um - let the artist finish the painting.

MSM: Um huh. So that's your perspective on it. Your association with it came directly (unclear).

Fraser: Well the first thing was the, the file store that I built. And I think it had no influence whatsoever on the future of UNIX. It may be, I think it probably was the first file server that anybody ever built. It was a modified version of the UNIX file system. Really, I mean slightly modified. But it had no real impact on the course of UNIX. And the second thing that I ever had any significant thing to do with was this design (unclear) system - designing integrated circuits. Which did, which was an unusual application of the operating system. At the time it did have some influence. In particular, it let to other circuit design H systems and now widely used by the company. That was at a time when we had just acquired some Tektronix 4014's. Do you know what a 4014 is? Its got this great big..

MSM: Screen you throw up...pipelines...

Fraser: And you've got a cursor um, two little wheels that you turn - that moves the cross-hairs. You can point to a piece of the screen that way. A rather clumsy process. You can draw pictures. And it was an attempt to allow us to directly enter the schematics of circuits and gates...gates and all the rest of it...representations for the chips, pieces of chips and then a series of software packages that processed the data from that input to give us as much as possible without human intervention, a fabricated board. It was a little dream driving it - which is that it was possible to push buttons until a little board popped out of the wall - all made. Just a fantastic dream in those days, because it was an incredibly intense human activity at that time. So the schematic input. I guess I did it about the same time that there was this, that a similar thing was done at Stanford. Sort of in parallel. We purchased a semi-automatic ware machine and hooked it up to UNIX. Up to the operating system. That gave us our way of making the circuit board. Indeed, we got it so that the placement, routing, checking all the processes that you need to do to make a circuit card were done. And the model for that was troff, believe it or not. There had been other design aids, there was a design aids system running at Bell Labs at that time running on the mainframe - not interactive - there were no schematic capture, and you didn't hook the (unclear) on the output director. But there were programs for doing parts of the job. And they tended to be sort of model (unclear) data-based things. I noticed that they didn't evolve - the software got stuck. I noticed that the troff, the text processing stuff, was evolving nicely. The EQN preprocessors and so on and so forth. And that having the files, the intermediate files, be ASCII strings even thought that wasn't a very efficient representation, (break) rather than data-base, working off a data-base, seemed to be the key. So I think the thing that characterized the UNIX (unclear) design aid system we built, was it was a bunch of little processors that passed string to one another, by and large. And it has turned out, indeed, to be a remarkably versatile structure. Not the world's most successful, uh, uh, efficient, but its evolved immensely. We have a tremendously varied capability in this thing now for uh designing communicatorial circuits inside the read-only memories and designing PLA's and doing layout and uh, fabrication of multiwire circuits and quick connect circuits, wire-up circuits and so on and so forth. All this great menagerie of capabilities has blossomed mainly because the interconnection between them is a very simple mechanism - namely the passage of strings. And a language that I came up with at that time which was in fact modeled on troff. You could have sublanguages buried inside the whole language, I mean, it could for example - troff - with a macro package using dot and a couple of letters or something to signify a command. All of the programs are written to ignore the commands they don't understand, just pass them straight through. So EQN will recognize 'dot' eq and 'dot' en, but 'dot' t or something 't', 'tb' or whatever they are 'ts' which come from tables, they pass straight though. And the designed this package to do exactly the same thing, ripped off the idea from troff. So each of these packages just interprets stuff that the package understands.

MSM: I see.

Fraser: Turned out to be very powerful. So... I think it was really quit a successful uh ...we only spent a few years on it and it took off. I'm sorry, I'm not much help to you.

MSM: Oh, no, on the contrary, you're doing, doing...(unclear) helping in part in creating that helping to recreate the atmosphere.

Fraser: I'll tell you another person, if you want to understand the atmosphere, I'm pointing you off to other people that are hard to get, I'm sorry to do that but they are not all around - Peter Dennis. He is somewhere around, he lives in the neighborhood. Doesn't work here anymore. I would think that Flannigan's secretary could find him. He's left Bell Labs and consults - I know he consults for Nynex and so on. He worked for Max Mathews, was the proud owner of two DDP 224's, at that time, and probably represented the person that was most interested in the minicomputer business, in 1970. And although he probably, it was some while before he paid any attention whatsoever to using UNIX. I think he could explain the attitude towards minicomputers at that time quite well, which was part of the environment here. Bell Labs was one of the leaders, I would say, in the use of minicomputers. Starting in the late 60's, there were quite a lot of them here. And in fact, the one that Ken used, the PDP-7 he used, was a castoff minicomputer that had been used for graphics. Something of the flavor of computing in that time - I think Peter could give you a reading on it. Very strong influence, particularly on ..I think, Max Mathew's attitude that you could use these little machines to do a great deal. With lots of autonomy and so on. A lot of the flavor that was present there and is sort of characteristic of many views you get of UNIX. One... sort of aspires to the simple direct practical approach rather than the grandiose ... (unclear) sledgehammer. I think that in part, that in part grew out of the use of minicomputers around here.

MSM: Interesting thought...It's ironic that ... I hear about all of these groups that had minicomputers and then I hear a story about a central group that couldn't get a minicomputer for the longest while.. [Laughing]

Fraser: They had one - it wasn't a minicomputer. It was a GE 645. And they blew a bundle on it. Eventually caused enough of a cuffuffle around here...I mean the conceptor really failed to deliver to his customers. At that time the research organization was running the comp center and they failed.

MSM: Multics was their responsibility within the company?

Fraser: Yes, sorry, I didn't make that clear. Prior to that, the computer science research was running the comp center at Murray Hill. And they had decided that what they should do is build this new time sharing system - Multics - on the GE 645. And that would be the next generation, all modern, wonderful, computing service. The people and the physicists who simply wanted to crunch numbers had to wait until that happened. I'm inferring that they failed to deliver and eventually someone pulled the plug. And the result of pulling the plug was, the comp center was separated out, budget moved away from computer science research, and the computer scientific research guild became small in number - all the others left or moved into the comp center or something, and the small number had to find their own future. And that was the point in time at which I arrived. They (unclear) very definitely. Bell Labs is not going to harbor any grudge, that bright people are going to be doing any experiments. However, people that thought...allowing any responsibility for something...do have a responsibility that they have to own up to. I think that it was correctly recognized that this was an ambiguous situation having aligned responsibility with a research organization which had not managed to handle the line of responsibility really. So I think the correct thing was done to separate it out. But I am sure there were a lot of raw edges immediately after that happened.

MSM: I um until you said it hadn't thought about that question, of living with the responsibility of that. Also given what, given generally celebratory tones surrounding Project MAC and Multics. So it is hard to put to recreate a time when that would have looked like a failure.

Fraser: Bell Labs...of course you see there was another issue which is that Bell Labs was one third of that project. MIT and GE were the other two pieces. And we pulled out. That is not good for your relationships with your colleagues. A lot of reasons for sore nose.

MSM: I should guess so.

Fraser: It was a very complex time.

MSM: 1969 was just one hell of a year. [Laughing]

Fraser: Let me tell you, one other thing that you might... to my amazement when I arrived, the computing science research center as a result of this debacle did not have a lab. The absolutely did not have any equipment to speak of apart from a few teletypes. They used to have all this real-estate, which the comp center was in. And it had all moved to the comp center, and they wouldn't have had anywhere to put it really that had one. They had a situation for example where they had Max Maxwell doing experiments in speech acoustics research, minicomputers coming out of his ears and the computing science research organization had mathematicians and no lab space. Some of them weren't mathematicians, they where interested in systems and they wanted their own computer. So when eventually they did get their own machine, the next thing of course was to find some space to put it. That's not the easiest thing in the world to achieve. It was stuck up in the attic. That gave it a certain character. I think the organization regards itself - 1127 - regards itself as being something apart. A smile upon the stupidities of the bureaucracy. Poke fun at it - they don't stand and salute it. Having your thing be in the attic is somehow consistent with that. (Laughing)

MSM: Bohemian

Fraser: Most definitely. You might to learn and I really don't want to publicize too many of these things. There is a offbeat nature to this organization. Has gone back to the Multics state. Ken had a little alligator or something, for example, in the jar. The story was what happened when the alligator got free? (Laughing) They have done all sorts of things that are, have tested the bureaucracy. I happened to do that.

MSM: Could you classify them, at least some of them, as a community of hackers?

Fraser: I don't know what a community of hackers is. But, I would say there were. Hackers are people who write programmers and think afterwards. They are very, very few of them and they are not tolerated. A hacker is a person who writes programs, because he's tired of his program. There is... there is...

MSM: There's another definition of hacker, which I had in mind.. A person who likes to explore computing systems and refuses to accept closed doors.

Fraser: There is some of that. But, there's very strong sense of responsibility. It could be that both of these are originally from Doug's value set. Doug was one of the people. Who in the early days, wished out loud that there were a process and standards associated with the publication of computer programs that were comparable with the publications of literature. That is to say people were expected to read it. Writers would expect it to be read. They would be embarrassed if it wasn't readable. So on and so forth. I've never been in a organization that was able to write literature of that nature. But, I think there is a ethic, which says that the programs you write, should be well conceived and defendable. Although you may write a few programs that aren't that way, you're not proud of it. So, in that sense they're not happy. So, in that sense they're not hackers. If the hacker is the opposite of that.

MSM: I didn't have (name)'s hacker as much as I had Minsky's hacker, which is a person that does creative things, because one turns blind eye to the probing that is going on.

Fraser: There is a great deal of programming. The knapsack protocol and uh a lot of work in encryption here. We've had some attention from the NSA from our efforts as people did. We have some outstanding mathematicians here. I would say that the level of education, of interest, broad interest of the programmers here is pretty good, I suppose. Which is not at all common. So, lunch time conversation will center around all sorts of subjects, from what's going on some strange moon and the planet someplace, to encryption problems. Whether something works or how you can make it work differently and so on and so forth. However, there is a fairly strong sense of responsibility, social responsibility, which might be contributed to Doug. I don't know whether it comes from him, but it might. It basically says that you don't hurt people. So, they have not only do they have they been very effective in discovering ways of breaking into systems. But, they have led the charge within this company, towards finding middle ground between constraints which limit peoples ability to do things, and protection which limits people's access to your information. You have to find a middle there. You can either lock things up so firmly that nobody can do any business with you or leave yourself wide open. And I... Doug was chairman of Bell Labs committee, that was the first major effort organized to define the security policy at Bell Labs. And they found a very nice middle ground. I think they've done a fine job. And largely, because of what had been done here. Fred Ramp for example wrote a program, which would run around and find the loopholes in your version of UNIX and tell you what to fix. So, they enjoyed doing all sorts of nice things like that. Very clear and capable of driving holes in things. I don't think there's I.. I spend a lot of time trying to make sure that the other members of management don't go putting really secret stuff on their computer. Because, I know there are programs around that which will decrypt them, if they are encrypted. There I know that there are people around who find their way into things they want to. So, I wouldn't want to feel that the information is not secure. On the hand, many of the people who possess those tools are also very responsible with them. So, I don't have any serious concerns. That both sides of it are present here. Fred Graham is the only person we have at the moment who is firmly in charge of that. He has a lot to do with helping the rest of the company deal with crisis, when we find that people are invading (unclear) or something.

MSM: I remember when I was in Holmdel. Whether it was a break in or an attempted break in...

Fraser: Fred was the guy who they consulted about that. I think by and large everybody has adopted a responsible attitude, even a playful attitude. Playful but responsible attitude most of what is done. I tend to do things a little off the wall. I think all of them, well nearly all of them. There have been things that were done, which were harmful in some way. And they by and large are shouted down. A guy put an (unclear) bomb outside somebody else's door, which had liquid nitrogen in it or something, but those sort of things are fairly rare. More often than not I think, making fun of the stupidities of the corporation. In all these corridors there is a little shower head. The reason the shower head is there is that some part of this building they use for chemical research. There use some dangerous chemicals some of which can get pretty lethal. Any of it gets on you, you want to wash it off in a real hurry. Before you get hurt. So, they have these shower heads as we call them and it's sort of stupid to put one in a software research organization. But the bureaucracy says that if you should put one in one place, then you should put one everywhere. So, the first thing they did was put towel out there and a bar of soap. A lot of that goes on. [laughing]

MSM: I was re-reading Ken's Turing Award lecture last night. I was struck by how sobering a talk that was. I was also thinking of the ironies of it, given last year's break-in. Is there anything else I should know?

Fraser: No. That's it.

Brian Kernighan

The interview date is unknown

MSM: Since we were talking about translations, and since you have watched this book be translated, I suspect you're one of the people that translators come back to when C goes into another setting-let's say into another language. It struck me, the more I converse with people-I want to get to this-that Unix is as much an ethos as it is a programming system. It's a way of thinking about computing. Have people had trouble with that aspect of the translation of Unix? What has been the response when people have tried to adopt Unix into other environments?

Kernighan: I hate to give a non-answer to the question, but, in fact, I have had relatively little feedback from any of the translators, with about three exceptions, I think. The guy who has translated several books into German really does program for a living. He writes; although he's a professor in the university, he seems to enjoy writing really grimy books on how to do things, and so he and I have technical arguments about things at one time or another. I don't think he has any trouble translating from English into German, or vice versa. He does his own translation of German words into English. So, there's a non-barrier there, if you like.

There are two people that I know, not as well, who have done the translations into Japanese of different books. The guy who's done them into-particularly the Unix book and a C book, is-runs the computer center at the University of Tokyo. Although he probably doesn't program on a day-to-day basis, I think he genuinely understands what's going on. My guess is that he doesn't have a heck of a lot of problems tanslating. Although one Japanese lifestyle, culture, or whatever, is enough different in some areas, that maybe it makes a difference. My bet is that it doesn't make a heck of a lot of difference. I suspect the computing aspects are pretty close to the same there, as they are here.

MSM: Let's take the English-actually, let me rephrase the question, because I had in mind more of an aspect of the portability of C. You wrote the books, and I suspect-maybe the premise is wrong-that people or institutions have tried to go over to you to adopt Unix; that you're one of the people to whom they come back and say, "I don't quite understand how this works." The queries came to you, or have come to you. Am I right on that premise? Have there been a sort of set of difficulties people have encountered when they tried to go over from one system into Unix? Has Unix proved difficult to port as a way of doing things, as opposed to simply a piece of software?

Kernighan: I think in a way it has, although memory grows dim. A lot of this stuff is something that I don't think about much anymore. Fortunately, I'm not involved in it as much. But I think there has always been a problem when somebody new comes to the system. There's a set of shared, I don't know, conventions; things that, because they work the same throughout all the Unix operating system and its programs, tend not to get written down. They're just like folklore; they're customs. Like keeping to the right as you drive almost. Everybody knows that kind of thing, and therefore, it tends not to be written down as part of every single description. It's in one place and then forgotten. People who come new to this system don't know that that sort of particular behavior is pervasive, and therefore, they are perhaps befuddled by it; they don't expect that it will work. And you could see lots and lots of examples of it. Oh, fairly narrow technical issues, but for example, the fact that most programs read from a list of files, or there are no files from the standard input. And I still remember seeing somebody who had taken one of my programs-ratfor, the FORTRAN pre- processor-reproduced the manual page, and had added a bug section which says that if you just type ratfor nothing happens, not realizing that if you type ratfor it's waiting to read the standard input. Okay, so there's an example of somebody who just had missed totally an important aspect.

An analogous one which is probably more modern: If you look at DOS, MS-DOS, the notion of wildcard characters for filename expansion, is part of DOS, but in a very strange way. It's really not done by the command interpreter, COMMAND.COM or whatever, the way it would be in Unix, by a shell. But, rather, it's a service provided by individual programs, and that means that its properties-some programs don't have it, its properties might be somewhat different from one program to another, whereas in Unix it's known that it's done by a single program, in a single place, and therefore its properties are somewhat more uniform. That notion that there's the right place to do things is something that you maybe take for granted in Unix; it doesn't quite come up the same in other systems. And so explaining that to people, maybe is difficult.

Another area that I remember endlessly, when we were doing in what I will best describe as popularizing Unix, back in the mid and late '70's: People would come in and they'd say, "Yeah, this is nice, but does the system do X?" for some X, and the standard answer for all of this was, "No, but it's easy to make it do it." Unix has, I think for many years, had a reputation as being difficult to learn and incomplete. Difficult to learn means that the set of shared conventions, and things that are assumed about the way it works, and the basic mechanisms, are just different from what they are in other systems. Incomplete means, because it was meant as a program development environment, it doesn't have all the finished products necessarily. But, as a program development environment, it's very easy to build a lot of these things. It's sort of like a kit. And if you want a new thing, you can take the pieces out of the kit and assemble them to make your new thing, rather more rapidly than you would be able to do the same thing in some other kind of environment. So, we used to say that. "Does it do X?" "No, but it's real easy. Do you want one by tomorrow? I'll give you one by tomorrow." Every once in awhile, someone would call your bluff. (Laughing) Sometimes that was fun, and sometimes it wasn't.

MSM: In what you just described, you used the term "kit," which could be expanded to "toolkit." And existing notions of tools, and Unix as a set of tools, where did that image come from? Doug credits you for it in the collection of research manuals.

Kernighan: I honestly don't know where it came from. It was in the air in several different ways. I think maybe Plauger and I were the people who put a name on it, and maybe some coherence, when we wrote this off our tools book, and tried to take ideas out of Unix and put them somewhere else. But I think the ideas had been kind of floating around anyway. Doug, of course, had published these two papers, in the-I don't even know where they were papers in, the Garmisch, and wherever else software engineering conferences in the late '60s, '68 or '69, that kind of time-where he was talking about things; not quite tools, but components. If you're going build components, you need tools, so that's part of it there. I have a vague notion that Bob Morris was talking about those kinds of things too, because I remember him giving us a fairly coherent talk at one of the spring or fall joint computer conferences fairly early. Beyond that, I don't know. I think that I started giving talks about tools, and combining programs, and so on, fairly early. '73, '74 more likely, that kind of time. And then Plauger and I started to work on the software tools book. And it was, well, what are we talking about? These are the tools you use when you write programs. And that came out in early '76. So, presumably, we were working on that in '74 and '75. I might conceivably take credit for the name, but probably not the real intellectual idea underneath it anyway.

MSM: Is this something you learned when you got here?

Kernighan: I think probably yes. I had spent the summer of 1966 working at MIT, in the group that was the MIT component of the Multics effort. I spent a summer there, working ostensibly for Corby, but practically for-I don't even know for who, officially, but, you know-I was there and I was working on something, and in fact, it was a tool that took stuff from the CTSS machine, the 7090, and made a coherent tape which you could then load on the 645, which had just arrived, and actually run it as a sort of Multics-y kind of job, although Multics didn't really do anything. I've forgotten, it was the merge editor or something; it was basically just, take a bunch of stuff from here and put it over there. So, I got used to both CTSS as an environment and some of the noise that was in the air about Multics, although I didn't actually have much to do with the pure Multics side of it.

Then I came back and spent the summer of '67 and '68 here at Murray Hill, first summer working for Doug, and I built myself-typical summer job, I think-Doug suggested an idea and I got sidetracked into the tools that were underneath the idea, or might have been helpful in building the idea, and I never went off and did anything. He wanted to investigate storage allocation algorithms, and I started to build myself some list processing stuff and never finished that. That was much more fun than (laughing) trying to figure out the properties of storage allocation algorithms. I think that beyond that, the notion of tools, or languages, or anything like that, did not show up in my consciousness until noticeably further on, probably when Unix was actually running on the PD11, which would be '71, '72, that kind of time. And even there not really.

MSM: Before or after Doug did pipes? Was pipes a trigger for this notion?

Kernighan: I think it probably was the capstone or whatever. I'm not sure what the right image is, but it's the thing that makes it all work, in some sense. It's not that you couldn't do those kind things, because I had already written redirection; it predates pipes by a noticeable amount. Not a tremendous amount, but it definitely predates it. That's an oldish idea. That's enough to do most of the things that you currently do with pipes; it's just not notationally anywhere near so convenient. I mean, it's sort of loosely analogous to working with Roman numerals instead of Arabic numerals. It's not that you can't do arithmetic, it's just a bitch. Much more difficult, perhaps, and therefore mentally not-more constraining. But all that stuff is sort of now squashed into such a narrow interval that I don't even know when it happened.

I remember the preposterous syntax, that ">>" or whatever syntax, that somebody came up with, and then all of sudden there was the vertical bar, and just (snaps fingers) everything clicked at that point. That was the time, then, I could start to make up these really neat examples that would show things like doing, you know, running who, and collecting the output in a file, and then word counting the file to say how many users there were, and then saying, "Look how much easier it is with the word count. With the who into the word count, and running who into grep," and starting to show combinations that were things that were never thought of, and yet they were so easy that you could just compose them at the keyboard and get them right every time. That's, I think, when we started to think, probably consciously, about tools, because then you could compose the things together if you had made them so that they actually worked together. And that's when people went back and consciously put into programs the idea that they read from a list of files, but if there were no files they read from the standard input, so that they could be used in pipelines. People went back and did that consciously in programs, like sort. Sort-an example of a program that cannot work in a pipeline, because all the input has to be read before any output comes out-it doesn't matter, because you're going to use it in a pipeline, right? And you don't care whether it piles up there briefly; it's going come out the other end. It's that kind of thing, where we say, "Hey, make them work together. Then they become tools." Somewhere in there, with the pipes, and maybe somewhere the development of grep-which Ken did, sort of overnight-the quintessential tool, as I guess Doug refers to it. A thing which, in a different environment probably you don't see it that way. But, in the Unix environment you see it as the basic tool, in some sense.

MSM: There are several directions to go here. One that this brings to mind is, do we take grep and yacc and get awk?(not clear)

Kernighan: As a bit of an oversimplification, yeah. I'm not sure that yacc is the right model. I think in fact sed is the right model. That-because the patterns are much simpler, and there's less of a sort of-there's a more sequential structure to the processing in awk which is much closer to match to way that sed works than to yacc. Yacc has mystical properties; I mean, certainly it's patterns and actions, but the patterns sort of spring into action, as it were, out nowhere. Whereas, it's really obvious what's happening in sed and in awk. So, I think that's a fairer example, or a fairer path of evolution. It's much closer. Because, I've been interested-having seen sed, I was kind of interested in the notion of a programmable editor, because there were lots of things people were doing that required text manipulation, and we didn't have on Unix a programmable editor. We had this thing called qed which came originally from Peter Deustch, I guess, or somebody like that, at Berkeley-but Ken had made it work on Multics and then I think Dennis made it work on the GE machine that we used. It was a programmable editor, but it was programmable in some formal sense. It was just awful, and yet it was the only thing around that let you manipulate text in a program without writing a hell of a lot of awkward code. So I was interested in programmable editors, things that would let you manipulate text with somewhat the same ease that you can manipulate numbers. I think that that was part of my interest in awk.

The other thing is-that I remember as a trigger for me-was a very, very specialized tool that a guy named Mark Rochkind developed. He was in group that was doing, you know, genuine telephone-related stuff, and he had a program that would let you specify basically a sequence of regular expression and message-regular expression and message-and then it would create a program such that, if you pass data through this program, when it's on instance of the regular expression, it would print the message. And we'd use it for data validation. And I thought, what a neat idea. It is a neat idea. It's a really elegant idea. It's a program that creates a program that then goes off and validates data, and you don't have to put all the baggage in; some program creates the baggage for you. The only problem with it was that it was specialized, this one tiny application. And so my contribution to awk, if you like, is the notion that you can generalize this. Technology of making regular expressions work, to this day, remains (not clear) and many of the database, and general feeling of data processing that you might get out of (not clear) repeater, I think that holds much of the first-cut implementation. I don't remember a lot of that stuff. Again, it's pretty blurred now.

MSM: It's hard for you to remember just-I mean, how did the three of you get together?

Kernighan: Well, we got together in, typically, in my office. We'd argue, and invent something in real time, and that, (laughing) that has been with us ever since. We'd throw stuff in. Peter is a very, very fast implementer. He can build things much faster that I can or Al can; and so we would get some idea and he would typically have it working almost immediately. Then over the years, I would go back and clean it up. Sometimes, we-he implemented things and we ultimately threw them out and probably should have left them in. For example, right at the earliest times he had a version of awk that would generate C instead of being an interpreter. That was something that didn't resurface again for almost ten years. He had in it several different regular expression machines, one of which would do one of these very, very fast regular expression searches, if the set of things that you were looking for was just key words, without metacharacters. The basic yacc-grep algorithm. He had implemented that, that kind of stuff. Over the years, I had tried three or four different internal mechanisms for the interpreter machine. You try a stack machine and see how that works, and you try quads or triples or something like that, and see how that works. You try interpreting the parse tree and see how that works; that's the one we stabilized on. So, I personally have used awk, probably excessively, as a vehicle for experimenting with various kinds of half-baked ideas, both in implementation and also in language design.

MSM: Let me back up to the beginning. You were up at MIT in '66.

Kernighan: Correct.

MSM: And there working with Corbatmoving from the 7090 to the 645. Conscious of Multics, but not part of it?

Kernighan: In some sense, yeah. I don't think I realized quite what it was all about. I mean, I had some notion that this was interesting. I was using CTSS; that was the first time that I had used a substantial time-sharing system. I had played very, very briefly with Dartmouth BASIC, and you know, it's kind of nice to have the computer talk to you. But CTSS by comparison was very, very polished. You could really do nice things with it, and in addition you were right center of the universe of CTSS; all of the experts were there. It's very like this is the center of Unix expertise. There it's the center of the CTSS expertise, and so they could make it do wondrous things which you would have never found if you weren't nearby. So, I was interested in that aspect of it, and then there were some interesting application programs as well. Like, ELIZA was there; Joe Weizenbaum worked down the hall. Now, he was away, I don't think I've ever met him.

But-so, you know, I'd meet an interesting girl, I'd bring her in to talk to the doctor. (Laughing) But, it was just an incredibly fun place to be. But, the Multics aspect of it, I had relatively little to do with. What I was doing was writing a program that ran on the CTSS side, and it created a output that was usable by somebody else. But I didn't actually care much about the output side of it. It was just a simple data processing problem; let's just collect inputs in some sense or other and put it together in a stylized sort of way. But, it involved list processing, and it was written in MAD, which was kind of a neat language. Much better than FORTRAN, which would have been one of the other choices.

MSM: MAD's the Michigan-

Kernighan: Yeah. Right.

MSM: It was Bruce Arden's, wasn't it?

Kernighan: Yes. Arden, Galler, I don't know who else. That group.

MSM: You came here in '67, '68. Were your projects part of Multics projects?

Kernighan: No. When I came in '67, as I mentioned earlier, Doug had this notion of working on figuring out what were good storage allocation algorithms, for ML, basically, that kind of thing; how do you provide quick access to storage and then release it again. That remains a good problem, to this day, and Doug continues to work on it to this day. But I didn't get turned on to by it. But, what I did was to go off and say, well, if you're going to provide storage allocation-let's say in a FORTRAN program, which at the time FORTRAN was kind of the universal language for most people-it would be nice if you could-I had spent time at MIT working on list processing kinds of things. There was a list processor called MAD Slip, which was basically just a bunch of routines that you call from a MAD program that let you do-you know, create a arbitrary size block of storage and then link it to some other arbitrary block of storage and so on-so you could do list processing in a conventional algorithmic language. And that was kind of neat, and so what I did that summer of '67 here, was sort of take Doug's vague idea of storage allocation and go off and build myself a bunch of routines that would let you, from a FORTRAN program, do list processing. You know, create a block of storage this big, link blocks together, walk along lists and stuff like that. And in a fit of absolutely misguided craziness I spent much of the summer trying make it run absolutely as fast as possible on this specific machine. So a lot of it was assembly language programming. It was-except for a learning experience, I think ultimately a total waste of time. But it was fun.

Then the second summer, I came back, the summer of '68-I spent that summer working genuinely on my-on stuff that would be related to a thesis. I worked with Shen Lin on graph partitioning, which is just unrelated to any of the above. I mean, it did require going out and writing substantial FORTRAN programs and doing experimenting and so on, but it had nothing to do with any of the sort of system-y stuff. It was pure combinatorial experimentation. I did that, and then when I got back to Princeton they, in their wisdom, said, "Your money is going to run out in January. Maybe you better write a thesis." I said Ah! (laughing) So, I wrote a thesis.

MSM: What did you write it on?

Kernighan: Graph partitioning.

MSM: Graph partitioning. I was going to look it up, but I didn't get a chance to go to the library.

Kernighan: Anytime you want to hear about graph partitioning, I will be glad to tell you what I know about graph partitioning. It remains a standard problem. I think it's an interesting problem, because it shows up in a variety of guises in real life. In circuit design, which is one of the reasons that people here were kind of interested in it, and it's still part, a fundamental part, of a lot of circuit layout problems. Because, basic idea is to take the components of a circuit and cluster them-in some sense so that you don't have too many wires running from here to way over there; rather, most of the wires are short. But there are constraints on the size of clusters, because the things you are clustering together have to fit on something, like a chip, or a substrate, or a circuit board, or whatever. It's a plausible model. Quite a few real problems. I actually worked on that off and on for probably the next four or five years, when I got here, and other combinatorial problems with Shen. But, I gradually drifted out of that stuff, after two or three years.

MSM: When did you come here in '69?

Kernighan: Real early. February probably. I graduated. I escaped from Princeton in January of '69.

MSM: It's the only way to describe getting out of grad school.

Kernighan: Yes. (Laughing) You understand completely. I really enjoyed Princeton as a graduate student. It was in some sense the peak of income and the minimum of responsibilities, and except for a horrific-probably eight to ten months, while I anguished over what the hell am I going do to for a thesis, I can't get out of here without a degree. Other than that, it was idyllic, it really was. Just a lovely place to be.

MSM: Yeah. I kid, but I actually had a good time as a grad student there. I was married at the time, but when we'd come back from living in a one room apartment in Germany, this Butler tract looked absolutely palatial. (laughing) But, it was like the situation my third year. An NSF fund, and I was teaching a couple of sections. I don't think I ever had so much disposable income.

Kernighan: Yep. Exactly. (laughing)

MSM: The rent was forty eight dollars a month.

Kernighan: Yeah. I remember.

MSM: What did you come here to do? Were you hired into the computing research group?

Kernighan: Oh, yeah. The same group that I'd been in all along. It's interesting, I had so much fun here in '67 and '68-just, you know, the people. It was just such a good collection of people, and I've enjoyed it. I never interviewed anyplace else; I never even thought of any other place. I simply said I'd like to work here. And Sam Morgan, in his wisdom, said, "We don't want any Ph.D. dropouts, so you have to get your degree finished. But, other than that, sure, we'd love to have you." That was it, and I came early in '69 and the charter, or my instructions, were-as they are for everyone else-non-existent. Do what you want. The hope is that the combination of people around you, doing things that are interesting-and perhaps ultimately relevant, but not instantaneously relevant, I don't even know-but the combination of people around you doing interesting things, and getting their jollies, I think, from having their interesting things affect other people, means that there's this sort of gentle gravitational pull towards doing the same kind of thing yourself. It's clear the reward mechanism ultimately favors those people who have an impact on the local community, impact on the Bell Labs community, impact on AT&T, impact on the scientific community, in some combination.

MSM: So, it's a question of, "Do what you want, but when we come to salary review, performance review, come talk about what the impact of what you've done has been."

Kernighan: Impact is, I think, ultimately the criterion, but there's quite a long view taken, and quite a broad view of what impact is. So, somebody who does purely theoretical work-but whose theoretical work affects the community in some sense, either because other people take it and produce artifacts, or because that person is able to shape a field, or something like that-that's fine. That's good work. That has impact. It doesn't mean that you can see it in a telephone or anything like that; it means that it has had an effect, a positive effect, on something of substance.

MSM: Now, when you arrived, one of the things going here was Multics. Were you that involved in it?

Kernighan: Yeah. I was conscious yes, involved no. I remember watching Ken and Dennis and a couple of others stroking this giant this giant machine that sat probably just around the corner here, or maybe it was one floor down, and sort of being intrigued, but from a distance. I never actually, I think, ran on it or did anything on it. At the time I came, it must have been within a few months of disappearing. I don't remember specifically. But, for all I know, it disappeared between one summer and when I came permanently. I don't know the date of that. But I never had anything to do with that. At the time, I was doing this combinatorial stuff with Shen Lin. When I first came, I continued to work on graph partitioning and, you know, I also got interested in the traveling salesman problem again. He'd been interested for a long time, and I got sucked into that. We were writing FORTRAN code for that, and I don't think there was a FORTRAN compiler on the Multics machine. So, we ran it on the standard GE machine, where there was a perfectly fine FORTRAN compiler and, you know, operators and all the other things that you needed to get the job done. So, for the first couple of years that I was here I spent essentially all my time doing combinatorial kinds of things and running right just vanilla FORTRAN programs.

MSM: So, that's why The Elements of Programming Style is basically about FORTRAN programming?

Kernighan: Well, that's not why it was. It's because FORTRAN was the dominant language, and-it really was the dominant language of scientific computation, and the only other language that you could pick on that had any overlap with it, really, was PL/1, because it had this sort of side of it that was used for scientific computation, and there was a hope that PL/1 would replace FORTRAN for scientific computation, which of course never came about.

MSM: Were you around when Multics was canceled?

Kernighan: I guess so, yeah, as I said.

MSM: Do you get any memories of that?

Kernighan: I really don't. I just don't know-

MSM: Sense of mood or-

Kernighan: I just don't remember. It's completely gone. You know, I-my guess is that the people who were involved were probably somewhat disappointed, maybe bitterly disappointed. If nothing else, they had invested a lot of time in it. On the other hand, I think the handwriting must have been extremely clear on the wall for quite some while, that this thing was not living up to its promises. The promises made had been totally unrealistic, but it just wasn't living up to anything.

MSM: When did you find out what Thompson and Ritchie were up to?

Kernighan: I don't know. I remember long discussions right across the hall there--which I think at the time that may have been Rudd Canaday's office, I don't remember now-when they would sit and draw pictures on the blackboard, file systems, different kinds of pictures and talk about it. I wasn't paying very much attention to that. I remember some distant-well, I certainly remember the PDP-7 and 9, because of the great graphics display, and you could play Space War on it. It was the best Space War, and still one of the best video games ever invented. But then Ken started to do serious computation, this Unix-related stuff on it, and at some point he put together a system. I think it was Doug who probably first pointed out that this was actually a useful thing, that you could do interesting work on it, but I still didn't actually do anything with it, certainly not while I was on the PDP-7. And I did not-I think that I, in some ways, got involved only peripherally through the B interpreter, which-B was the language that they had used to experiment in one way or another. Steve Johnson made a version of the B interpreter that ran on the Honeywell machine. I started to play around with that, and got interested, and wrote with Steve a sort of introduction to B for people, so that people could write B, presumably on the PDP-whatever-at that point I don't remember whether it moved to 11 or not-but also on the Honeywell. So, I wrote this little tutorial on B, and I wrote a couple of B programs, and I found it, you know, easier. It was like going back into MAD from FORTRAN. It was just easier, because a lot of-it was easier to manipulate characters, textual kinds of things, you didn't have to worry about goddamn labels and continue statements and so on. I mean I still use goto's, but it was just cleaner. You didn't have to worry about card boundaries, all that kind of nonsense. It was just nicer. In some sense, maybe that's how I got into it, through the language side. Then, at some point, the PDP-11 came along. There was an actual useful machine there, and.... I literally don't know what I-how I got in, or what I did first. I must have been pretty early in the game, because I have a single-digit user ID, as do Ken, Dennis, and Doug.

MSM: Low serial number?

Kernighan: Low serial number. (Laughing) Mine is 9. It's the last of them. But, there's got to be some cachet in having a single- digit user ID on the lineal descendant of the original Unix machine.

MSM: Absolutely.

Kernighan: Ossanna, I don't know, was 4, maybe, and Robert Morris was 5, and that was it. I mean, Ken was 6, Doug was 7, Dennis was 8, or something. You know, that kind of thing. So, I was 9. So, I must have been in, in some way, fairly early, and I don't know how I achieved that.

MSM: You don't remember what you were doing, what got you on?

Kernighan: I don't. I really don't. It may have been that I said, "Gee, I'd like a login or some way to use this machine," and maybe never did anything with it. That I don't remember.

MSM: What were you working on at that time?

Kernighan: Probably, still these combinatorial kinds of things, because Shen and I worked on graph partitioning and traveling salesmen, and I worked on a variety of circuit-related things, circuit design related things, with a guy named Dan Shweichert, that were also combinatorial, and so on, in that period of time. Those were predominantly FORTRAN programs running on the GE machine, because that was the general-purpose computing environment.

MSM: What was your first major project on Unix, and when did it start to become part of your research program?

Kernighan: The first substantial thing I can remember was eqn, which Lorinda and I did, and that, I would guess, was '73 or early '74. The initial development was very, very short, but you could probably date it almost exactly. It was written in C, so there had to be a working C compiler, which was presumably put in in '72 or '73. There had to be a working yacc, because, you used the yacc grammar. It was done-in fact, I could find out from this-there was a graduate student named Wayne Hunt who had worked on a system for doing mathematics, but had a very different notion of what it should be. It basically looked like function calls. And so, although it might have worked, he a) didn't finish it, I think, and b) the model probably wasn't right. I remember, he and Lorinda had worked on it, or she had been guiding him, or something like that. I looked at and I thought, "Gee, that seems wrong, there's got to be a better way to say it." I mean, then suddenly I drifted into this notion of, do it the way you say it. I don't know where that came from, although I can speculate. I had spent a fair length of time, maybe a couple of years, when I was a graduate student at Recording for the Blind at Princeton. I read stuff like computing reviews and scattered textbooks of one sort or another, so I was used to at least speaking mathematics out loud. Conceivably, that trigged some kind of neurons. I don't know.

MSM: EQN was the-

Kernighan: That certainly was the first substantive thing that I did that ran on Unix; was purely, specifically, only a Unix program.

MSM: Was that the point at which Unix was being developed on the grounds, on the basis, of being a text processing system?

Kernighan: It must have been well into that, because at that point troff existed, we had typesetter-because this stuff wouldn't be interesting if you didn't have a typesetter-so we had a typesetter, and Ossanna had a working version of troff. So, all of us had had this interest in text formatting for a long time. When I was at Princeton, I wrote a program to format my thesis, because I couldn't stand the idea of paying somebody a couple of dollars a page to type the stuff, because I knew I was going to do it over and over again. I hated just writing stuff out by hand, and I couldn't use a typewriter very effectively; it was just too tedious. So, I wrote a text formatter at Princeton, which was sufficiently successful that, for a decade later, there was a student roff agency.

MSM: I don't remember the student roff agency, but I do remember, back in the mid '70s, when I first became conscious there was a course on computers and society that was being taught by a guest brought in from Rutgers because no one at Princeton wanted to teach the course. It has since disappeared as a course; I keep threatening to bring it back. It would actually be a good course; I'd have no trouble getting 1500 students in for a course like that. But, I remember that the students were asked to roff their text. I remember about that time, one of my students, the first of my graduate students in the history of science, discovered script. He started using green bar paper, and then never did write a proper thesis, because he thought editing meant going in and responding to my margin area on the line, and that's not what I had in mind.

Kernighan: So, I was interested in formatting. I'd done this formatter, Joe Ossanna had done a formatter. I think it was either-it may have Ken, it was probably Ken, but it might have been Dennis-that had done a little formatter that ran on Unix, and that was the genesis of the patent department stuff. But, Ossanna took it over, I think, and made it big. I may be making that up, you'd better check with some of the protagonists. Doug was interested in formatting, and had built quite a sophisticated one for the Honeywell or GE machine-somewhere in there, it became Honeywell. So, there were a lot of us who had our hands in on formatters, and it was one of those topics that everybody was intrigued by. But, the eqn thing was the first-something that sat on top of, or in front of, a formatter to genuinely broaden what you could do with them. That was the first thing.

MSM: One of the things that I find quite interesting there, is-I can understand people's being interested in formatters, because you get the idea that you're going to have a system that you can type onto, and using a teletype to do it. You say, "Look, this is a typewriter, if I can get stuff into it, I ought to be able to be able to get stuff out of it, and I ought to be able to get it out in any form. Why not use this as a way of editing? Why not stop this silliness of having to count lines and footnotes as I encounter them, and keep a record of them off to the side?" and so on, and so forth. But, eqn and tbl and the others go beyond formatting, to typesetting. It's going to get you into the printer's art. I think of Don Knuth, who was in the midst of writing this marvelous bible of programmers, and then, all of a sudden, off he goes and gets into a decade of close studying of the formation of letters. He still hasn't gotten back to Volume 4. There seems to be an allure. (laughing) What is that?

Kernighan: Well, I will say for Knuth, I think it's in a large part, a waste of great mind for him to spend a decade on TeX. It's not that TeX is bad, but it's a waste of Knuth. I mean, he's capable of much more. I think I understand it. It's seductive because-first the output is actually appealing. I mean, you can actually see its utility, and you get a chance to change something and see how it improves it. So, it's really appealing in that sense. The input/output relationship is really quite intriguing. The other thing is that-I think that in some sense, the problem area is a microcosm of everything you ever wanted to do with computers. It really has all of the interesting problems, but they're there on a somewhat smaller scale, so that one person can encompass it. It's relatively self-contained, and if you do anything useful, people are just really enthusiastic; they love to have it.

MSM: Were you learning things, as you were setting up this text processing system, about computing?

Kernighan: Yeah. You learn-

MSM: Or were you just saying that that had theoretical interest?

Kernighan: Well, yeah, theoretical is not the right word. But, it genuinely had computering science kind of interest, because what you're doing is, you're building compilers, right? But you're building small compilers. You're building them for relatively simple languages, which means that you don't have to face, in your language, all of the problems that may get difficult to build a compiler for a real, conventional mainstream language. For example, a compiler for eqn is several orders of magnitude smaller than the compiler for something like C, or FORTRAN, or something like that. So, the job is intrinsically simpler; there are a lot more things that you don't have to worry about. Yet at the same time, retains most of the interest. I think maybe that's part of it. Then the other thing is that it's kind of like many other things in computing; you get to go off and invent your own rules for the game. Especially if you're building languages, which is a lot of what I've done over the years. If you're building a new language for something, well, you can invent the rules. It's not like-if you want to go out and build yourself a new C compiler, you can't invent the rules. They're already defined for you. I think that's boring. So, but if somebody says "We need a new language to make it easy to talk about, you know, the way that medieval manuscripts have been illuminated," or something or like that. Well, gee, define your own rules, because nobody else has done it before. That, I think, is part of the charm as well. Before you set out to play the game, you get to define the rules, and if you don't like the way the game turns out, then you change the rules. That's always been part of the charm in computing, I think, building something out of nothing.

MSM: That's a mathematician's approach.

Kernighan: Well, in some sense, yeah. But it's different from at least pure mathematicians; there is, in addition, the reward of utility if you do it well. People come along and say, "Hey, look what I did." Maybe mathematicians don't get any jollies when somebody says, "Oh, I used your theorem." But I think people who write programs do get a kick out of it when somebody comes along and says, "Hey, I used your program." I know I do.

MSM: I think mathematicians-certainly when a mathematician's result unlocks someone else's problem for them, there's got to be an immense sense of gratification.

Kernighan: That's right.

MSM: Plus a validation that what one has developed is a profound theorem, when it begins to unlock other people's problems.

Kernighan: None of these things are profound, but, you know, they make life easier for people. They make it easier for somebody to get something done. So, I personally enjoy that.

MSM: Actually, one of the things you were talking about, that I hadn't thought about, is--typesetting things, which one tends to think of as graphical, is really about languages. Small languages. It's a question of how to capture a description.

Kernighan: The input side is small languages. There's a continuing debate between: is it better to have a linguistically, textually-based description of things, or is it better to have a visually, graphically-based description of things? People who have WYSIWYG editors will tell you it's much better to have it right there on the screen before you, and people like myself, who've grown up with, and are comfortable with, the textually-based tools, will tell you there are lots of things you can do with text that you can't do with the pictures. The truth, of course, is that it's a combination of both; each has its good and bad points. I think we started to make significant progress in a lot of these things when we started to think that what we were doing was building languages, because then you could start to think of using the tools that were around for constructing mainstream languages in these other areas. In addition, the artifacts that we built with these tools themselves, were in some sense cleaner and better, because they were linguistically- based. They became less of a collection of features and more implementation of a relatively coherent grammar and set of rules, and so they were easier. Early mathematics-there had a variety of people, I found out afterwards, who had built tools that were intended to make it easy to typeset mathematics, and they were always full of restrictions, like there shall be at most three levels of subscripts, and two of these and four of those. And the reason was that...

[END OF SIDE 1]

Kernighan: ...to build yourself a language, that a lot of these funny restrictions don't happen, because the recursive structure that that tool encourages you to use means that you tend to get things that just go. So, if you need seventeen levels of subscript on something, well, you know, it's no different than two levels of subscript. It's just more than one. And so a lot of these arbitrary, capricious restrictions, that showed up in things where somebody was building a program, sort of go away when somebody's building a language with an appropriate set of tools, because the grammar does not really make it easy to talk about restrictions-well, one or two or three-but encourages you to think of just an arbitrary number. It's not that you can't have an infinite number of subscripts; you'd run out of something after a while. But, it's not in the structure of the language.

MSM: Little languages: when did you start learning little languages?

Kernighan: I believe it was--I've forgotten his name, but in Le bourgeois gentilhomme the gentleman who realized he'd been speaking prose all his life. (laughing) I should remember his name, but I can't. In some sense, it's the same phenomenon. Somewhere, somebody asked me to give a talk. I looked back and realized that there was, in some way, a unifying theme to a lot of the ways that I had been fooling around over the years, which is that I had been building languages to make it easy to attack this, that, or the other problem. In some way, make it easy for somebody talk to the machine. I started to count them up, and gee, there were a lot of things there that were languages. Some of them were absolutely conventional things, some of them were pre-processors that sat on other things, some were not much more than collections of subroutines; but, you know, you could sort of call them languages. And they were all characterized by being relatively small, as they were things that were done by one or two people, typically. And they were all not mainstream; I never built a C compiler. They were attacking sort of off- the-wall targets. So, I said, gee, well, they're little languages. Then, once you see that, you can start to look for further targets of opportunity. Over the years, that's what I've done. You can push that arbitrarily far, probably too far.

MSM: The way you were describing it before, when you were talking about yacc, and about, when you see these things linguistically, but-I forget exactly what words you used-but, what it triggered in my mind was the sense that, what's come out this research group as a whole is a body of theory that seems particularly adapted to precisely this design of languages. This is the textbooks on the subject of language design, theory based language design-combinations of three things taken two at a time. (Laughing) I should say eight or nine things taken two at a time. But that all fits together, and on the one hand we say "Yes, of course." But, on the other hand, "No, not of course."

Kernighan: I think that there's-you could see the roots of it. The theory- based part of it goes back to Al Aho, I think, starting here-having just finished a thesis at Princeton on a particular class of formal languages, having worked with John Hopcroft, having had Jeff Allman as best friend all the way through graduate school-when the analysis of formal languages was the hot topic in computer science. Computer science didn't really exist in those days, but that was the topic. People were studying the properties of languages. So, when Al got here, he was still interested in that, and I suspect that there were times when his management would wish that he'd get off this damn language stuff and do something that mattered. Fortunately, in the best tradition, he never did. Then when he and Steve Johnson got together, and realized that it was possible-I guess they weren't the first people to make compiler compilers-But they were-

MSM: They were back in books-

Kernighan: Yeah. And the fact that Steve called it yet another compiler compiler suggests that this was again in the air. The difference was that this thing was sufficiently well-engineered that it was a practical thing for other people to use. It was not the personal research vehicle of Steve Johnson or Al Aho, but rather was something other people could use. And furthermore, that there were these collection of weird people around who actually wanted to use it, who were willing to use it, and stress it in ways that hadn't been thought of, and therefore make it a better tool. If you look back, maybe it was yet another compiler compiler. I'll bet you can't name another compiler compiler. That's the only one that has survived. It's still used, still used extensively, continuously. All kinds of people, lots of people still discover it, because the job sufficiently well done.

I think the reason was well done is, aside from the intrinsic brightness of the people involved, and the fact that they picked good algorithms and continued to define them over the years-I think it's the milieu of other people sort of banging against it, and trying things with it, and building things with it-build up sort of a collection of things, where you could look at it and say, "Yeah, this is actually useful stuff." It's not a academic exercise. It's genuinely a better way to do things than what you might have had before. So, this collection of people-enough critical mass, if you like-to actually prove the concepts, and prove them in the in addition to working the rough edges off them, and getting them to point were they genuinely practical tools. We use our own stuff, and I think that's a critical observation about this group here. We do not build tools for other people. We do not build anything for other people. I think it's not possible to build things for other people, roughly speaking.

MSM: In the sense that, you just sit and have other people lay out their specs, and then you build the tool?

Kernighan: Right. If I build something for you, even if you spend a lot of time describing to me what you want, and why it's the way it is, it's not going to be as successful as something where I personally face the problems. Now, I may live with you long enough that I start to understand what your problems are, and then I'll probably do a better job, but I think that we have historically done the best on building things that address problems that we face ourselves. That we understand them so well because we face them, either directly-you know, I face that problem myself-or it's the person in the next office.

MSM: This is probably one of those, either "chicken or the egg," or "a little bit this, a little bit of that" questions. What drives this, in essence, is that you're working on your own project, developing your own stuff, but you're also constantly calling on what other people are doing. So, as a result, you tend to reinforce one other's work and you're your own best critical audience. Criticism in the best sense, because you have a stake, not only in finding, but in making stuff work. Therefore when you find problems that are genuine problems-that block you-you want them fixed.

Kernighan: Yep.

MSM: One can see all sorts of things coming together now. You've got to have the right people. Those people have to be working on the right set of problems. And they have to establish a way of working with one another; one can image that happening of itself, or one can have a sense of its somehow being directed. Now, what is it that makes it work here? What is it that was making it work, back in the early '70's?

Kernighan: I don't think it was directed, or least if it was directed, it was done in an incredibly deft and unobtrusive way. Maybe management will tell you that that's worse....(laughing)

MSM: Surely.

Kernighan: If that is true then it is to their eternal credit. Now, I think, in a sense-I mean, Doug was management of at least some part of that. I guess Ken technically was in Doug's department, and Doug is superb that kind of stuff. Insofar as he manages it, he does by superlative constructive criticism at the right time, and by going out and trying your stuff and finding out where it works and where it doesn't work, and then telling you what was good about it and what didn't work. To a lesser degree, I suspect that, in some sense, we all do that. I don't think that this was done by any direct management, so we can dispose of that part.

Part of it is a confluence of really good people with reasonably good taste. Particularly Ken and Dennis, who, as far as I can tell, genuinely have truly deep insight, and at the same time, good taste, and at the same time, essentially very close to parallel taste, so that they don't get going in opposite directions. Part of it is happy coincidence, that technology had gotten just about the right point where you could get hardware-a machine to work on-where you didn't have to, in some sense, be beholden to other people. You didn't have to use that machine their way because they paid for it, or something like that; that you could have something that's sort of your own, so you could furnish your computing world the way you wanted it, the way you are comfortable with it. If I want to go off and run on a big IBM machine, there's no way I'm going to be able to do that, because I can't afford it. I'll have to do it the way which is provided by somebody else, because they paid for it, they call the shots. But, if it's a machine that's my own, then I could run it the way I wanted to, assuming I have the technical background to actually make it work. It's some combination of those things, and it would be nice to know precisely what makes it work so that you could clone it. But, my guess is that it's-in a sense, almost an accident. You could see other places that have had that same kind burst of stuff. I think Xerox PARC went through a phase like that, in roughly in the early seventies, where they produced a bunch of really, really good stuff, with a different working style, to some extent, but again, it was a combination of things that led them to produce genuinely innovative stuff that's had a effect on everybody.

MSM: You know, I was talking with Shedell. The guy that did the Paintbrush program, the first Paintbrush program. I just happened to meet him at a reception at the computer museum at Boston. We started talking about Xerox PARC: how did you get your assignment and what was your mission? You know, there was a great deal of similarity. Well, it was sort of a general mission to do interesting things and hope they work out, but look around for something interesting to do and get going on it. He said he was given two years to find something to do. He sat there and he played with Paintbrush, which he had done back in '73, and it was brilliant.

When did you become the group's scribe?

Kernighan: I think at some point fairly early in game, I started writing tutorials. Sort of, how do you use it? Gerry Markey, who is now Sandy Fraser's secretary, said to me one day, "I don't really understand how to use qed," which was the text editor, and I said, "Well why don't I write down something that will, sort of, tell you how to use it." And I wrote a tutorial on qed. Now, I don't know if it ever did Gerry any good or not, but a lot of people found it useful. It was a sort of, here's how you get started on this kind of stuff, and it was a particular style of writing that nobody that else seemed to be interested in doing. Which was sort of-not a manual, but a "how to do it" tutorial. No better word.

I had already written one of those for my little formatter at Princeton, in fact, so it wasn't the first time I had done it, but this was, I guess, the first time I, sort of, consciously did it. I did several like that. I did one on B; the one on B mutated into the one on C, which then mutated into a C book. And, you know, a variety of others. I did a "cave guide" to the Murray Hill computer center, an underground guide to the Murray Hill computer center, which was (laughing) sufficiently against the received wisdom that they didn't want me to publish it. But I published it anyway. Which was, sort of, one of the useful programs, as opposed to the ones you will find in the manual. That kind of stuff. I guess, from there it's not too big a step to writing things that describe what's good about the operating system, or the environment, or the way of doing things-these sort of pseudo-philosophical papers that explain what you could do when you connect programs together, and what you could do when you had a programmable shell, and that kind of stuff, which, where I took basically one paper and probably wrote it about fifteen times. But that kind of thing. So, I think that's part of where this writing came from.

The other aspect was book writing, which in the long run is much greater effect. I think you have much more impact if you have a successful book. I still remember quite clearly how I got started in that. I was enormously lucky when I came here the first summer to be in the office next door to Dick Hamming. I'd heard of Hamming codes because I had taken a course in coding, error-correcting codes at Princeton. I was sitting in my office the first day, as we are sitting here, and this guy came in from next door at eleven o'clock and he said to me, "Hi, I'm Dick Hamming, let's go to lunch." I said, "Well, okay," and he dragged in Vic Vyssotsky, who was right across the hall from me, and we went off to lunch. Later on I discovered, this was the famous Hamming of Hamming codes, and the numerical analysis book that I had used the year before. I think a lot of people had trouble with Dick because, he was one of these guys who was absolutely outspoken, and not afraid to give you an opinion on anything, and usually sort of a controversial, rock-the- foundations kind of opinion. But, I didn't mind. That was fine, and he was a nice guy.

One of things that he was fond of saying was that programmers don't know how to write programs. The way we teach programmers how to write programs is we give them a grammar and a dictionary and we say, "Okay, kid, you're a great writer." That's the way programming was taught according to Hamming, and there's a grain of truth in it. He said, "What we really need is a book of style; here's how to write well." I don't remember in detail, but his idea of how to write good programs was, I think, pretty half-baked at that point. But, one day he came into my office and he handed me a book and said, "Look at this!" (searching for book) I don't think I still have it down there. I used to have it. It's probably down there somewhere. He handed me this book, and he said, "Look at this! This is awful!" It was a FORTRAN program. It went over two pages. What he was talking about was the numerical analysis in this thing, but what I saw, when I looked at it, was this horrible piece of code, which is the first example in the Programming Style book. I looked at it, and said, "Jesus Christ!" I wrote on it in green, "Jesus Christ" (laughing) and then it occurred to me. I know what I can do, because I had somewhere stumbled across Strunk & White, which is basically an "awful, good, awful, good," you know, side by side. You could make a book out of that. You go off and you find awful examples and you show how to do them right. Bill Plauger at the time was in the next office, and he kind of got intrigued by the idea. So, we went off and we hunted the libraries, all the libraries, all of Bell Labs' libraries, and any other place that we went. Bookstores and everything. And we found awful examples, and it was easy to find them. There were just zillions of awful examples, because every programming textbook was awful. We went off and wrote-basically just collected these, tried to get them in a coherent form, where an example would illustrate some principle or guideline on how to write well. Then we just threw it all together and wrote a book. It was, I think, certainly a fun book to write. (Laughing) My wife said to me, "You found your ecological niche."

MSM: I've been looking for a copy. I can't find it anywhere.

Kernighan: I'll find you one. I can probably do that. (searching for book) I'm sure I have one down here, somewhere. Fun book to write, and I think that's how got I started in book writing, at least. Then Plauger and I wrote the Software Tools book shortly thereafter, and then I browbeat Dennis into working on the C book with me.

MSM: You just found you like to write?

Kernighan: I like to write-ultimately, it was deemed to be good thing at the labs. I think when I first wrote that book, it was deemed to be neutral. It wasn't like a positive thing, but I'd only spent about three to six months on it, so it wasn't a bad thing either. It was just a neutral thing, and it was only sort of retroactively that it was deemed to have been a good thing. I think Plauger got fired for writing it.

MSM: I want to talk about where he went in a second, but there's an obvious question. When someone takes other people's style and says, "This is the way to do it," and when you talk about its being relatively easy to find examples of bad code writing-where did you learn to write programs? Where did Plauger learn to write programs, that your style is good style?

Kernighan: (laughs) Well, it's not clear the style is good style; it was better than a lot of the programs that we found in textbooks. All of the examples came from textbooks, and they were-I mean, we clearly picked on the bad ones. It was embarrassingly easy to find bad ones, because a lot of these things clearly had never been thought of. Many of them have never been executed. I think a lot of them, the professor wrote the book and said to some of his students, "Why don't you write programs that will answer these exercises?" and then stuck them in the back of the book and never looked at them, and a lot of those were just-they couldn't possibly work, and others were just really bad. You didn't have to look very hard to realize what was bad, and from that, you could start to infer what might be good. I don't think our rules of style are very deep or anything like that. But, we gradually evolved a set of-well, rules, not in any formal sense, but little detailed rules that corresponded to getting your commas in the right places when you write sentences, and realizing between "which" and "that," those kinds of things-and move up to grander things, that relate to the structure of programs.

MSM: Was Strunk & White more than just an inspiration, or was this-did you read through Strunk & White, think in terms of Strunk & White when you were doing this? You just used an example from it.

Kernighan: Yeah. I think that Strunk & White was an excellent example of something that we didn't consciously-I think we must have consciously taken them as the model, because, the sort of side- by-side, "Here's a good one, here's a bad one, here's a good one," and what did we do to get from one to the other, is definitely what we did there. It's not the same, because English is not the same as writing programs. But there's an awful lot of commonality. I still reread Strunk & White every couple of years just to refresh my memory, what they think about good writing, because that's still the best English style book I have read. The other thing we tried to emulate was the brevity, because I think long books are not necessarily better than short books. In fact, they are sometimes worse.

MSM: Try and convince my grad students of that.

Kernighan: There's lots of reason to believe that short is better. (laughing) If nothing else, even if it isn't better, there isn't so much of it.

MSM: You started out using FORTRAN, the old FORTRAN, which is not a structured language. You spent time optimizing, writing an assembler. Ultimately you made a transition to what might be called structured programming, and Plauger went off to work for a company that is probably the standard bearer of the structured approach to things. Was that a conscious transition for you? Or, did you think of it as a transition? Was there a time in which Dijkstra was on the shelf here?

Kernighan: Yeah. It was-structured programming, and programming without goto's and all that stuff was definitely very much a topic of discussion at the time when Bill and I were working on this book, and noticeably before. Quite a bit before. We wrote a couple of papers before we got into the book, or concurrently with the book, I guess. I remember, somebody or somewhere, I was introduced to the notion that you could write a program without goto statements if you had the right kind of language, and B was the first example that I really used where that was a possibility. And so I set myself the task of writing a particular program-something that just reported on job status on the Honeywell machine or GE machine-I set myself the task of writing that program without any goto statements. I said that this would be my test case, and it was a program that ultimately wound up with, I don't know, six or seven hundred lines of code. I would write it without goto statements, and I found it an incredible bitch of a job. I finally got it down to three, and I was quite proud of myself. In hindsight, you know, fifteen, twenty years later, I cannot image what the problem was; how could it be so difficult? Because I just don't do that anymore. You know, it's like training yourself so that you always get "which" and "that" correctly. You don't think about it anymore, and you don't realize it's an issue, you just do it correctly. In that sense it was conscious for me. I had to work very hard to get to a particular level, where then, after a while, it became completely unconscious. And there were other kinds of programming, things that go along with-

MSM: But you were rather persuaded by the virtues of doing so?

Kernighan: I think so. The first big program I ever wrote, truly big, was a COBOL program. COBOL programs are sort of the antithesis of structure; in fact, the only way you could write a COBOL program is basically to make it unstructured. It's just awful. And I still remember, the way that I wrote that program was, every time I had to make a decision about something-is this bigger than this?-then I'd say goto, I'd invent a label, and I had this steadily increasing frontier of things I hadn't figure out how to do yet. (laughing) The program just grew without bounds, and I never finished the damn thing. In retrospect, it's the kind of program that I could probably have written in a hundred lines in a decent language, and it was just-it was literally over ten thousand lines at the point where I quit, at the end of the summer. So, in that sense, I was convinced that, at least, just pouring in these goto statements was wrong. Looking at some of the examples in the textbooks, it was clear that was wrong. I'm not sure that I believed Dijkstra in any pure sense. I really don't remember when I first read his famous letter to the editor; it was probably well after I had been doing this kind of stuff for a while. A lot of that's just blurred.

MSM: I started doing this going back to school in '82. I was taking a Pascal course, and I learned to program directly, in machine language, or-I guess we had alphanumeric-no, it was 074, it was clear and out. You just had to know what the codes were. I remember the first time we were supposed to have a branch decision, having to search out, have to go see, and I said, "Where's the goto?"

Kernighan: (Laughing) Yeah. Right.

MSM: They said there is none. You're not supposed to use it. And then, they explained what this was all about, and then I remember getting Wirth's book, and looking at it, and it's got goto's. It usually has goto's, at least to the error, so he gets all his errors together. So, here's the ultimate structured programming language, and there's the author of it using goto's. Like most truths, it lies somewhere in the middle.

Kernighan: There's a great line in Strunk & White about, you know, you'll find places where the rules are broken, but you'll find some compensating merit to make up for it.

MSM: Well, there's Winston Churchill's remark about prepositions, that it's nonsense up with which I were.

Another aspect of structured programming, at least the approach that you were talking about before, is this use of recursion. I remember when I was reading the proceedings of the Garmisch and Rome conferences, and I remember now, someone saying something like, everybody recognizes the virtues of recursive procedures, and yet, no operating system, no large software system program, uses them. And it was in Holmdel, someone handed me a-rules for programmers from another project, and one of the rules was no recursive procedures. And yet, the Unix systems were-seemed to take-what was going on there?

Kernighan: I think that there was, for a long time, a conception-perhaps originally based on fact, but laterally not at all-that recursion was in some way expensive, and therefore you couldn't use it; that a recursion procedure, if nothing else, it was another procedure call, and therefore procedure calls were more expensive and therefore you couldn't use it. Now, it wasn't a issue in FORTRAN, where you couldn't recurse, but it was in PL/1, where you could recurse, and PL/1 function calls were notoriously expensive because of the language design; it sort of forced you to carry around incredible baggage to actually say what the arguments were as you went along. So I suspected it came from that fear that, when you-any extra function call was going to cost you a lot, and recursion was intrinsically function calls in place where you didn't have to use them, and therefore it was a bad idea.

MSM: Was call by value in C? C's calls are very spare. Was that it was there for? To support recursion more easily?

Kernighan: I not sure it was to support recursion. I think it's simply to support function calls, because functions, breaking up the job into smaller pieces, I think is necessarily a better way to do things. But, if you're going to that, you want to make sure that they are efficient. I think in part it was a reaction to the PL/1 stuff, where functions were so expensive that people tended to avoid them. And they don't have to be expensive, they can be quite cheap. In fact, there was a lot of effort devoted over the years to various ways to make the function calling inexpensive so that people would be encouraged to use it. C compilers to this day go to some effort to do that. And furthermore, a lot of that is reflected in the machine architecture, where the machines themselves drive the subroutine call, mechanism cheap. Part of it was just the machine. A machine like, say the IBM 360's, 370's, the subroutine calling mechanism was actually intrinsically expensive; it was badly designed in the machine. The machines like PDP-11's and their derivatives, the function call mechanism is actually well- defined, and it's comparatively cheap, because basically, the machine supports the notion of a stack in some way-the auto- incremental structure is one, manipulated stack made it easy to get in and out, and there's even a-A del had a subroutine instruction; the question is, what do you have to do before and after it? The DEC machines just did it right, and IBM machines just did it wrong.

MSM: Have the, just following along those lines-you said earlier something along the lines that, it was the right moment, the hardware was coming along. Is there an extent to which this development, maybe its timing, or its pace, has been hardware determined? To what you had available? Or has it reached the point where it's now beginning to influence hardware design?

Kernighan: Certainly the original development and pace, I think, was very strongly affected by the hardware. The PDP-11, I never programmed it in assembly language, so I can't speak intimately of that, as Ken or Dennis could. But, my belief is that, from a programmer's standpoint, as a dream machine-that's really a very, very nice machine. And from an economic standpoint, it was kind of a dream machine too. It would fifty thousand dollars fifteen years ago, and that was manageable. That was something where a group of ten people could justify spending that much money. It was an order of magnitude cheaper than existing machines that you could buy and you could use for something So, I think-and furthermore, it was available from a real manufacturer, somebody who existed, who was in some ways comparatively easy to deal with, certainly much easier to deal with than with IBM; and a manufacturer that, perhaps, because of its origins, made it easy to connect interesting widgets to the machine. A lot of things combined together to make the 11 a very attractive machine. IBM always played it very close to the chest about what you connect to their machines; you had to have these elaborate channel things. It was just horrible. DEC machines, you could just plug in stuff. It was a whole industry of weird things you could connect to DEC machines, all of which made it substantially more interesting. And the fact that it was small enough that a university department could buy it-it made it spread. So, it got to the point where, the combination of the attractiveness of the hardware and the fact that there was this attractive software that you could get, almost for free, to go on it, meant that large numbers of university computer science and related departments would go off and buy the things, and run them. I think the VAX carried on the tradition, although the VAX is probably, today, excessively pricey for what it does. But, I think what we're finding now is that the portability aspect of Unix mean that in some sense the hardware is almost irrelevant. There are certain kinds of hardware where Unix and C are not going live comfortably. But, for the most part, the hardware is almost irrelevant. I think that, in some sense, is a giant leap forward.

When I first got into computing, and for the first ten or so years, up until the mid '70s, at least, the arrival of a new computer-you were going to go from GE to IBM, or from UNIVAC to Data General or something-that was just a trauma beyond words. It would months--it would take years-to make that adaptation. It doesn't happen that way anymore. Things are-I mean, you still spend a lot of time as you move from one machine to another. But, it's a different-it really is a different order of magnitude. We've slipped in several new machines locally, and a lot of the software, you just compile it and it runs, and the operating system environment is essentially identical. You type the same commands, they behave the same way, the shell is the same; it's the same. That, I think is a tremendous step forward. I don't know whether that relates to your original question, which I've now managed (laughing) to lose from my neurons, but-

MSM: No, actually, it's always seemed to me it's sort of-a bit of a contradiction that, the most popular host machine for Unix, during this period of rapid spread, was the DEC PDP-11, or the VAX, which is just an extension of the 11. You can look at the manuals, and it's one of the richest instruction sets, I think, that's ever been put on a machine. I mean, you've got an assembly language routine for evaluating polynomials, and all the packed array, decimal packed array stuff--it's fun to go and play with it. Sort of an assembler programmer's playground. I can see the attraction of doing it.

But also, the ethos of Unix is you stay out of assembler. You don't program in assembler. You use C, and you try to keep the assembler kernel down to just what's necessary to get things up and running. If I understand it correctly, it's right there in the bootstrap command. From there on in, you address it in C, and though I haven't looked at the C compiler, my sense is that, for portability concerns, if for no other, one would say they're a pretty restrictive set of assembler routines, and that in many ways the RISC architecture is better suited in the Unix system, than this extra rich instructions set. That's what led to-the instruction set on the VAX says, wasted if you run Unix. And the irony is that two-thirds of the VAXes are run on Unix.

Kernighan: Yep. Absolutely.

MSM: (Laughing) That was meant to be a question; obviously it failed.

Kernighan: Well, I believe what you say. I don't think that people write assembly language on most machines that run Unix, except for some tiny thing that they can't get at any other way. I have not written an assembly language program in eons, fifteen years probably, and never to expect to again; I hope never to have to. You're right; most machines provide a very, very rich set of instructions, most of which are inaccessible from your favorite high level language, whatever it is. Now, packed decimal is presumably there for the benefit of COBOL, right?

MSM: I don't know, (Laughing) I never could understand what that's for. I simply took Peter Huntington's challenge once, to do something in packed decimal arithmetic. Pain in the neck.

Kernighan: But, you're right. There's no compiler in the world that's going to generate the Horner's rule instructions. It just isn't going to happen. Poly-q or whatever it's called; it's just not going to happen. So a lot of the effort that goes into to building that kind of complicated architecture is totally wasted. The RISC architecture is, insofar as they are uniform, are a better match to what you likely want out of your favorite compiler.

MSM: I've run out of questions for now.

Kernighan: What are you doing for lunch?

MSM: Nothing.

M.D. McIlroy

Friday, August 18th 1989

MSM: I was looking over some of the literature and one of the things that struck me as I was looking back at Ritchie's retrospective and other retrospectives of it, are the circumstances under which it got started. I gather that the name UNIX came from Brian and it came in '70 and it was a play on MULTICS. And the more I read the literature the more MULTICS looms behind UNIX, both positively and negatively. What was the relationship there?

McIlroy: Ritchie, Thompson and Osanna, and Peter Neumann, and I were all in on the MULTICS project from the time Bell Labs joined. Ed David, who was Executive Director of (ocean? --not clear) sciences, I guess it's called. And Later on went to be Nixon's science advisor.

MSM: Go ahead.

McIlroy: Was really pushing for this MULTICS project but (it was) the dream of the computer utility that just grabbed him. And he alerted people to join in and meet with MIT and start laying plans and early people doing that where including Masowski. Osanna and Neumann were particularly turned in on the project and devoted time to it. I would say the rest of us were in on the project and dove in with a will and did a lot of design work.

But, perhaps were not quite as confirm believers that this was the wave of the future. Nevertheless, we devoted an awful lot of time to it. When MULTICS began to work, the very first place it worked was here. We had our GE 645 machine. MIT, had one too. But, they were doing their development on another machine, carrying tapes across and just taking measurements, making tests on the MULTICS machine. As soon as we got a tape, we tried to run it as a computing home. Thompson, so in the day, we would have a MULTICS machine running. Fitfully. It was amazing how three people could absolutely overload this giant room full of equipment. And that was because MULTICS actually changed the way people worked. The MULTICS user was not the same as a user of previous time sharing systems.

And the principle reason was that he could do multiple things at a time and that he could be typing ahead of where he was working. Previous ones had been strictly half duplex. You typed for awhile and then you waited for the computer to respond. MULTICS went full duplex. It was amazing how this one tiny little change, absolutely permeated the way you use the system. And that and the fact that you could very easily set things going in the background. So, any one user could start several things going, and when the machine was slow, that's exactly what you would do. Your mind would be racing way ahead of the machine. And that just brought it down even worse.

So, MULTICS was clearly... once it was running was not the boon, that was going immediately solve our need for computing cycles. Three people could bring it down. Also there developed a wonderful Multics system programmers manual. An eight foot shelf or something. I don't recall how long it was. Nobody here had a complete copy. Volume after volume of design documents. Very daunting. Thompson and Ritchie and Rudd Canday, who was an intern in my department for a year, were talking about, well, how could we do this in a less massive way? And, there were many afternoons spent across the hall there. Working at the blackboard. Working out the design of the MULTICS file system. I'm sorry, the UNIX file, what became the UNIX file system. If we were to make a file system, what would it look like?

MSM: Let me interrupt you for a second? What is it. Was it the file system that made that MULTICS so big and daunting?

McIlroy: It was the... The real reason for the... one already knew why time sharing was such a boon. It wasn't that it allowed many people to share the cycles in the machine. It was, that it allowed many people to work in the same huge pot of data and it was this synergy of sharing data, to be able to quickly look at other people's files, pass messages around and so on, that was the best thing that time sharing had to offer. The other was merely a economic advantage, but the one of sharing was a qualitatively different way of using the machines. So, the file system was the heart of the matter. And

MSM: Oh, so it was the idea of sharing?

McIlroy: Yes.

MSM: And, making it easy to share?

McIlroy: Yes. And make it easy to find; to store away and retrieve information. The UNIX system owes much to the MULTICS file system, most notably the directory tree ID.

MSM: How many of these design features of MULTICS, had sprung from you people in the first place? Or did you ...?

McIlroy: The basic concepts of MULTICS really come from MIT. We joined the project after they got started. And it was going to be the follow on to their CTSS and talked about it for a long time. One significant design thing for MULTICS came from Vyssotsky. MULTICS had these two ideas; the file system, and the segmented address space for processes. And they were separate. You would do IO from files into the address space. Vyssotsky said, "Why don't ..., why are not files exactly the same as segments? And there is no...; an IO disappears. Well in fact FORTRAN programs still have read and write. But, when you open a file, all you're doing is putting a segment in your address space. MULTICS really worked that way.

And our later systems have backed off from that wonderful unifying idea. There was, in the working out of the idea, there was a great deal of overhead. The other big thing of MULTICS was the idea of dynamic linking. And what that imposed upon the rest of the architecture, was, I'm sorry, I should say dynamic linking and the so called ring structure for memory protection. The various layers of access permissions. All the collection of those things together, the hardware was conceived to support those, but it was our first cut. The collection of them together turned out to be take a great deal of implementation to make them work. One of the surprises late in the project was.... So you got automatic... (back up). The way the shell worked. When you invoked a program, what it did was simply link the program into your address space and run it right there. Suppose you recompile the program. It's already in your address space and you run it again, and you run the old one.

And, how to undo. There is lots design effort that went into the binder. Then. Then nobody thought about unbinding, which turned out to be something that had to be put in later on. And unbinding turned out to be quite a big monster. Especially, to have unbinding occur in any... people really didn't like this idea. So, I rewrote the program and I got the old one and you would like that to happen. You get the latest version automatically. It took a great deal of implementation. This kind of thing, mushroomed and the system got huge.

MSM: What did MIT look to get from Bell Labs in that project? ... what was your role?

McIlroy: Why was Bell Labs part of it?

MSM: What were the expectations in both directions?

McIlroy: MIT had the basic vision of the computer utility, in those words. And Bell Labs certainly was a window into getting that out of the academic world. I suspect that would be the principle motivation for having Bell Labs in. Of course Bell Labs too, had a good reputation for having built interesting operating systems for many years. When, for example, IBM came out with a 709/7090, which had data channels. We. It was in the market for well over a year, before we got one. Probably a couple of years. But, we built our own operating system for it. Similar to the one we'd built for the 704. We used the data channels and it did asynchronous I/O. None of the software that came from IBM used the data channels any way...

Although the hardware was there, but it didn't exploit the software. So, we were in there exploiting the hardware and the data channels interrupts all that. First, when the disk drives were announced as a product. Lots of people put them on. But, we were the first people to put them into a file system where you could leave your files. So, Bell Labs did have plenty of background in creation of operating systems.

MSM: Where you part of that?

McIlroy: Yes. I was not part of the 704 operating system, which was built before I came to work here. But, the 7090 operating system, was I certainly was. Although the two principal players were, Ron Drummond and Gwenn Hanson.

MSM: So, what you joined was a continuing tradition of building your own operating systems?

McIlroy: ...of building our own operating systems, absolutely. And this was... everybody agreed that operating systems could do multiple things at a time, were the next step and MULTICS was let's hope in that direction. It was multiple in every sense. As its name indicated.

MSM: And the Labs hoped to get a share on that?

McIlroy: Well, the Labs was looking for... to move to a new generation of equipment and a new way of using it, and here was a way. It looked like that might be a very big undertaking, because operating systems, although they had been built by two people here, back in 1968 uh '58. You found more and more people when you looked outside at the ones that were built around '64 and you find that there were fifty people building them. Maybe too much to be doing in the corner of the math department.

Of course, what UNIX showed after that ,was that two people could still build a operating system if they had the right model. So, we had MULTICS in the background. Ken Thompson, very quietly, in the wee hours, would take the machine when nobody was on. Would take the machine down, was building his own operating system, for the giant 645, starting from scratch. He got to the point, where actually he came up to the console and said log-in or something like that. I do not know, what the architecture of that operating system was.

MSM: He was just doing it to explore operating systems?

McIlroy: Yes. He felt he could do it with far less fuss and bother than the megabytes that had been written for MULTICS.

MSM: So, you really were disappointed as a group in the way MULTICS ended?

McIlroy: I think that's true in most of us. Yeah.

MSM: And so it just petered out?

McIlroy: No. We were still working. But, (pause) the computer centers had been put up the money for the machine. The computer centers by now were, separate from research... that happened some time during the MULTICS projects. The computer centers, hoping to get something out it, and with big budgets research had never had computers of their own. Computers always belonged to the Computing Center, which once belonged to research. The computer centers move away, research is left as clients. Only no hardware and no capital budget. Well, the computer center began to see that this was not going to provide the cycles that they were going to need in the next couple of years.

MSM: No. I see three people can bring it down. This is not the answer to their needs.

McIlroy: They needed computing cycles. They were selling them. They had this million dollars worth of equipment up in the attic, that was sitting there being played with by three folks and the day that it was going to make into the comp center. We did have some fairly interesting assessments of what it could do. I think, I still have those up on the shelf. Where various people predicted when MULTICS might become useful and how useful it would be. You'll find positive and negative things written about it. I could get that kind of stuff out for you if you're interested. It's MULTICS, its not UNIX.

So, it became clear that we were a drag on the computer center's budget. We were not going to pull them out of their hole. You know, in the near future. They were going to have start buying hardware and go with whatever was in the market at the time for operating systems. And the project was, it was a clean sharp decision made to get out. The project did not wind down, it just stopped.

MSM: When was that?

McIlroy: It was in 1969. I forget what month, and the astonishing thing is that we had a visit from the President, Bill Baker himself. To tell us about the turning off of the project. And he poured wonderful vacarian oil upon the waters.

MSM: I've seen him in charming action (Laughing)

McIlroy: As we still often proposed, in Vietnam, he declared a victory and retreated. (Laughing) The research value of MULTICS was declared to have been... the research potential of the MULTICS project was declared to have been exhausted. So, we would get out of it as a research project.

MSM: I gather it was about the same time the research group got split into two halves, mathematicians and computer research?

McIlroy: That had happened about '67 or so.

MSM: Had that split come simply because things were getting too big?

McIlroy: Yeah. I think so. There were two degrees of split. First split was, computer research left math and kept the comp center. And fairly shortly thereafter, the comp center left research entirely and went over to a more operational department.

MSM: You were computing research, but you didn't have any computers?

McIlroy: That's correct. Visual and acoustics research had computers and they had them for some time. They were really, they wanted to listen to signals in real time and make digital filters. Simulate digital filters and stuff like this, and they could eat up all cycles of a machine. So, they started getting little, they were the pioneers of minicomputers at Bell Labs. They had some that were stuck on the side of our 7090. The Packard Bell 250 was the first one they had. This guy could reach in and grab cycles off the 90, or run a collection of interesting acoustic gear on the side. Gather digitized tapes which would then be moved immediately to the 90 and processed. Perhaps, that was the first workstation, I think the Rand Corporation had some more or less at the same time frame, the early sixties. As more minicomputers became available, visual and acoustics research kept getting them. Now, we would look at their... there was interesting observation back and forth. They had nice hardware, and we would look how inefficiently they were using their cycles. You know, do a little improvement in your software and you wouldn't have to have all these machines. They broke the ice for minicomputers. And, because they really didn't like making software, instead when things got tough, they would just buy another machine. And if things got a little faster, the machines got a little faster, they would just throw out the old one and that was the origin of the PDP7, which ...

MSM: Where is this famous PDP7? Does it still exist?

McIlroy: Long gone. That was a graphics engine, put together by Bill Nidke and Ed McDonald, Ed Setarp and some others. It was a graphics engine with a really very nice display on it. A display with a program display list, so that you could have graphics subroutines... and it was more, it had been displaced by an improved graphics engine, which was sitting idle and that's what Thompson grabbed on and built, finally built... fairly soon after the UNIX shut off, and I think he was happier doing that than he was, trying to make the GE645 do its thing.

MSM: Now, you people must have been in something of a bind? When you were a computer research group. You haven't got computers. Were you looking around for a mission? Did you have a mission?

McIlroy: Oh. We had, we still could work on the... We had always been associated with the comp center. We still had good times with the comp center. If we produced interesting compilers the comp center would install them. So, we had the computing cycles down there in principle. But, they were not at your fingertips, the way we got used to after having CTSS at MIT available to us for some years. From '66 on, we were connected to CTSS from here. This little machine came up and Thompson brought up his operating system, and Ritchie joined in, and I saw that it was a neat thing and I was the department head, so I muscled in, and they turned it from a one user to a two user system.

MSM: What were you doing at the time when this caught your interest?

McIlroy: Well, I had been the languages person for MULTICS. Bob Morris and I wrote the PL/1 compiler, and MULTICS was all written in PL/1. That came about, because I was on the IBM share PL/1 committee. So, I had. We were looking for higher level language to program MULTICS in. This was not a first. Boroughs had programmed the B5000 in some dialect Algol. But, that pretty well. That wasn't good enough for. It really wasn't too well suited to nit picking algorithms that go into a operating system. The PL/1 had everything you needed, and a lot more.

MSM: Did you like PL/1?

McIlroy: The answer is, not very much. Even I helped design it. It was a neat idea to put everything that was known about programming languages into one pot. (Laughing) Almost everything. But, they didn't melt together very well. And I have only written one PL/1 program, in my life, after having designed it and built a compiler for it. Which says something about the language. The compiler was built in TMG compiler writing system, that I had taken over from Bob McClure of Texas Instruments, and then improved a good bit. The two of us built a very large portion of PL/1. We left out all the I/O, which turns out to be half, if you look at the grammar of PL/1, half of the grammar is about I/O, so that really cut off a lot. We left out the I/O. We left out parallel processing, and we left out almost nothing else, including some very elaborate data structure handling. Self describing structures and so on, which IBM didn't have in their first release. Uh, compiler. The compiler, the two of us built in about a year and it was used for several years before finally being replace with a real one. This compiler had two diagnostics. The syntax error and the other was redeclaration. (Laughing)

MSM: Sounds like BASIC. (Laughing)

McIlroy: But, to build the compiler, we had this TMG compiler writing system and that one being a huge language, stretched into its limit and we kept, every once in awhile we'd fill up all of the memory and now there were two choices. You would work on the compiler. Or, you would work on the compiler compiler. And we had both at our disposal. Went back and forth, squeezing out one or the other and out of this, I got an idea of how TMG really ought to work and that's what I did on the PDP-7. The first thing I brought up was from absolute scratch. We had an assembler only. I brought up a compiler writer, a compiler compiler. Written in its own language. Bootstrapped it up.

MSM: Now, is that TMG or did you do that in B?

McIlroy: It was TMG. TMG was a gun in itself. There was no B. There was no C. There was an assembler.

MSM: One of the sources talks about roff having come from run off.

McIlroy: Yes.

MSM: Which you did for MULTICS?

McIlroy: No, roff was done by Jerry Salzer and MULTICS, he invented it. I'm sorry for CTSS.

MSM: And you got up roff here?

McIlroy: I wrote roff for MULTICS, yes that's true. That's correct. And I wrote that in BPCL.

MSM: You got BPCL?

McIlroy: Dennis Ritchie had brought BPCL up on our machines.

MSM: He brought that in?

McIlroy: Mm. Hm. (yes)

MSM: Was B ever used in MULTICS?

McIlroy: No.

MSM: So, that history of BCPL, to B to C, is it all here?

McIlroy: All here.

McIlroy: And TMG fed into that too. Some of things like the two address assignment operators were in TMG here first and then were adopted by B, and by C. I can't say I invented them because they were also on Algol68 at the same time. B is where the unusual declaration syntax of C came from. That was Ken's invention, that the declaration should look like... should have the same syntax as an expression.

MSM: Since we're on C. One of the... I'll ask Dennis this when I get to it, but one of the features is, that struck me about C was when I was writing a LISP interpreter form, in it. This property of C, of always... of any statement bringing back a value, in the type, so that all operators have values and so I found that at a certain point my core C list was beginning to look like LISP expressions and at a certain point it just seemed automatic to go over to a LISP library. Because, I was just stacking parenthesis in C. Where did that come from? Is that part of B? Or... the notion that all operators have values?

McIlroy: Yeah. It was also in Algol68. In BCPL, which came out of CPL, they had the very, very strong distinction between notions and commands. An assignment was a command. So, they did not have... I do not think the assignment was an operator in the expression. But, it was a Algol68. So, that was in... So that happened sort of everywhere at the same time. In fact, the first place I saw it was McClure's proposal called Linear C, which was way before the language C. Just liked it because it sounded nice. Like after Linear A and Linear B.

MSM: Oh I see, I see

McIlroy: It was an obscure looking language and it was linear, because you wrote tremendous long expressions.

MSM: Must have placed you on the borderline between a procedural and functional list?

McIlroy: Yes. It did. In roughly speaking what it had was a break in the continue statement. Continue simply went back to the last parenthesis, and Break simply jumped over to the next one, and those were the major contributors, plus an IF of course, those were the major controls in a language. So, there wasn't an actual key word FOR. Just the fact that you said Continue, meant you would jump back.

MSM: Let's jump ahead for a second.

McIlroy: Yeah.

[some chat about whether the machine is recording, red light, etc.]

MSM: I was talking to my daughter, who's a computer science/music major at Harvard, before I came up here. She said, "What's the name of this project?" Well, it's the oral history of UNIX. She said, "That's not particularly jazzy." (Laughing) "Can't you think of a jazzier name?" and she said, "Who are you going to talk to?" and I said, "Doug McIlroy." And she said, "Well, what did he do?" I said, "Well, he had something to do with pipes." She said, "Why don't you call it Pipe Dream?"

MSM: I do want to talk about pipes, because Ritchie says in his retrospective that, not only was it your suggestion, but indeed, he suggests, at your insistence.

McIlroy: That is one of the only places where, I very nearly exerted managerial control over UNIX, in pushing for those things. Yes.

MSM: Why pipes?

McIlroy: Why pipes?

MSM: Where did the idea come from?

McIlroy: Goes way back. There was... in the early sixties, Conway wrote an article about Co-routines. Sixty-three, perhaps in the CACA, I had been doing macros, starting back in '59 or '60. And if you think about macros, they mainly involve switching data streams. You're taking in your input, you suddenly come to a macro call, and that says, stop taking input from here, go take it from the definition. In the middle of the definition, you'll find another macro call. So, macros... even as early as '64... Somewhere I talked of a macro processor as a switchyard for data streams. Also, in '64, there's a paper that's hanging on Brian's wall, still. He dredged out somewhere, where I talked about screwing together streams like garden hoses.

So, this idea had been ironed on in my head for a long time. On MULTICS, Joe Osanna, who was actually beginning to build a way to do input-output plumbing. Input-output was in interpreted over this idea of the segmented address space in the file system, really... files were really just segments of the same old address space. Nevertheless, you had to do I/O, because all the programming languages did it. And he was making ways of connecting programs together. They were fairly kludges and no one really exploited them, because you had to explicitly say connect this to that, and that to that. Nothing so nice as to piping operator in the shell appeared. And, at the same time that Thompson and Ritchie were, on their blackboard, sketching out their file system. I was sketching out on how to do data processing on this blackboard, by connecting together cascades of processes and looking for a kind of prefixed notation language for connecting processes together, and failing because... it's very easy to say "cat into grep into... or who into cat into grep, and so on. It was very easy to say that, and it was clear from the start, that that was something you'd like to say. But, there are always side parameters that these commands have. They don't just have input and output arguments, but they have the options. And syntactically, it was not clear how to stick the options into this chain of things written in prefix notation, "the cat of grep of who?"

Syntactic binders... didn't see how to do it. So, I had these very pretty programs written on the blackboard in a language that wasn't strong enough to cope with reality. So, we didn't actually do it. Nevertheless, I tried to get, who was it...? somebody was playing with... was getting into the I/O system of the GE635 that the comp center had. We got that in anticipation of replacing it with the 645 the minute MULTICS was working. I asked them, could you make... I've got this wonderful I/O system... where you can... relatively device independent. By and large, you wrote the same way on tapes, as on disks, as on printers... in fact, that was true back in ESYS- 3, the operating system that was built here for the 7090. Largely, device independent I/O calls, like many other operating systems. So, that device independence was something that was around here for a long time. It was clearly a beautiful mental model, this idea that the output from one process would just feed in as input to another. There was syntactic difficulty in talking about that mental model and I have a co-routine paper written in 1968 that was never, never printed, because, it was always a little too ugly, struggling with syntax.

MSM: I understand that one time you were thinking of an infix notation. According to Ritchie's article, you were going to use your pipe... we see these piping as form of operator, linking two arguments, it would be an infix notation.

McIlroy: Yes, yes. Well, we finally... or a filter, a whole filter process was going to be an operator between two arguments... and I... over a period from 1970 til '72, I would, from time to time, say how about making something like this... and I would put up another proposal, another proposal, another proposal. Then one day I came up with a syntax for the shell, that went along with the piping and Ken said, "I'm gonna do it." He was tired of hearing all this stuff... and that was certainly what makes it... that... you read about it several times I'm sure. That was absolutely a fabulous day, the next day too. "I'm gonna do it." He didn't do exactly what I had proposed for the pipe system call. He invented a slightly better one, that finally got changed once more to what we have today. He did use my clumsy syntax and we simply this is passing it through... this is going to be another process. He put pipes into UNIX. He put this notation into the shell, all in one night. The next morning we had this... people came in, people came in... Oh, and he also changed a lot of... most of the programs up until that time, couldn't take standard input. Because, there wasn't the real need. They had file arguments. Grep had a file argument, Cat had a file argument. Thompson saw that that wasn't going to fit into this scheme of things, and he went in and changed all those programs in the same night. I don't know how. In the next morning we had this orgy of "one liners." Everybody had one liner. Look at this, look at that.

Nroff had a program called OV, Overlay. It was to make multi-column output. What you did was (writing on blackboard), out of nroff, you produced a series of pages like this. One page had stuff over here. The next page had stuff over here and then OV would OR these two pages together. Then it was into nroff, into OV, into OV, into the printer. Four column output. All that happened. However... and if you go back look at the UNIX manual we wrote about this, discussion of how to use pipes in the shell goes on for a whole page. It clearly had not yet been internalized. Because, now... Is this much in the shell manual that describes what pipes are all about?

One of them had to explain the syntax. How you recognize which "greater than" is to the file. And you also had "less than." Which were really funny. Less than a process.

When Thompson was to give a talk on UNIX at a meeting in London. We all said, what you really want is function decatenation, and we would write informally a little function decatenation symbol.

MSM: Yeah.

McIlroy: To prepare this talk. Thompson said, "Let's take it simple one, and took that one, and distinguished it from the "greater than" for files, and then he could give a respectable talk. I can remember giving a talk at WG2.3, just two weeks after pipes were up, and apologetically talking about this. Folks are not reticent with their criticism of 2.3. They said that's ridiculous, "you gotta have better intake," and the better intake did come a few months later.

MSM: This is my get that, because I haven't got a video camera on this.

McIlroy: I think that notation is somewhere in Dennis' paper.

MSM: It's in Dennis' paper.. What's not in Dennis' paper is the story about the meeting of Ken (Thompson) and you.

McIlroy: Cleaning up of something so you can talk about it is really quite difficult. Every time a manual, another edition of a manual would be made, there would be a flurry of activity. When you wrote down the uglies, we'd say; "We can't put this in print." Take features out, or put features in, in order to make them easier to talk about. The virtue of being in a research center... you don't have to keep any old software running.

MSM: Incompatibility is a human function?

McIlroy: Right. Incompatibility is just a terrible burden born by IBM and Bell Labs selling facility. We're trying make production. They have users who have code out there that works and probably nobody even who knows how to repair the code if any syntax or semantics are changed. So everything is competing... the burden of history is with them.

MSM: I was talking with... when I was working with Charlie Stenard down in Holmdel, we came up to see Carolyn Childs. I think it is. We were talking to her about the problem of maintenance of software, and the problems of trying maintaining it when you don't have documentation. So, what kind of documentation would you like most of all? She said, "We would like some record of the decisions... of the things you didn't do." "The decisions you made not to do something. Because...

[END OF SIDE A]

MSM: (It was a version of SREM -- not clear)...which is now called RDD 100, says that one of the values of that way of designing is that you can keep a record of your previous designs. And, in form of version control, go back and just archive that. You can always go back and see why it was you didn't do something. Because, you got this problem here and this problem there.

McIlroy: That kind of stuff disappears, when the personnel... Well, in fact, it even disappears out of your own mind after three years. Somebody wrote me mail the other night, saying, "Why is such and such an option in diff?" I knew I put it in. And, as far as I knew it had no use. (Laughter) It was twenty four hours, before I realized it was special feature in there, just for the special benefit of one other program that used diff. Perhaps, I should have never perturbed diff. I should have put this glue outside, instead of in the program.

MSM: One of the lovely features of pipes is the way it reinforces the notion of the tool box.

McIlroy: Not only reinforced, almost created.

MSM: Well, that was my question. Was the notion of the tool there before... (interrupted)

McIlroy: No.

MSM: pipes... or did pipes create it?

McIlroy: Pipes created it.

MSM: UNIX looked different after pipes.

McIlroy: Yes. The philosophy that everybody started putting forth. This is the UNIX philosophy. Write programs that do one thing and do it well. Write programs to work together. Write programs that handle text streams because, that is a universal interface. All of those ideas, which add up to the tool approach, might have been there in some unformed way prior to pipes. But, they really came in afterwards.

MSM: Was this sort of your agenda? Specifically, what does it have to do with mass produced software?

McIlroy: Not much. It's a completely different level than I had in mind. It would nice if I could say it was. (Laughter) It's a realization. The answer is no. I had mind that one was going to build relatively small components. Good sub-routine libraries, but more tailorable than those that we knew from the past, that could be combined into programs. What has... the tool thing has turned out to be actually successful. People just think that way now. Fast providing programs, that work together. And, you can say, if you if stand back, it's the same idea. But, it's at a very different level. A higher level than I had in mind. Here, these programs worked together and they could work together at a distance. One day they can write a file, and tomorrow they can be able to read the file. That wasn't what I had in mind with components. I had in mind, the car would not be very much use if its wheels were in another county. They were going to be an integral part of the car. Tools take the car and split it apart, and let the wheels do their thing and then let the engine do its thing and they don't have to do them together. But, they can do them together if you wish.

MSM: Yeah. I take your point. If I understand it correctly, and think about it. A macro based on a pipeline is a interesting thing to have in your tool box. But, if you were going write a program, to do it, you wouldn't just take the macro, you'd have to go and actually write a different program. It wouldn't be put together out of components. In that sense.

McIlroy: So, when I wrote this critique a year or two ago of Knuth's web demonstration. Joan Bentley got Knuth to demonstrate his web programming system. Which is a beautiful idea. You write a program in an order that fits the exposition of the program. rather than the order that fits the syntax of the programming language. And then you have a processor which takes the program written in expository order and turns it into a Pascal program and files it. The expository order not only contains program fragments, it contains lots of text right with it.

The declarations are stuck in at the point were you need them, rather than up at the head of the block. And then they're moved by the web processor to the right place to compile the run. Really elegant, and he calls it, Knuth calls it literate programming. And Bentley asked him to write a demonstration literate program for Bentley's' Programming Pearls column. I wrote a critical report about Knuth's program. It's a little unfair, because his program was written as illustration and technique and I, my report criticizes it on engineering grounds, that that was not the right way to write the program. And one of the things I wrote about Knuth's program was, (greased) text that prints out a list of the distinct words in the text and word counts, sorted by word count. Its an easy problem. And he wrote one monolithic program to do whole job and I said "Look, here's the way we do it in UNIX with canonical pipelines, and although I don't recommend it. This is not what he was out to do. I really think, he should have not put definition of what word is, into the program that builds tables. That these were completely unrelated things.

Now, in 1968, I would have thought he was doing just right. He was taking this sub-routine and that sub-routine, and putting them together in one program. Now, I don't think that is just right. I think that the right way to do that job is as we do in UNIX in several programs, in several stages. Keeping their identity separate, except in cases where efficiency is of extreme importance. You never put the parts into more intimate contact. It's silly. Because, once you've got them there, it's hard to get them apart. You want to change from English to Norwegian, you have to go way to the heart of Knuth's program. You really ought to be able to just change the pre-processors that recognize this is a different alphabet.

MSM: Going back to..

McIlroy: So, I learned a lot from Brian. Who really is the guy, the person who articulated the tools idea. It seemed to be in the air, but it was not an overt communicable design philosophy. You discovered it only by hanging around the UNIX room. Brian, put it out of the world.

MSM: Now, this is before or after piping?

McIlroy: After.

MSM: Your sense is that pipe (galvanize) was not true? But, it was there in embryo?

McIlroy: To some extent the shell... The ease of writing a shell script in UNIX. There had been something like that on CTSS before. But, it wasn't easy. You couldn't do more than six commands in it. It had very curious limitations. You could do six things, but not seven. Very ease of writing the shell script. Tomorrow capturing... having a machine govern or guide a set of processes, that yesterday were guided by humans, was certainly in Thompson's dream. And he did a beautiful job of bringing it to reality.

So, we were all ready. Because it was so easy to compose processes with shell scripts. We were already doing that. But, when you have to decorate or invent the name of intermediate files and every area has to say put your file there. And the next one say get your input from there. The clarity of composition, of function which you perceived in your mind when you wrote the program, is lost in the program. Whereas the piping symbol keeps it. It's the old thing about, notations are important.

MSM: I just got through beating somebody up about that. I'm not going to call on Newton. (Laughing)

MSM: Just the dangers of translating Newton's geometry into algebra and what you want to understand as Newton's habits of thought. He thought in geometry. He did not translate it from the functions.

McIlroy: He did not.

MSM: He never wrote that text in anything but geometrical form.

McIlroy: Did he discover the theorems, in geometrical form? All of those method of exhaustion arguments were. (Laugh)

MSM: No. Those are after the fact. They're meant to give logical rigor to what was a more intuitive form of ... Which is not classical geometry. It's an infinitesimallist geometry that was developed by people like Karl (Jurding -- Not Clear) and others in 17th century. I'll send you the article.

McIlroy: Yeah. So, he really did it?

MSM: No, he did it geometrically.

MSM: Christian Huygens, among others, taught him how to do that. Not... I mean, indirectly through his work. But, it was common to think in geometric terms. Because, actually, you could see your parameters. But, also, when you went to the continuous case, you would quite often lose your parameters. For example if you were... as he does in first proposition, talking about Keplerian motion you have the body, it's moving like that, here's your center force. Now, imagine it moving for a short period of time at uniform speed. Now, give it a push. Then it will move like that. Give it a push toward the center, and it will move like that. Well, these are impulses and then he just goes to a continuous curve, by shortening the intervals and increasing the number of pulses until you get to the continuous curve. The trouble is that geometrically, what you do is you lose your geometric measure of the velocity.

McIlroy: Yeah.

MSM: So, you have to relocate it. Well it turns out that if you draw... if you have an orbit with the center force here, and you want to know what velocity is here, you draw the tangent to the curve and draw a perpendicular to that tangent and the velocity is inversely proportional to that length. And you prove it as a separate theorem, to show that's the case. And that is ... (interrupted)

McIlroy: So, when you do the algebraic... when you do the usual algebraic derivation, and pulling a rabbit out of a hat. They convert from r, to 1 over r, and the equations become nice? (laughter) Are they generated? (laughter)

MSM: It would be nice to say that they are a translation of that. But no, the beauty of Algebra is that you don't worry about dimensionality. And you don't worry about losing terms. Because, ultimately you have a picture of an orbit here, which is a physical object in space. Well, there's no room in space of three dimensions for things like velocity, acceleration, time... so that any time you draw them on a diagram, you're imposing another dimensionality. And then you have to be able to work in several dimensions and are not using it another way. Whereas in the Calculus, it's just a question of how you write your terms and you can keep all your dimensions in multidimensional space.

McIlroy: But there is this amazing transformation that turns the equations of orbital motion. If you use 1 over r, instead of r, as your dependent variable, the equations are nice.

MSM: Yes. I've done the trick. But, no. That does not come from that. Anyway, you're right, notation makes a difference.

McIlroy: The... We talk about more elaborate... So, pipes are there for linear pipelines. More elaborate arrangements, such as we talked about in a language from NSA called POCAL. A data processing language, this was an amazing language which data processing... you... often problem or solution is expressed with pictures of here's the tape being carried here to there and it's being put onto cards, and what you're seeing is a data flow diagram, and not a classical program flow diagram. They had the idea that the data flow diagram was really the right way to express data processing, at a very fine grain. Even between two successive steps. So, we would put together a data processing application, as a whole bunch of little things connected up with files. Often fifty files. And then their compiler would optimize the files out of existence. It's gotta be biggest optimizing compiler (interrupted by laughter). You know, when you throw away a file pass, that's really different from saving an instruction which most optimizing compilers do. A very impressive optimizing compiler. It would throw away as many files as it could. Even when there's loop structures, if it could, by reading the code, determine that there would be a bounded feedback cue, then all you need to do is provide enough temporary storage to handle the bounding cue, and... furthermore, when there are loop structures, you can't do it with real live files. Because, you have to start reading the file... real live tapes, which is what they had at the time... because you have to start reading the tape while you're still writing it. How did I get onto POCAL? (laughter) Oh, other topologies of pipes.

MSM: Let me ask you about topologies and pipes that is mentioned, and that's APL... as a form of pipelining process. Or, a language that pipelines.

McIlroy: APL? Yes. It's the beautiful prefix... this composition of functions. Certainly APL was one of the things in mind when I was doing these blackboard exercises.

MSM: That was my question. Did you have APL in mind?

McIlroy: That was certainly in mind and APL just did not allow us to have operators with variance. Such as only options, that our utilities had. As long as you take the good clean operators, it's a beautiful notation. It only took us one willingness to throw in a new separator, the vertical bar and we were able to handle that, but it took us about four years, from the time we started talking about it, to the time it happened.

MSM: Let me ask you what you were thinking about in another sense, and that is related to something we were talking about when I had lunch here the last time. Which to the extent to which UNIX is the instantiation of... really a theory of computing... of ideas in computer science. YACC, the instantiation of a theory of (cursors -- not clear), blanks, of finite automata and so on.

To what extent can we take something like pipeline? You could treat pipes as they appear in any instantiation as the instantiation of a mathematical idea and what was the relationship over these early years between theoretical comp sci. What were you thinking about? Were you thinking about how to get an operating system working... a computing system working... or were there a set of ideas that you people were pursuing... that you were using this project to test out?

McIlroy: Well, there were two. I would say that most of us, the theory was there on the side and we were certainly alert to it. I went to Oxford for a year, solely so I could imbibe the notation semantics from the source.

MSM: I lived with him in the same program for two years and didn't realize he was the source. (Laughing) Daniel was part of the history of science program at Princeton for two years.

McIlroy: He had been at Oxford just the year before I was. But Strachey was sort of the catalyst for the whole thing. Although Dana was the one who made it mathematically respectable.

MSM: You had gone to work with Strachey?

McIlroy: I went to work with Strachey. Most of us are more computer types than mathematicians. Even though we write papers occasionally with mathematical... With exception of the language theory. I had in my department, system builders like Thompson, and theoretical computer scientists like Aho. And Aho plowed the fields of language theory from '60... He joined us in around '66.. Just around the same time as Thompson. Handing out paper after paper of slightly different models of parsing, and automata. And that was supported with the overt idea that one day out of it, this really would feed computing practice. Even though it was not. In the same way, we have we have today folks working on denotational semantics. Which seems to be a longer term. But, I have the same belief that semantics, is going to be change practice, and ML is the current embodiment of that. This long line of playing with the mathematical ideas. Which happened all over the country. It wasn't just here. Finally led to Knuth's one paper on LR parsing. Which got repatriated back here, and one day Steve Johnson went in to Al Aho, although I wasn't present, I'm attributing something here... and said, "I want to make your stuff work". We had compiler compilers before TMG. And in some ways, TMG was nicer than YACC. Not specification of grammar, but it actually helps you do the translation. YACC only helps you do the parsing, it's up to you to do the translation after that.

When the sound theory of parsing went into a compiler writing system, it became available to the masses. It.. . There is a case where, there's absolutely no doubt that, overtly, theory fed into what we do. There are lots of other places where theory is an inspiration, or it's in the back of your mind. Very few of them are... well the regular expression business also came out of automata theory. Thompson wrote one famous recognizer, which is the one that's still in GREP. And Al Aho decided that he was going to take that part of automata theory, he built EGREP. Which determine... you have the deterministic one in EGREP, and the nondeterministic one in GREP. I think really that YACC and GREP are what people hold up the "real tools" and... they are the ones where we find a strong theoretical underpinning. troff has none. And of course it's used, and indispensable. Nobody holds up it as a programming gem. (Laughing)

MSM: When I used YACC, in the compiler course that Sethi taught us at Princeton, one liked to go in and actually look at the statement. And in my urgency, I have no desire to look into MS... (Laughing) ...and see what those macros are. (Laughing)

McIlroy: ... if you do look at it once, you recoil in just absolute terror. You know, there's no model there. It's true of all its competitors, too.

MSM: Things like TECC, are slightly more powerful...

McIlroy: ...but, fundamentally they are the same thing. You still don't have a model of what typesetting is about. But, one of the difficulties is it's partly esthetic. You cannot bend page to meet some theoretical requirements. Nobody cares what you're compiler looks like on the inside, so you can bend it to agree with a automata theory. troff has to feed into a different market...

MSM: Yea, and you're also, it seems to me with tools like YACC, accomplishing more than just getting a compiler together, you're getting some assurance about ambiguity... If it says that there's an equivocation in it, then there certainly is. But, if whether you're really healthy if you get a clean bill of health... but still, it's comforting to know that you've gone through there and you don't have any ambiguities in it.

McIlroy: This is the nice about programming in a language like ML. Which we have not... I have not yet been able to say all right I'm going to abandon C, I'm going to write in ML. I think I ought to. But, I will have burned my bridges. I will no longer be able to work with... I will have left all these old parts... that I could use. Starting from scratch. But, there's a language which is built on mathematical ideas of algebra. Category theory... how imposition of functions and higher level functions in that language... Functions that work on functions... Functions are return functions... Come straight out of modern algebra.

MSM: I haven't seen this. Is there text now available?

McIlroy: There is a book available. It's a job jointly done, by Edinburgh who are in the center and Dave McQueen here... and now there's also a big outpost of it at Cornell. I think it spread... In England where they like their computer science to be more scientific, I think it's spreading quite well.

MSM: The Algebraic reminds me of sort of the use of set theoretic specification through to Z and... at Oxford. When I was looking at it, it seemed to be more mathematical than would suit the American taste, or at least homegrown taste. So, I've ordered it.

MSM: ML, I'll take a look at it. And you say there is a book out on it?

McIlroy: Yeah.

MSM: One of my interests, as an historian in mathematics, is the effort to mathematize computing. One thinks of the computer as a mathematical instrument, and of course it is. The difficulty of getting it and capturing it in mathematical forms, especially dynamic behavior of programs, makes an interesting chapter in efforts at mathematization. ...and what it would mean to mathematize it.

McIlroy: It's interesting that computers are feeding back into the foundations of mathematics. I think computing is the engine that's driving type theory now.

MSM: Type theory through mathematical logic.

McIlroy: Yeah, the logicians are now getting their inspiration from the computing side.

MSM: Good, I'm glad there's a justification for it. Because, I must say when I first encountered it, I thought... the problem can't be that bad, that we have to go through this.

McIlroy: But, sound, type theory, is really at the heart of design of a language like ML. We often talk strongly typed languages, but the idea doesn't really mean much until you get to second order functions and polymorphic functions. The general identity function in that identity can be applied to anything. It just produces....

Sam Morgan

The interview date is unknown

MSM: You were saying that there was some effort to...sometime ago to portray UNIX as having been management inspired. You were about to say but that was not so.

Morgan: It was not so and in the way that the question originally came to me. And why don't we get to that in the proper course of things.

MSM: Okay

Morgan: Let me ask you, whom have you talked to already about UNIX? Uh, some, some set of people not all of whom are right around this immediate corridor that were in on the early part of the work and would have interesting things to say. Who, who have you seen?

MSM: Well I have talked to Doug, talked to Ken Thompson and talked to Sandy Fraser, Peter Weinberger, Brian Kernighan. I am suppose to see Condon and Ritchie tomorrow.

Morgan: Ritchie, Ritchie is important as you know.

MSM: Yes. Let me see who else is in my book. Lorinda Cherry and Al Aho on Friday I am going to talk to. And then I think we have another interview, and I have a list of other people that I want to talk to. Basically one of the lists I have been using is the list of people that Doug put together in that little piece he did on the early manual. Identifying where pieces had come from and then I got some other names. Ted Dolotta gave me a call when he heard about this project cause I knew Ted from swimming.

Morgan: Okay, a person who you certainly ought see is Berkeley Tague. The reason I say that is well Berkeley is an articulate and philosophical person. But he was involved from very early on in the UNIX support group. When, when UNIX got to be big enough and interesting enough to the organizations at Bell Labs outside research Tague put together a support group that gradually took over the management and extension of UNIX as a software base for a lot of development efforts. And I think it was in 1982, um, Tague put together a fairly long talk on the history of UNIX up to till then as he had seen it. And I thought it was both entertaining and quite perceptive. Tague had during, Tague is now a department head in the Murray Hill comp Center. He can be found in the book and his name would be suggested to you anyway I think by someone. But he did make some effort to do a one man's history of UNIX. Which I thought was quite effective. And so you certainly want to talk to him as to how he saw it because his viewpoint was a little different from the viewpoint of the research organization. But not so different that you couldn't see some similarities and he did considerable work in 1982 on putting the record together. So he is somebody you ought to see.

MSM: Good. What was your position here at the time this UNIX project was done?

Morgan: I was Director of Computing Science Research. The same position that Al Aho holds now and that Sandy Fraser held after I did. Up until a couple of years ago. I was director of the organization which UNIX was done.

MSM: Were you director during the period of the MULTICS department.

Morgan: I became director in 1967 and MULTICS was a project that was then ongoing. MULTICS had been presented to the Bell Laboratories computer using community as a kind of computer utility. As an operating system that would be a major advance over the then existing mostly batch oriented operating systems and this was to run on GE 645 computers. And people users had been told don't make further major commitments to developing software for the then existing IBM700-7000 series. Uh, wait, uh, MULTICS which is being done as a joint effort by Bell Labs, General Electric and MIT, uh, this will be the operating system of the future. At the time MULTICS began to be presented to computer users in that style I was elsewhere and was a computer user myself. By the time I became Director of Computing Science Research there were beginning to be doubts about MULTICS. It was, the development was clearly moving more slowly then had been expected. And users were sighing with varying degrees of pungency, "We can't wait for this." But the MULTICS development effort as far as Bell Labs was concerned went on for about two years after I became director. And then Bell Labs declared that it's commitment to the MULTICS development effort had been fulfilled. This was made, this decision was made early in 1969 and Bell Labs work on MULTICS was terminated I believe at the end of March of 1969. So I was in on the last part of the MULTICS efforts so far as Bell Labs was concerned. And UNIX was born late in 1969 as you probably have heard and developed in research for awhile and then eventually spread.

MSM: I'm interested if you can you tell a little about that of the MULTICS project. Realizing that you had, that you came into your position while that was going on. But you did I guess that MULTICS, there were promises associated with MULTICS.

Morgan: There were promises associated with MULTICS that were not fulfilled on a scale and in a time period that would have made MULTICS generally useful to the Bell Laboratories computing community.

MSM: Was this an assignment that the computing research group got or had it had a role in shaping the project. Making those promises in the first place.

Morgan: I do not know how, I do not know for sure who was the driving force behind MULTICS. I associate it with an Executive Director named Ed David. I was not, I was not closely associated with the computing enterprise until I became Director of Computing Science Research. I was an applied mathematician and really had no expectation that I would be going into a computing organization. And so I simply heard about MULTICS. The person who did most of the talking in auditorium and general meetings describing this system that was coming and encouraging users to not make major commitments to the IBM700-7000 series but to wait for the GE 645 and MULTICS, the person who did most of this was Ed David. And there was a man named Corbato at MIT and I don't remember who the principle GE promoter of MULTICS was, but I simply, I simply was not aware of whose brain MULTICS sprang, sprang from. The Executive Director of the organization that Sandy Fraser is now Executive Director of was the principle person who promoted it and who advertised it. And, oh yes, I should say, at that time computing service with comp centers such as they were at the different Bell Laboratories locations were run by technical organizations. The comp center at Murray Hill had originally been run by the Mathematics Research Organization. And then it was run by the Computing Science Research Organization when math and computing science split. And the comp center at Holmdel was run by a technical organization that kind of ran computing service with its left hand, and at Indian Hill. Each of the comp centers was run by a technical organization whose business was not primarily running a comp center. They were using, the organizations that ran comp centers had been amongst the early users of electronic computers, and so they took on as a part of their business computing service to the whole location at which they were. Alright. Uh. The Computing Science Research Organization, um, which I believe was split off from mathematics about 1965 and was under Ed David's direction until he go promoted to Executive Director, the Computing Science Research Organization did the software development such as it was at Murray Hill at that time. The Computing Science Researchers had put together various operating systems for IBM 701, 704, 709, 7090, 7094 under the names of BESYS 1, BESYS 2, up through BESYS 7. This work, this operating system design work was done by computing science researchers. They called it all research and we ran with the aid of a fairly small number of associate technical types. We ran the Murray Hill computing service. So when MULTICS was commitment to by Bell Labs and I am sure that Ed David was the spear head of this effort, David committed his people in computing science research to carry the Bell Labs end of this. I don't know Doug McIlroy was around during that time and he will probably be able to tell you whether this MULTICS effort was supported whole heartily by everybody or whether there were doubters from the beginning. But in any rate, at any rate in 1967 when I became director of Computing Science Research the computing science research organization was committed as a major part of its then ongoing work, to see the MULTICS project through, and MULTICS was going slowly and was clearly. it was becoming clear to people that MULTICS was an attempt to climb too many trees at once. It was a mixture of research and exploratory development and final development in so far as those terms can be applied to software and it was simply not going to produce usable amounts of computing service to customers. This feeling was already pretty strong in the computing science research center when I took it over, and users, outside users who were never very patient with anybody, users had decided already that MULTICS was not going to fly. Well the MULTICS effort never the less continued for another two year approximately and was officially terminated, Bell Labs quit working on MULTICS, as of the end of March in 1969.

MSM: You said you had, that you came out of applied mathematics and had not been heading to running a computer, computing environment.

Morgan: I had, I was simply a user of computers up to that point.

MSM: Did you, when you took over in '67 what did you see the mission of that group to be. Did your appointment represent a shift of direction of any sort?

Morgan: No it didn't represent a shift in direction it represented the fact that the person who was then director of computing science research had been laterally transferred to one of our Whippany organizations. Was doing military software for the Safeguard Project and I am, this was a lateral transfer . He became a director at Whippany and I was not aware of any particular reason why this was done I assume that he, it was felt he was needed at Whippany.

MSM: Was this Vyssotsky?

Morgan: No this was not Vyssotsky. Vyssotsky was a department head in computing science research at the time the man was Tom Crowly. Crowly was shifted to Whippany, lateraled as a director and I assume that it was because he was urgently needed at Whippany. And there was I presume a search for a suitable person to take over the computing science research center and I was asked to do it but I was not told that there shall be any change in mission. My understanding of the mission was that it was a research group. We were-[break]- to understand the foundations of computer science. Computer science at that time was not nearly as large and flowering a structure as it is now. We had work going in formal language theory. We had work going in numerical analysis. We had work going in operating systems. We had some work going in switching theory and we had this exploratory development project MULTICS which had been taken on under the aegis of Ed David and I believed at that time, and was not given any other sailing orders, I believed that our business was to do research to understand the power and limitations of computers in so far as computers ought to be useful to Bell Laboratories, and that as a transient part of this we were committed to seeing the MULTICS operating system through. But I always believed that this was a transient thing that we had been committed to and that we were not in the software development business for the long pull. We were suppose to assist software developers and so that MULTICS would ultimately be finished up. Well it wasn't finished up quite in the way that the originators expected it to be, but it did come to an end.

MSM: Was that a fairly sudden end?

Morgan: Uh, there had been an increasing feeling both outside computing science research and inside computing science research that the project was not possible to finish in order, in a way that would meet the original expectations. And our then, Vice President, Bill Baker, decided that the work was simply going to stop. It was Baker's understanding and mine too that we had in some sense met the commitments that we had originally made, that we were not backing out of any contractual arrangement without, well we were not breaking any contract and the day on which the work stopped I believe was the last day of March. There was an announcement, a formal announcement that the work was stopping, that we were charging no more effort to the MULTICS charging case. And that we were simply out of it. I believe it had to be done that way because some folk were, well unless there is a definite statement that you are not going to work on a project anymore, why, some people will continue to work on it. That's the way, that's the way research goes. Folk from day to day do their own thing. And so there was a clear announcement that the work was over. And this was due to Bill Baker. I believe that Ed David actually read the formal statement to the members of the computing science research department but they were words that had been, this decision was made by our Vice President. It is not unprecedented that a project shall stop, I have known of other much larger efforts that were simply by management edicts stopped on a certain day. And MULTICS stopped. It was, I believe the general reaction was that it was understood why it had to stop. It was simply, it was simply using up effort and was not, was not advancing and showed no promise of, of turning into a user useful thing.

MSM: You have talked to Ken, Doug, and those that have written about it, Dennis when he writes about it in his retrospective. We talk about the sense of disappointed they felt. Where as on the one hand they agreed and they agreed with the technical judgment of MULTICS's inadequacy. That is that this was a system that was simply wasn't going to do what it promised to do. For one thing is was not going to deliver the cycles that sort of...

Morgan: Well that, well that was the main, that was the main reason that MULTICS was stopped here so far as I can see. It, it had, it was originally a promise to users of very flexible cycles. It was the first real time sharing system. Well there was IBM's TSS which was running at Indian Hill. I have never been very familiar with the details of TSS. The Indian Hill people were a group that decided quite early on that they were not going to wait for research and for the GE 645 and for MULTICS they had to have something sooner, and they wanted something that was supported by a vendor which TSS was. I don't know the TSS story really and I can't tell it to you but MULTICS if it had met it's promised goals would have been a much more flexible, convenient system than TSS, so I am told and I believe. But MULTICS was not about to meet it's goals in 1969 and I think this was generally understood. Now the sense of disappointment that Dennis and Ken and a few other people, I guess all the people who were working on MULTICS felt, I think was that they had had a system that was for a few... Well in the first place it was intellectually elegant. There was a lot of nice conceptual stuff in MULTICS and it is always good to feel that you are on the leading edge. But the other thing was that it was a, it was a very pleasant and convenient system to work with if, to use, if there were only a few people on the machine, if you had so to speak, and I am not trying to be pejorative here, if you had exclusive use of this large expensive toy, great! It was fun. You could develop software, you could do all sort of things with it. It just wasn't adaptive to supporting, it wasn't cost effective. But heck it was something that they liked and as you have undoubtedly been told repeatedly it was to make well UNIX turned out to be a much simpler, more cost effective environment which provided users with the pleasures of a, of the same kind of sandbox. So MULTICS was fun. I, I never used MULTICS, but I was told that it was a lot of fun for the people who were developing it. It's just that it, it wouldn't carry the load for a, for a big organization.

MSM: Well they've, they said both in conversation with me, but also in writing it what they missed was the shared environment.

Morgan: Yes.

MSM: That here was a way in which you could, you were all working, you could share one another's files, and delete things for one another.

Morgan: It was a very nice environment for a small number of users, but the Labs just could not afford and users generally could not afford the cost of the GE 645 for the small number of users that it was supporting. Now I am giving this to you by hearsay, but that was my understanding. Not that UNIX was unsuccessful for a limited community of computer science, MULTICS, not that MULTICS was unsuccessful for a limited number of computer scientist users. But that it was not, it was not cost effective, it would not have been cost effective to support a large laboratory.

MSM: Now when the decision was announced that there would be no more charges made to the MULTICS case were there, were there any statements either explicit or implicit. Edicts about lines of research that would or would not be followed. I mean in a sense the MULTICS project didn't stop, stop it just got redirected.

Morgan: It got redirected. There were no statements about what lines of research were acceptable. We don't make statements around here about what lines of research are acceptable in the short run. AT&T is interested in a very wide variety of subjects. We are not interested in translating my hieroglyphics, we are not interested in fusion research, we are not interested in various other things but there are a lot of things that we are interested in. Centering, mostly centering around communication and around information handling and this provides a great many directions that one can go. When a new researcher is hired here, there will be a point to this in a minute just hang on. When a new researcher is hired here anywhere in the research area, he or she is hired because of a doctoral thesis or some other track record that indicates proficiency, creativity in some field that we are interested in. When the person comes in the department head's business is not to tell the individual what to do but to see that he or she gets introduced to folks with common interests or perhaps common interests and that various people come around and ask questions, try and consult with the person, and we suggest that a new employee spend considerable amount of time, up even to a few months, thinking about what he or she would like to do. Very often publishing the Ph.D. thesis is a good thing to start on. But anyway, people essentially found their own things to do influenced by the total environment they are in. And if a person wants to undertake a certain line of research, a certain kind of investigation, presumably because of the individual's technical background before coming here this would something that's in a field that is of interest to Bell Labs and we allow this to continue. And if the person seems to be getting somewhere, seems to be interacting with people and well seems to be making some progress, and particularly seems to be communicating with his or her colleagues a considerable length of time can go on before the department head try's to steer the person in some other direction. The problem that sometimes arises with people that come to with a bright new Ph.D. and seem to be very bright is that the person will somehow have been closely directed during his or her graduate life, worked for a professor who held the reins very tightly and then in a kind of free environment like this where nobody tells you what to do from day to day the person will just not be able to find new and interesting things to do. Now if a person does find new and interesting things to do and if they get written up and published and if there seems to be lot of interaction going on. And particularly, if the person seems to have people coming in to talk to him or her from other departments, that this person is interacting and communicating that is fine. The person will essentially never get directed by his or her department boss. If with the person doesn't seem to really to, be producing anything and in particular doesn't seem to be communicating or interacting with people the boss will over the next several months spend more and more time encouraging the person to communicate and to look at specific problems. And as a year or two goes by there is always performance reviews every, every year and a matter of communications is stressed. The boss will become more and more explicit about, "why don't you spend some of your time looking at this particular problem?" But a person says, "I want to do such and so." You are not going to be told not to. Eventually if the direction seems to be completely at variance with others things that are going on it may turn out that the person had better pursue this at a university or some place like that. But in the short run folks are not told you are not going to do this. Development organizations. If a development project is canceled usually that involves a team of people working on a particular direction. If a development project is canceled, alright you are not going to be developing XYZ widgets any more, that is clear enough. But researchers you don't tell them what to do. What we did we tell people that had been working on MULTICS was you cannot have a large computer a the [inaudible] Tand was proposed as a substitute for the GE645 during the summer of 1969. They didn't have a GE645 anymore and so there was some effort to propose the purchase of a large computer on which to do time shared systems research and proposals that one should by a substantial chunk of, of plant equipment, naturally have to be approved upstairs. The MULTICS people were told, "we are not going to provide you with a large computer for a small number of people to do time shared system research on." We didn't tell them what they should do. We told them various things that we were not going to buy equipment for. And so, that's standard operating practice for researchers. They are suppose to be able to find things to do and so eventually they did.

MSM: When did you become aware of this new project, this new file system and attempts to implement it?

Morgan: Oh, must have been late in 1969. We have a performance review every year. Starts about November and people write up a page of what they have done, it is commonly called the, I Am Great Report, although that is not an official name for it. And Ken Thompson had on his I Am Great Report in 1969 that he was working on a, a file system for a, a small computer and by 1970 why the system had been named UNIX and several people were working on UNIX. Another theme that merged with the time shared development was the text processing, text editing and formatting theme. There was, I believe at MIT or from someplace a type script formatting scheme called runoff which Doug McIlroy worked on quite a bit and turned into a thing called roff and this, I got a head of myself a little bit. Now this when we got a cheap photo typesetter, got approved to a formatting scheme called T- ROLF which is still around. People were interested in text editing and formatting and you could do this on a small computer and if you had a, if you had a operating system that involved easy handling of files and presently time sharing so that the people could access and use each other's files. The UNIX file system and the text editing and formatting work kind of came together. I understand that Ken Thompson had a space war game that he played for a while when he was looking for something to replace MULTICS. That was fun but the, the first real application of the file system that became UNIX was a text processing system. And this was kind of the merging of file system work and work that folks had been interested in for a long time, text processing.

MSM: Well this is the system that the Labs was willing to buy a machine for.

Morgan: This was a system the Labs was willing to buy a machine for. When this, the proposal was first made that we should buy a machine for text processing it was presented to me because I had to sign the purchase order. And I didn't understand at the time the innovative nature of the UNIX file system and we had done text processing work in the past and I didn't see that we were, that any great research advance was being made. It sounded as if people wanted to provide a service or something with a typing pool. So the first proposal to buy a I guess it was a PDP11/20 I turned down, this was in 1970 and another director Max Matthews managed to gin up a machine. He was also interested in text processing and by the time people had worked on the file system and on text processing for another year by 1971 it was quite clear to everybody locally that there was something rather special going on. And from then on we bought a sequence of PDP- 11's, and research, and by and by the patent division was using the text processing scheme, and by and by it was used in the word processing typing organizations, and eventually it spread all over.

MSM: What is it that persuaded you that there was a research component?

Morgan: Well, I do not remember at the moment any particular day on which I decided there was a research component there. I guess it was being, being shown some of the things that the text processing system could do. I guess I felt that. Let's back up a little bit. The computing science organization here like all of the research area, but I think maybe they are a little stronger than some, has always been very outspoken and very sharp tongued in promoting their viewpoints and there was a good deal of noise when MULTICS came to an end. And it seemed to me, that well I guess I had some difficulty in sorting out the signal from the noise. I was quite well aware that my bosses wouldn't approve the purchase of a really large computer to support any surreptitious continuation of the MULTICS effort. And I was, I think willing to wait for the initial shouting to die down and I figured that if there was a research component involved in the text processing work that it would appear in due course. And indeed it did. I have told this tale more than once to people who, this is were we came in, who would have liked to demonstrate that it was management perspicacity that caused UNIX to be, to be born. Some parts of management did not understand UNIX as rapidly as other parts did. I think that we did understand management principles. The management principles here are that you hire bright people and you introduce them to the environment, and you give them general directions as to what sort of thing is wanted, and you give them lots of freedom. Doesn't mean you always necessarily give them all the money that they want. And then you exercise selective enthusiasm that is one of Bill Baker's favorite phrases. You exercise selective enthusiasm over what they do. And if you mistakenly discourage or fail to respond to something that later on turns out to be good. If it is really a strong idea it will come back. So anyhow that is... MSM: We had a dean at Princeton who was famous. No matter what the proposal the first answer was no. Then you came back.

Morgan: Alright, well it is a little bit like patent examiners. I was told in my early career when I got a few patents that there is always an interplay between the local patent attorney and the patent examiner at the bureau of patents in Washington. And you had chit chat for a while and then you get from the patent examiner a final rejection. This patent is now finally rejected. All claims are rejected and that is an invitation to put forth your strongest argument. You now give me your best argument and I will listen to it. But I was told that the final rejection is the last, last stage before you finally get some things admitted. Well, we didn't quite play it like that around here. But that. I have never been in an organization that had enough money, or enough hiring slots, or enough office or land space to do everything that we would like to do. So one provides some back pressure. And in the case of the transition from MULTICS to UNIX the MULTICS faucet had to be turn off reasonably hard. It was a part of turning off, I mean it was a management decision that this was going to be turned off. And part of turning it off was not immediately buying hardware on which MULTICS could be continued. In retrospect, Thompson and Ritchie and other people did find partly through their own efforts and partly by looking for a director that was willing to buy a small amount of hardware, did find machines on which they could work. And in due course when it was clear to everybody around the research area that UNIX was going to go somewhere and needed to be supported they have had the machines that they wanted.

MSM: One of the things that impressed me, that has impressed me about UNIX is the way in which it's a system with a lot of really effective coding, programming. On the other hand it is a system that if it's not theory driven at least has roots in theory. There is a, if one works ones way through the various books by Aho, Hopcroft, Ullman or the various combinations of three things taking two at a time, that series represents. And one looks at UNIX, one sees their other piece, and that is the product by in large of the computing research group. How did that unity come about. Was that something that you were looking to create or is it pure coincidence, or it is...

Morgan: I...

MSM: It is a view of computing really as an enterprise...

Morgan: I, I don't, there was a conscious decision to do this unified sort of way. As I, yes I was saying earlier we have had at Bell Labs for a long time, certainly since before I came and I have been here forty two years, we have the philosophy that you hire bright people, you expose them to interesting problem areas, and you keep an eye on what they are doing and in particular on their interactions with other people. You attempt to give them guidance only in a very general sort of way. Often times this guidance is simply a lot of enthusiasm for something that they are working on. An environment like that is self perpetuating, so long as you keep your hiring standards up and your management keeps its eyes open. Remember that the management around, around Bell Labs all are, at least around the research area, all came up through the technical route. And people don't get promoted to management in the research area here unless they have a good track record. You may find a few folk who disagree with that. But my view is that our department heads and directors and executive directors were once technical hot shots. Sometimes that back fires, because you get a technical hot shot who has no people skills. But that is a different story. Your, uh, your technical people, your managers were once technical hot shots and they were imbued with this general philosophy of how you conduct, how you manage research at this kind of place. And good things come out of this. Well, good things come out of this philosophy of research management. And as I said it is self perpetuating in that that's the way that I grew up and that is the way Al Aho grew up and it is the way Sandy Fraser grew up and it is the way our local department, department heads have seen it work for a long while. What we did in the computing science research organization. I didn't create this, to some extent I keep it going. But was to have bright, interactive people who were interested in theoretical computer science, that is Al Aho and now Ravi Sethi and lots of other people, but Aho was one of the early ones. And folk who were interested in programming techniques. People like Doug McIlroy who was a mathematician to start with, but was in on computer from very early on. And people like Peter Weinberger, who I guess was an algebraist to begin with but he is interested in practically everything. And people like Brian Kernighan who are, is a superb expositor. Kernighan writes beautifully, which a great many computer scientists don't and is very creative in seeing something that needs to be, needs to be done. And people like Mike Lesk perhaps not the world's greatest programmer but Mike Lesk who is now at Bell Core did the EQN patient setting system. No I guess that was Brian, that was Brian. Alright Mike Lesk did a lot of the page layout stuff that got put on top of, of T- ROLF. Brian, Mike, Lorinda Cherry, could see things that, by golly, I know how to do this and I bet somebody else would be interested in it too. The EQN equation layout package for instance after it has been done. Sure other people do that sort of thing, there's ...

[END OF SIDE ONE]

Morgan: ... had the inventiveness to see (A) that I can do it and (B) that it would be nice if somebody did it. Now maybe it ought to come the other way around, perceiving the, perceiving the niche and observing the technique, that the technology exists for doing it. These are two parts of the same thing. Alright we had people like Brian, we had people like Mike Lesk, we had people like Doug, we had people like Ken and Dennis. We had people like Alfie and if I, well it was a small group, it was about two dozen people for a number of years after, after 1969 when we quit running a comp center service. I will come back to that in a moment. And when the MULTICS effort and some people who were associated with MULTICS in a more supportive sort of way went elsewhere. From about 1970 to about 1976 or 1977 we had about two dozen people, twenty four people in the whole group. We were essentially not hiring anybody, we were in one of our chronic hiring freezes and we just had a small group of good people who generally ate lunch together, and who were quite willing to argue with each other and to discuss and to use the techniques they knew about to put together things that they thought were interesting. It was a lot of work in text processing at that time. There was a lot of work in practical operating system development. There was a lot of work in theoretical computer science, compiler theory and algorithms. It was done essentially by a hand full of people. But they were people who did a lot of talking to each other and a lot of shouting and who essentially collaborated. And that is the way that research is suppose to be done.

MSM: What I am getting here is a picture of a group of people hired within a fairly short period of time, several years. At a time when things are the field was still in flux.

Morgan: It was still in flux.

MSM: What computer science was suppose to be in the 60's was an open question.

Morgan: That's, that's right.

MSM: Brought together they tend to form a stable community and in essence what I see is a usual match between practical applications and theoretical foundations. Certainly the out, the product of a group that had come together for different reasons but then had found a common, they had established a community.

Morgan: They established a community. They were in touch, of course, with the university community with computer science being established, being defined as a field in the 1960's. Some of the old timers, myself and Doug McIlroy, and a few others came from the math research center. We had a numerical analyst named Dick Hamming, early on who was kind of the farther of service computing at Bell Labs.

MSM: What had been your background?

Morgan: I was mathematical physics. And as I said I was an applied mathematician. I did boundary value problems, radar antennas, microwave, wave guides, up until I was put in charge of computing science research. And I suspect that I was put in charge of computing science research because just at the time that the previous director was transferred to Whippany there wasn't a really good professional computer scientist who was ready for the job. Sometimes you know there is, you have to fill a slot, and there isn't a perfectly qualified person of the right amount of seniority. So I didn't look for the job in computer science. It wasn't compatible with my background really, but I had been steeped in the general way in which research is managed here. You get good people, you make sure they are aware of a wide class of problems and you let them do their own thing. But you give them feedback.

MSM: Did you have a sense yourself of what computer science would look like at the time?

Morgan: Not really. I was more interested in the mathematical parts of it. Of course I was interested in seeing that people got, so long as we ran a service organization I was interested in seeing that service was supplied. In the middle of 1969, this is a new topic but it is relevant I think...

MSM: Right. It was about to ask you what happened when you ceased to be a service organization.

Morgan: In the middle of 1969 service computing at all Bell Labs locations was taken away from technical organizations, that is organization whose primary business was something else. And merged into a single division under a man named Phil Thayer, who is now retired. All the comp centers were put under unified management and for a year and a half I was both director of service computing at Murray Hill and Whippany, and director of computing science research. It was expected that this would be a temporary arrangement and so at the end of 1970 I chose to give up the service computing aspect and from then on it was under its own separate management. Well anyhow. The move to a separate computing service organization I think was long over due. It just wasn't reasonable for a single, for a research organization also to try to manage a stable computing center. Researchers you know always like to fiddle and, "we are going improve it!" And users, "my program that ran yesterday won't run today what the hell have you done with the operating system now? And besides I want this thing fixed!" and the researcher may feel, "I am not really interested in fixing that. That is mundane..." So anyhow, having a separate computing service organization was long over due. It was started in the middle of 1996. And this was another impetus I think toward the development of an operating system for small machines namely UNIX, that went on in computing science research. Because once the comp center machines were moved out from under the research aegis, we had in research had our own machines and management would not buy big DEC PDP 10's and so we had to do something on minicomputers. And that was another impetus toward Thompson and Ritchie in the UNIX direction. Anyway, that's kind of the history of things. I was interested in both in seeing that users got good service and got new tools as rapidly as they could be delivered. And also in seeing that the theoretical understanding of computer science got advanced. And if I had any personal interests here I found the text processing work particularly entertaining. But I did not do any of the, I did not do any of the research myself. I was, I was the research manager.

MSM: Was there any point at which you were running interference for these people?

Morgan: Well you always run interference in that part of the business of management is to explain to higher management and to other parts of the laboratories what is going on. So that was just part of the job. I never felt that, I never felt that I had to go out and fight for them in the sense that I was contending with anybody. I was, I was if anything a publicist and explainer rather than a person who was going out and contending with other people for money. Our research area here has always been I think quite well supported. It doesn't mean that we have everything we wanted. But if you can make a good case for something, and it is the director's business to make a good case, if you could make a good case for something well you could get it.

MSM: At a certain point I gathered between 73-74 I am not sure what the date is. UNIX in a sense out grew the research group or...

Morgan: Well basically it out grew

MSM: Did it outgrow it and therefore did you feel that it had to someone else had to take over...

Morgan: Well

MSM: Take over or...?

Morgan: Remember in 73 and 74 we had a couple of dozen people who included some numerical analysts, and some people like Al Aho, Jeff Ullman was around here for a while. He is now in Stanford he has become a big man in academic computer science. We had a small number of people and we had essentially no support staff and there were things that folks wanted to do with UNIX that our people were not terribly interested in putting the time on. My perception of the way things grew is roughly as follows and you will want to talk to Berkeley Tague on this because he was heavily involved in this next stage. My perception is that various software development organizations around Bell Labs picked up UNIX and its researchy state and began adding things to it, to meet their needs. The first application of UNIX outside research where it was a test bed or an environment for software researchers to use, the first thing that was done outside, was early 1971 where the patent organization took UNIX on as a word processing system. And there was another system whose name I forget now I could look it up, it was a commercial system that was a competitor. Well, the patent organization was persuaded by some of our folks including particular Joe Osanna who was the father of troff. Osanna died I think in 1977. But anyway Osanna persuaded the patent people that they ought to use UNIX as a text processing system. And so computing science research organization provided what extra bells and whistles were needed and hand holding for the patent typists and so forth. But by 1972 there were a number of outside organizations, outside research at Bell Labs that were beginning to use UNIX for software development. And each one of them had special needs and so they came and they talked to our people and then they added their own bells and whistles. It was about this point that Berkeley Tague who'd been in and out of research and was at the time associated with the comp centers, decided that, that was a game that he wanted to play. His story now is that he was tired of the work that he was doing at the comp centers. He wanted to get into the UNIX action and this was a very interesting area and it was clear to Tague, who has always had his head screwed on right, it was clear to Tague that somebody was going to need to support UNIX. And so he persuaded his management as part of the comp center that there needs to be a UNIX support group. His version of this is that he got together a few people and the way that he became a UNIX support group was that when anybody would ask a question, "We had this problem with UNIX," Tague would say, "well I will take it under consideration." Then he would get on the phone and fly around like mad to every UNIX user he could think of and say, "have you every encountered this problem? What did you do about it?" When he found out he would trot this back, and "you know this is the way that you can fix it!" And after six months he had some local expertise. Well you should hear Tague tell this story. Anyway. Starting in 1972 UNIX began to be adopted here and there and then it was a kind of an avalanche of organizations that needed it for software development purposes or for running their own particular version of the operating system on. And they got to the UNIX organization supported out of the comp centers and Thompson, Ritchie and Kernighan and Mike Lesk and Doug McIlroy and the folk who had contributed to the early stages of UNIX went on adding things as they wanted to, and answering calls from Tague occasionally, and generally consulting, but they were not in the support business any longer. They hadn't been in the support business very much although at the beginning, whoever invents something has got to give it some support. But a UNIX support organization was formed I think in 1973 under Tague, and from there on it...

MSM: Well the system was first announced if I am not mistaken in 1974 at the IBM conference.

Morgan: I believe that..

MSM: Was there a definite decision about when to go public with this and... Cause there's a, one sees a flurry of papers around the mid '70s, is that a sense of back-up?

Morgan: Well we. Computer scientists most of them we don't like to write papers. And so it was a while after the system existed before it was, before it was written up. I forget, I could look up when we first began licensing UNIX to universities. There is another interesting aspect of the UNIX story which might not happen the same way again. AT&T management could not understand the importance of what it had in UNIX. And so we began licensing UNIX to universities for a very small amount of money. At most a few hundred dollars. And UNIX was licensed all over, it spread over the academic world, Berkeley but many other places, it just went all over the academic world in the early 1970's. Doug McIlroy can tell you when or I could dig up out of my records the first dozen or twenty or fifty universities that we licensed. AT&T had simply let universities have UNIX for a song on the basis that they would not do certain things with it that universities didn't very often do anyway. And as a result of that graduate students got on UNIX and decided that, "I love this, where can I get more of it?" And this piece of serendipity was I think very important in spreading UNIX over the world. The fact that it was essentially given free of charge to universities. And I suspect that we would not do that again. But it was a case of AT&T's top management not realizing that software could be financially, extremely valuable.

MSM: You also weren't suppose to be in the computing...

Morgan: We were not suppose to be in the computing business. So we were not making computers and people did not realize that the computer is more than just hardware. It's also software. So giving UNIX away essentially free, talking about it freely and having open lines of communication with our university colleagues especially those at Berkeley, but also elsewhere, this was a major thing in the spread of UNIX. And to some extent it was an accident.

MSM: So they, that set of papers that appear in the mid '70s is that just a..

Morgan: Well now.

MSM: The timing there accidental?

Morgan: Well, the first big set of papers was the 1978, BSTJ. I have got that around someplace.

MSM: Yeah, I have got the reprint of them.

Morgan: Alright. It was, I was involved in that rather heavily and in putting it together. The BSTJ decided that computer software was a good thing and that we ought to have, we ought to have an issue on it. And there was a general consensus that the UNIX operating system by 1978 needed a special issue. And so we kind of made that a, well we made that a project. I was the, yes guest editor who put the issue together and we sold the issue at two dollars and a half or three dollars and a half a copy, and it has out sold every other issue of the BSTJ that we ever published by a factor of many. It over took the transistor issue almost at once, and it was a tremendously heavy seller, and they sold it for the standard rate on single issues of BSTJ which I forget how much it was then, I believe it was two dollars and a half. And that was another thing that AT&T management didn't recognize that they could have done much better by charging five dollars an issue. The big spate the first big spate of papers on UNIX was the 1978 BSTJ issue and I don't believe except for some conference papers and the original Ritchie-Thompson paper, I don't believe there had been much before then. I know I beat quite hard on folk to get papers written for the 1978 BSTJ issue. And we kind of regarded that as the journal unveiling of the subject. There should have been more publications before then but it was a case of lots of word of mouth and lots of electronic mail. And the fact that most computer scientists with the except of Kernighan and Aho don't much like to write. There was no conscious deci..., before the BSTJ special issue, there was no conscious decision, "we will now publish on this." Our folk were encouraged to publish anything that is worth publishing. But some people you have to push pretty hard to get them to publish and we don't push perhaps as much as we should.

MSM: So there was no sense of sort of a formal release to the world?

Morgan: UNIX didn't get any formal treatment in it's early stages it was a thing that Ken and Dennis made and other people as they heard about it by word of mouth, got on to it, "oh this is great!" And university people heard about it and, "Oh yeah you can have it. We will set up a mechanism, you pay us three hundred dollars or whatever and sign this agreement that you won't set up your own company to market this stuff." And it was all a very small scale and low key in the beginning.

MSM: If you look back on it from a point of view of manager, is UNIX the sort of thing that management can make happen?

Morgan: No. You can't make it happen. You hire bright people, provide them with a stimulating environment. And you do selective pruning and encouragement of what they undertake. But you don't do this with too short a time constant. As I said the first time that Thompson and company asked for a computer they asked for a DEC PDP10 and they were told no on that. It was simply to big and you are not going to do operating system research for a big computer just after MULTICS has been turned off. The second time they asked, they wanted a PDP11/20 and I said, "I am not convinced yet, I want to see more of what you say you are going to do with your text processing system." So I didn't stomp on them, but neither did I sign their order and they found somebody else, another director to sign the order, and the third time they came around they wanted an 1145 and by that time they had a perfectly plausible and defensible story. So they got selective enthusiasm used on them but not too violently or with too short of a time scale. If it is going to be good it will prove itself.

MSM: Well, you know, you. The selective enthusiasm with a counterpart. You were displaying selective enthusiasm. They were displaying entrepreneurship. You said no, so they went and found someone that said yes.

Morgan: That is right.

MSM: Is that also, is that conscious management? That is, encouraging people to do sort of in-house entrepreneurship.

Morgan: Not in the sense that people are told that if you want this funding you have got to find somebody to fund it. We don't ride our folk with a short rein. And we don't tell them who they can talk to or who they can't talk to. And I didn't tell the guys when they came around and asked for the 11/20 and I said, "Look I am not convinced by this story." I didn't say, "If you can find somebody else to do it, feel free." But I didn't tell them "Look you must not talk to anybody else," and when I discovered there were no secrets about this I discovered, I was told "Look, Max Matthews can support this." He was the other director. And why could he support it? He could support it because he was interested in text processing, he was doing, he was in behavioral sciences and psychology and he had people who were working on text processing, and in fact one of the folk who was, came in with the proposition for the 11/20 that I turned down. One of the folk was Lee McMahon who was one of Max's department heads. Lee has recently and very sadly died. But anyway, Lee McMahon was the department head of Max Matthew's so the pitch was not really that two of Morgan's MTS, having been thrown out of Morgan's office, I exaggerate here, but having been thrown out of Morgan's office, trot down the hall to Matthew's and, "Morgan doesn't love us what can you do for us?" They came in through McMahon's director and in fact I am, I hadn't really reviewed this but as I think about it comes back to mind. The people who originally made the proposition to me were Osanna, Thompson and McMahon who were working together. They were in different organizations, they were working together. McMahon was particularly interested in English grammar and in text analysis at the time. Osanna was interested in editing and formatting systems, things like the runoff system. Thompson was interested in file systems and ways of handling information conveniently in a computer. So these birds were talking to each other and they had discovered they were all interested in small computers. They had discovered the PDP-11/20, and they felt that they could make a good text processing system out of an 11/20 which would exercise Thompson's file system. I don't know whether it was called UNIX then or not. It would exercise Thompson's file system, it would give Osanna a chance to write text processing programs. It would give Lee McMahon a chance to process text in his analysis of grammatical structure. Which is what he was doing as a psychologist in Max Matthew's area. So they came to see me. And I obviously didn't fully understand where their proposition was going and so I said I couldn't do it. Not then. So they go around and they give this pitch to Matthews who is Lee McMahon's director. And so it wasn't a case of guys from my organization going outside my organization to find somebody. They simply went to the director of the other person in the trio. And I didn't think there was anything wrong with this or unreasonable about it. Max Matthew's was a person who collected little computers anyway and it may be that he had more money at the time than I did. We have certain plant budgets. Anyway, I didn't think that there was anything out of the way about this and I didn't feel that somebody was criticizing my judgment. Max was perhaps in a better position to support the machine or I don't know what. But anyway it didn't seem unusual to me and now that I recall McMahon reported to me for a long time. He transferred from Max's organization into mine not too long after this particular incident. But at the time he was a department head for Max Matthew's. So he added his voice to the desires that the other fellows had and so Max bought the first computer. But there was nothing, there was nothing particularly unusual about this. And since it would have been a little more unusual if people entirely from one center had gone to a different director and said can you support this. In which case, I am sure that Max would have come to me and said, "Look, two of your guys have come to me and have said will I buy them a computer. If a computer is going be bought you ought to buy it. Let's discuss whether it should be bought or not." The reason it didn't happen that way was that one of Max's department heads was in this story.

MSM: It sounds less entrepreneur...

Morgan: Well, now I should have told you, told that to you that way in the beginning. I remember now who the people were. It was Thompson, Osanna and McMahon, and at that time McMahon was a department head for Max Matthew's, and Thompson and Osanna were MTS in my shop, and each one of them had a separate interest in the particular project, and Max was willing to buy it. If he hadn't had one of his department heads pitching it to him he wouldn't have bought it. I would have done it or nobody. And if I hadn't, if Max had come to me and said, "Look, I have listened to these guys and I think they have got a good story, and why don't you listen to them again," I probably would have. Anyway there was nothing unusual about this and it wasn't a case of people either being encouraged or choosing to find a back door. We do encourage people to be enterprising, that if they want something done, or if they want somebody to cooperate with them. There is another kind of question that comes up occasionally with a new MTS. You will occasionally get someone with feels that he would like to have somebody working with him and this won't happen until somebody's boss says, "You two guys collaborate." One does not tell researchers to collaborate with each other. You find, you find common interests in somebody and then the collaboration occurs. So if somebody came to me and said, "You tell somebody to, you tell such and so to work with me." You make your own contacts. So folks, folk are encouraged to be entrepreneurial in the sense that they make contacts and they get collaborations going. They are not encouraged to go and ask some other member of management for money that they can't get from their own management. But in the case of the Thompson, Osanna, McMahon thing the pitch to Matthews came from one of his own department heads.

MSM: Well, we have gone on for a while and I think that I have run out of questions.

Morgan: Alright.

MSM: But I also probably..

Bob Morris

The interview date is unknown

MSM: Talked to Doug McIlroy. Ken Thompson, Dennis Ritchie, Sam Morgan, Lorinda, Brian, Sandy Fraser, Al Aho, Joe Condon, Weinberger and Berk Tague, oh and Stu Feldman. Have I missed someone important?

Morris: Well, there's three people, that they have missed. Two are dead, so, uh, you waited too long. That's Lee McMahon and Joe Osanna.

MSM: Who was the first person?

Morris: Lee McMahon. He died about two years ago. Joe Osanna maybe died ten years ago. There is another person. Who was in very early. That gets inadequate credit for what he did. But, he left the research area, sort of right after when things really sort of got started. People have forgotten about him. Which they shouldn't, because, hey, I had forgotten his name too.

MSM: Rudd Canaday?

Morris: That's probably who I'm thinking of.

MSM: He was one of the original three that met in Ken's office.

Morris: Yeah. Okay. No you didn't mention him.

MSM: I hadn't talked to him.

Morris: Yeah and uh, I mention that because there's quite a few people who were not in it in the beginning at all, who still get a lot of credit. Some people who were in it in the beginning who don't and I think Rudd would definitely be one of them.

MSM: I'll talk to him.

Morris: Of the people you talked to, very few were associated with the creation of the system itself. Or were even anywhere near close to it. Those who were were really, Ken, Dennis and Rudd. Others came in maybe a year or two or three years later and myself included. I was nearby but not involved in the creation of the system and the fundamental ideas that went into it. I was nearby but not involved.

MSM: How did you get involved?

Morris: Interesting goings on. Possibility of restoring what a time was a... Bell Labs had become a technological backwater in almost all computer science related activities, and not only that, but we were headed in a direction of more stagnation as time went on. This was right after the death of MULTICS project. Which we had been on for oh perhaps six years, seven years something like that. I think we started in about 1963 or 4. 64. It was a dying system and never did serve any really useful purpose. We recognized Bell Labs recognized it was a dying system and abandoned it, in 1970 or '71. I can't the exact date.

MSM: It's gotta be '69.

Morris: Maybe. Yeah. All of my dates back then are plus or minus a year.

MSM: That's what references are for.

Morris: Here was the possibility for creating a computing environment. That was actually somewhat forward looking. Using what then had become relatively common facilities for multiple users on, that is multiple access to a time shared system. So, that the access was broad and usage was broad. What we had at Bell Labs up until that time was pretty much big machines somewhere in the basement. Inside a room somewhere and you put a deck of cards down and that's the way the job run. That was all very well when I arrived at Bell Labs in 1960, that was the way computing environments were. Uh, but, during the '60's people had gotten way, way head of that and here was a project that was attempting to and eventually did get us back on the track. On more or less on an up to date computing environment. By no means a first, God it wasn't the fifth, there were just in my own experience that I personally used not just a handful but a considerable number of predecessor systems of that sort. Remote access for multiple users and provided reasonable computing services.

MSM: Had you used them at the Labs or in other projects, you were involved in?

Morris: Well, the Labs itself, themselves didn't have much. The labs itself had nothing of that sort. MULTICS would have been an attempt to go in that direction. But it failed for reasons I guess that we don't often hear. Too big, too complicated. The best quotation of getting MULTICS to do something is like kicking a whale down a beach. No, I had used systems at MIT. I give them credit for being the first off the market. They produced the first system of this sort. Of which UNIX was a simply logical development, eight years later. But, the system that, again all my dates are plus or minus a year, the system that MIT produced in 1963, called CTSS, basically showed the way for all the others. By '66 or '67 I was using a home grown time sharing system, at Berkeley, and the work, just one they basically built themselves.

MSM: Is this the Genie system?

Morris: Huh?

MSM: Genie? Or what was the name of the system at Berkeley?

Morris: Oh God. I don't know. Berkeley timesharing system, I think.

MSM: Okay.

Morris: Ran on a SDS-940. I don't think it had a fancy name, but it was a project that was home grown within the electrical engineering department, and uh, I had used it by that date. I was at Berkeley in '66 or '67. There were several commercial time-sharing systems. __ So, it had become reasonably common. I went back to Bell Labs from Berkeley, in the summer of '67. And uh, we were still kicking MULTICS around and it didn't seem even at that time, to have any future; I never took much interest in it. I spent some time working on it. But really as little as I could get away with it. It died, whatever date you said. Basically, Ken Thompson saw some machines kicking around that weren't being used and decided to set up a time sharing on them and uh, at that point, it was pretty much his baby. I saw it happening but I did not participate. He got the rudiments of a system to work on, oh God I don't know. PDP7 PDP9...

MSM: The PDP7 was the first one.

Morris: Something like that. They're both the same. I'd have to physically remember how big it was.

MSM: (Laughing)

Morris: Between the PDP7 or the PDP9. They're the same machine. They run the same code. Got that going though was really only the rudiments of an operating system at that point. It handled input, output. Some scheduling of processes. But certainly did not for multiple users. It supported one user, sort of. I've forgotten whether it supported one user, so long as he was at the console or not. But, it was along those lines. It went along and never got a heck a lot beyond that point. Or, Bell Labs computing. Bell Labs situation otherwise was dependent on monolithic mainframe computers. That was viewed by them as the way they wanted to go. The wave of their future at least and they continued on. Somebody, I guess just Ken needed to scrounge on a machine. In which he could put together a viable operating system that for which the PDP7, PDP9 version was just a forerunner. I think, whether and to what extent he asked his own management for support for this I don't know. Certainly he didn't get it. But that is neither here nor there. Well, actually he did both here and there. (Laughing) He managed to con I think the Murray Hill patent department into paying for the machine. I'm sure of that. Chris would know better.

MSM: _

Morris: Promised them and eventually delivered a system which would provide them significant economic savings, in their patent preparation operations. That actually happened. Got the machine, I think they paid for it. that would have been a oh God knows PDP something with very low number, 11-2.

MSM: I think it was eleven forty-five.

Morris: Before that.

MSM: Before that.

Morris: Eleven forty-five is distinctly later. I think eleven-twenty.

MSM: Okay.

Morris: Let's think eleven-twenty. The first machine was quite small. If it was in this room. You could have concealed it so there's not now visible. I mean, I think it occupied about 5 cubic feet. MSM: I see.

Morris: By, so by so. Something like 5 cubic feet. Let's see at this point. Joe Osanna, is clearly in the picture. He's probably the second person to really commit himself to the development of the system. That machine was set up in our space in an attic room in Murray Hill.

MSM: By our space now you mean computer research?

Morris: Yeah.

MSM: Okay.

Morris: Yeah. Don't think of a fancy laboratory, but it was a room up in the attic. And instead of bringing the facility to the patent department, the patent department came to us. There were something like four patent department secretaries resident in our space for I think for several years. I would estimate, two years. Something like that. The system was largely developed including the software, that they used, within present. You could get, to say the least rather instant feedback. Don't like this. Do like this. This doesn't work. How can I do this or why can I do that and things like that. Was rather immediate feedback. At this point we had, currently have Ken, Dennis, Joe Osanna and Rudd Canaday working on it. Those four were really the four that brought. I was nearby. But, again not participating. I saw this happening but I wasn't doing it. Those four people were in it in the beginning and they were the ones that had the vision to turn an idea into something that could kick. But, it was developed initially as a text processing system. For the Murray Hill patent department. That was the surface reason for its creation. Right from the outset.

MSM: When did it catch your attention as something you would want to work on?

Morris: Within a year after that.

MSM: What about it that caught your attention?

Morris: Just what I said at the outset. That it seemed like a distinct step away from the, by then one can fairly say bankrupt notion of computing a cardex on the monolithic computers. You put your job into compile and you go back an hour later and get it and discover, there was a compilation error. First of all very inefficient. The wrong way to do things and what caught my attention was simply that, and I had had tremendous experience in software. I was a heavy user of CTSS at MIT. Heavy user of the Berkeley time sharing system at Berkeley and UNIX was a derivative of all of these. It would be too much to say there was nothing new in UNIX. But, that's not often much of an exaggeration. Obviously tremendously derivative on what existed at the time and what have you created in the past.

MSM: What were you using a computer for?

Morris: Me? I'm a mathematician.

MSM: You were using it to do math?

Morris: Of course, also the text processing. Because, I wrote my own papers. I mean part of the way a mathematician survives is by doing mathematics and also another way of surviving is to publish papers. Any paper that I was writing, and there's was always something on the fire. The text preparation was certainly being done, on some time sharing system and after UNIX arrived on it. So, that I was there probably about a year after its creation. The. That was damned near it for a long time. Probably another three years or so. During the time I was with it, I didn't do that work. It really turned into a fairly complete system. With the system utilities, you would need and expect to do the ordinary things you expect to do with a computer.

MSM: Did you add some of those utilities yourself?

Morris: The one thing that I did, from the earliest times was the, was to contribute most almost all perhaps of the mathematics related, arithmetic related software. The mathematics, I don't need fancy mathematically things. I mean that if the system printed up a date on your terminal. The chances are to get the numbers and that date. It went through software that I wrote. So, when I mean invented software. I really mean in a broad sense arithmetic software. I did a great deal of that. So, just stuff that involved numbers for whatever reason. Like entering a date, or receiving a date. All kinds of conversion type stuff. Conversion of numbers to form or another. Because these things are really held internally anything like the form that you would expect to see them externally. Also, I wrote the fundamental service routines that computed the commonly used mathematical functions, sines, cosines, tangents, logarithms, exponentials, things of that sort. As far as I can recollect I wrote all of those plus some specialized things. The so called desk calculator. Still pretty widely used. Though I didn't write it for the public, I wrote it for myself and that's true of a lot of software that people are buy and large writing software according to their own standards. The way they wanted to. For their own use, and the use of their friends and associates. Certainly no notion in the early '70's that this was going to become a country and of worldwide time sharing system that everybody and his brother would be using. We did not contemplate that and certainly in early times. The software was just not written anything like that. The desk calculator, which was now used by, I suppose, tens of thousands of people. I wrote it for one person. Myself. Period, and the reason for it actually that fairly early on it replace an earlier version of it by something else that I needed to do a lot of coefficients in order to install sine, cosine, logarithms, and stuff. I needed high precision arithmetic to do that and DC was the vehicle for that. There's another program called BC which is just the same stuff.

MSM: I've used BC.

Morris: Same stuff. Repackaged.

MSM: You put that together, cause you needed it. But it eventually became a utility that others used and others contributed their packages and one of the other things that struck me is that there is certain if not uniformly consistency of approach. Or am I misreading things?

Morris: It depends on your point of view. Some would say and I feel a consistency of approach in style in general, orientation and in attitude, but, there are others, critics who at some justification observe that in the ordinary commands one uses day to day, it seems like nobody was talking to anybody else there that they are all maybe similarly or generally but enough different in detail. A total pain in the butt. Some arguments have dashes before them. Some arguments that, ordinary functions have dashes before them. Require the dashes but for the argument, for the command. Some require them. Some forbid them. It takes some experience to guess which is which. There certainly is a uniformity. It did not extend into enough detail, that that is a widely held view. I view it that way. Later on I got into other things. One of the contributions that I put in was, all the password related stuff.

MSM: May I ask you about that? When did it acquire password in some form of security?

Morris: Some form of security? Right from the beginning. I can't remember when there wasn't some forms of password security, that they weren't used. But, there were there. The initial version of the system. When it first got on the air. Every user could have a password. But, most didn't. Which was very unusual. In the early 70s, for anyone to actually use a password. They were available. The password itself was kept in a file somewhere and now you begin to get into problems of being able to keep those passwords on a file. So, that they could be entered, or when people entered passwords or changed passwords. They could be awked up when the system needed to check the authenticity of something. But, yet you wanted to prevent others from either reading them or changing them. So the clear text so called, let's call it clear text passwords, unencrypted passwords. I was having an argument at some point with somebody. This was certainly rather early '70's. Probably '73 there about. Again, everything plus or minus a year. But, we are talking after all about a twenty year old offense.

MSM: Exactly. (Laughing)

Morris: The notion that I had was to encrypt them. Pretty standard stuff and has been for a long time. But, that wouldn't quite do the job. If the algorithm used to encrypt them was readily available, because anybody who wanted to mimic a real user. Just had to mimic the encryption. Which though you might be able to keep it secret for a certain period of time it would eventually become known and what I bet I could come up with was, and though I did not know it, this trick had been done before, whenever, I don't think ever published. Somebody in England had done the same thing was to find an encryption operator who would work in the direction of turning ordinary passwords into encrypted passwords. But, extremely difficult to go the other route and that is proving to be true. It's seems even now, and God knows the current version of UNIX password is encryption, the current version is close to fifteen years old. It is much older than ten years. Expect fifteen or fourteen years, people still don't seem to be able to have any edge at all on going backwards. Obviously, you can try things. You can try things automatically. People run whole dictionaries through the damn thing.

MSM: Yeah.

Morris: That certainly works. I made that as slow as I could. But, I couldn't arbitrarily slow and I knew the future was going to be faster and has just turned out that the future is faster. And originally, I put the routines in so that the amount of time it took to do the lookup of a password was about as slow as I felt people would tolerate them. 'Bout a second. Things have speeded up now. It could even at that time been sped up by perhaps a factor of ten. But, still that ten per seconds, it takes a hell of a long time to go through a dictionary.

MSM: Yeah.

Morris: Machines however, are perhaps twenty times faster as they were then, and now what I had originally had the that version was used on-line. Which took about one second per password, is now doable in something on the order of 10 milliseconds.

MSM: Really.

Morris: It's a lot faster.

MSM: But, no big deal. Expected. The only question was when, and five years hence it would be some other factor faster. It still takes awhile to go through a dictionary and encrypt all the words in it. That remains as far as I know the only attack on the password algorithm. No one seems to have gotten any edge on going backwards, going from the encrypted passwords. And the advantage of encrypted passwords is that you can keep it openly in the file, and it gives people relatively little edge. It turns out in retrospect that may not be the wisest thing, but you still can do it without total loss of security, as long as you can look at a password file and has everybody's encrypted passwords. You still got a whole lot of work ahead of you, to find out what their passwords were.

MSM: I was, I was actually in that file the other day in my own machine. Because, I was having, seeming to have trouble with a password command. Someone said, "Just check the password and see if its changed..."

Morris: ...and it would tell you.

MSM: ...and it would tell me.

Morris: If it succeeded in putting in a new password, by God, it would change. The first one that I put in worked but it had draw backs, of which the main one was that it could be made to run too fast. That was probably first put in about 1973. It was changed in a major way about three years later with an algorithm whose main advantage was actually that it was much more slower and pretty hard to speed up. Anyway those are two of the principles things that I contributed to the system.

MSM: Did you see those as interesting theoretical problems or ___.

Morris: Oh the password thing was just a side issue. I just, just like I fix bugs and so forth in one way or another. The password stuff was not central. The arithmetic stuff fell into two baskets really. One was general service routines for the people who wanted to do genuine computation on computers. A rare thing now days. Now days computers you use text processing, not arithmetics. But, that's a change that has really taken place in during my working career. That changes. When I came to work at Bell Labs in 1960. That's what people used computers for.

MSM: Surely, it's primary use was in numerical analysis.

Morris: Not just the predominate _.

MSM: Sole users.

Morris: That changed through the sixties. So, that 1960 was a hundred percent. In 1970 there was considerable amount of text processing. In by now it 's almost unheard to hear of someone using a computer for numerical analysis. It just doesn't happen. I mean I don't even use my own computer to perform numerical analysis. I use text processing one kind or another. Oh maybe occasionally I would run some numerical programming. It's a rarity. It's not what it's there for. So, one basket is certainly the...

[END OF SIDE 1]

Morris: You back again?

MSM: We're back again.

Morris: Yeah. The service stuff that simply contributed to the system being a complete operating system but had the kinds of support and service mechanisms that one would expect. Part of it was that and the good part of was really doing my own work. By and large, when I did things like writing sine, cosine, tangent, exponential, and logarithm functions. I tried very hard to some success to first do a very good job and second there was a enough originality in it that most of the work of that sort that I did got published.

MSM: I see.

Morris: Sooner or later. So, that was genuinely part of the research I was doing. Mathematical component. Not a side issue. Passwords were always a side issue. There solved immediately an irritating problem that we have more than one copy of the password file. Because, of the old style password. We had more than one copy of. One copy you could look at and one copy you couldn't look at. You needed to look at some of the information having to do with log-in names, because for example you would simply be able to know who was logged-in. Or you would want to mail something to somebody. Something of that sort. So, and we did have and they were always kind of out of synch with each other and never worked out right. The, so, one of the important perceived advantages of an encrypted password scheme was the new ability to keep all the user related information in single file. Now, it turns out in twenty years, retrospective that ain't a hot idea. What the hell. What does turn out to be a good idea in twenty years. I don't know.

MSM: Twenty years from now it may look like a good idea again.

Morris: At this point in proceedings there were, to the best of my recollection, and I'm talking about 1973. Five people working for ___ Unix. Well except that Rudd left. But, for a long time it was Rudd, Ken, Osanna and myself and Doug. That's about it. During the period of time where it developed from the idea for an operating system to a fairly complete operating system things that people wanted to do. It was really those five or six people that I mentioned.

MSM: So, what was Doug's role?

Morris: Well you see Doug was a manager and he had a supervisory responsibility for the whole thing anyway. It was all being done by people, I think all in...He was a department head and I think was being done by people in his department. There may well be exceptions but, most of them certainly were in his department. So, at the early stage. He simply watched this happen and thought it was a good idea, supported it, and helped in an administrative way to make it happen. Perhaps a couple of years later, he was right along in there pushing along with the rest of them. On the technical level. That's why in this stage I include him. I don't mean Doug as a manager as a department head. But, as a technical might, he was in there by 1973 thereabouts. But, at the point, when it was turning, say when we had encapsulated the system for the patent attorneys. That machine by the way got sent back to the Murray Hill patent department, with the secretaries, and they had a locally operating system built for them. To their requirements, that they used quite some years in the PDP1120 I believe. Its at that point that we get a 45 and again to within the usual inaccuracy. I'd say '73 or '74.

MSM: Okay.

Morris: You know in the best of all possible worlds there may be places where we could actually determine that, rather than getting people's guesses, but this ain't the best of all best possible worlds, and I know approximately. Others would also know.

MSM: That's what archives are for, and other sources.

Morris: There aren't any archives. Most of this information is anecdotal and long since lost. I think.

MSM: Well one of the things I want to do is to look at, track down the case numbers of some of these things, these projects that were associated with it. But, as you say, a lot of it is just cross checking people.

Morris: I remember for example, one piece of software that I made a noticeable change in. I was listening one day in about 1974 to Ken and Dennis arguing about when something happened and even at that point they couldn't agree to the nearest year it happened. They had a printout in front of them which had the date on it. Month and day of the month and I looked at them, looked at the piece of paper, their argument and in my best Southern drawl. I said, "Ah shit," and turn around console and actually changed the print programming program called PR and so it would now print out the year.

MSM: (Laughing)

Morris: I did it and I did it one day without anybody noticing it was in 1974. It was not part of the original package. Find the sheets. If you see them. Which were printed before that. Do not have the year on it. At one point, I put that in just for that reason. Because, we were already losing the precision of knowing when things had happened and paper records that should have settled such questions were not in fact settling. (Laughing) So, I was the user, and of parts of it I was creator, but there mainly in the arithmetic and mathematics. I continued to be a user. I continued to do research on making things on it, beyond that. But, the creativity slowed down in the late '70's and was practically dead by 1980.

MSM: You mean in the system? In what was going into UNIX?

Morris: The rate of change slowed down tremendously... The rate of change in the early '70's was absolutely unbelievable. The responsiveness of it was also unbelievable. One day early on let me pick about 1973. I was watching Dennis Ritchie do some arithmetic computations. I don't mean anything fancy. He was just adding up a list of numbers. Using DC to do it and as he was typing them in he made a error of typing and DC for no particular reason except just the way it was designed. It could have just printed him a error comment. But, that's not what it did. It printed him a error comment and wiped out the current sum. So, he had to start from scratch and again went back to my favorite Southern drawl. Went in made the change to the first program of DC. Recompiled it and installed it and it when about ten minutes later. Dennis, who probably hadn't seen me, the fact that I was watching him, said, "There's a problem with your program and think I ought to fix it." Hey it's already installed and that kind of thing could happen with any person , any software, any time and was the rule rather than the exception.

MSM: What do you think in...

Morris: In the early and mid '70's, we were basically in the same room with all of our users.

MSM: Okay. What is it that made that, that facilitated that kind of flexibility. Is it the tools? Was it the shared knowledge of how the system worked or...For instance, when you were going in there making those changes. I take it now at this point that you using C?

Morris: Yeah, yeah.

MSM: That made a difference?

Morris: Well actually that program happened to be machine language. But, that's the detail of...the machine language was it in the beginning and B had become available, and B changed to C and I don't remember the date of the, the real date of the change. But, it was '74 or '75. Before the system itself was written in C, and you would expect that essentially anybody wrote for any purpose. But, it is a detail and about that, because BC was written early on. That sure it was written in machine language. I think the reason for it is share of knowledge of the system. But, I think a general. Two things one is general attitude. People contributing system software and that crucial, there were not working toward externally separate departments. We were not bidding on some Goddamn government project. Which meant somebody who didn't know anything had set out a lot of ways of how the system should operate. (Coughing) Excuse me. We had almost total freedom in that and we were able to and it's a luxury. I mean no one could do that kind of stuff with UNIX now. Couldn't possibly.

MSM: That's what everybody says.

Morris: Not with AT&T UNIX. Not with any UNIX. You just couldn't possibly laugh and see something so wrong go with a program. See that it was wrong. Go in, find the place when the change needed to be made and install the result. Hey that was perfectly reasonable in 1974. By 1978, it was absolutely out of the question.

MSM: Did you guys talk among yourselves in a explicit way about this shared philosophy? Did it work itself out? Was it seeing one another's work? How do you do explain the emergence of this sharing of thoughts?

Morris: We all worked in the same room. We worked all up in an attic room on the sixth floor, in Murray Hill. In space that maybe was one and a half times the size of this hotel room. We were sitting at adjacent terminals, and adjacent, and we knew each other and we had always in fact ate lunch together. Shared a coffee pot. So, it was a very close relationship and most of us were both users and contributors and there was a significant innovative for research contribution at all points. As I mentioned, the possibly the best known in name terms of all the quota I put as BC or DC. The. As far as people using code without knowing it, that pales with something in comparison to the sine routine, or, that a lot of the code does just mundane conversions. That's gets for example a date, the year and print it out right on your terminal. That kind of quote don't make you famous. But, it's still going to be there. So, I was a user and I was creating system that in part, in large parts I wanted to use. So, the parts I was creating were in many cases the part, I needed for my own work. So, I was both a user and a contributor. But, that was generally true. It was true of everyone. C for example, everybody I imagine now just happened. Well, it didn't just happen. In one form or another, was in the process of being born for very nearly a decade and I watched most of it. I wasn't a contributor. Well I used to bitch about it. Bitching about someone else's software was always a contribution in those times. I was not a contributor, but I saw it happening and it was basically transition from a language developing in Britain called BCPL. Got important in this country and it was some attempts to get it or some like it going on. MULTICS never panned out, then Multics never __. Then a version of it, a modified version of it turned up on UNIX written by Dennis, as B, the language B. It was an outgrowth of BC and an improvement on it. But, then turned into C. Mid '70's. Before, '75 certainly. A tremendous amount of development had taken place and Dennis wasn't just batting his gums. He was doing a real research in programming languages. In process of taking relatively antiquated BCPL that nobody's ever heard of. I mean the only reason anyone has ever heard BCPL was because it was two times antecedent of C and that the C that was originally created ain't the same C as exists in UNIX now. It's called the same name. But, I had the interesting experience of not too long ago. Maybe two or three years ago, to compile a program, that I had written. In about 1974 or '75. Fairly complex Boolean _ program. I compiled it and I think I as a result hold the world's record on error comments from a compiler. I ran it through a error checker called... It does a better job than C in outlining your errors and miraculously I got seven thousand knots. On every single program. A lot of things had changed and you know much of it, I could look through, I actually wanted the program, look through it and see a third of comments were all on the same subject, that a particular piece of the syntax had changed and I hadn't bothered to change. I fixed that and looked at what the big winner was and I think in four or five hours I finally got the thing to compile. But, it certainly sensitized me that to the fact that the C that started out like, is recognizably a predecessor of the C that now exists. But, that's all it is.

MSM: When I first started programming in C in 1982 and I got some routines. I've had well no were near your record. But, had that same phenomena. Compiling now and getting error messages. That the earlier compiler didn't care about.

Morris: Yeah, and it would have been much. In order to get the ten thousand. I had to go through some significant syntax change. Changes in syntax. That took place in the late '70's. There's a construct if you want to say A equals A plus B. Originally you wrote that A=+B and that got changed to A+=. _A minus turned into = reversed. [editor's note: the tape is unclear here. However, Morris is explaining the change in notation from A=+B to A+=B, and A=-B to A-=B. This was needed to distinguish "A gets A minus B" from "A gets minus B. "] You know that by itself can cause thousands of error comments. But, that wasn't all. That's easy because quick editing of passwords, will take care of that. Some of them were genuinely hard. Because you could no longer quite work on just line by line change. As if it were a syntax change. Genuine facilities that disappear, or change in some service functions for example, whether it disappeared or changed their function in a central way. So, that a significant change had to be made. But, it's still changes. Yes, eighty-two would not be the same of ninety- one. Oh hell a lot closer than '75 for sure.

MSM: You mentioned that Dennis was paying serious attention to developments of programming languages. One of the things that has struck me about UNIX as a system is its close ties to developments in theoretical computer science during the late '60's and especially the early '70's. Did it pick up that...

Morris: The '60's were the golden age for computer science to turn theory into practice in computer science is something that happened in the '60's. Didn't happen much before that. There wasn't much science, and didn't happened really at all. Notice that UNIX is practically the last operating system to be developed. Not quite, but very nearly. There are operating systems which are simply copies. Renamed copies of things that already exist. C is very nearly the last programming language to be developed. Again, there exceptions, but there aren't many. One can only really think of two, Ada and PL1, that were developed since, C, um that's a close one too, PL1 very early...

MSM: Actually PL1 comes before C.

Morris: I don't think so.

MSM: PL1 was under development in the mid '60's.

Morris: I'm sorry.

MSM: It was originally called new programming language. Doug was responsible for the semantics of it.

Morris: I'm sorry, you're quite right. I just got my dates mixed up. PL1 became a reality in about 1967. '66 or '67.

MSM: Because, I went to an IBM workshop. There were trying sell humanists on it as a language. '67.

Morris: It's not much use even now. Perfectly good language, and some what the same features of Ada, but, I guess, I would have to say that Ada is pretty much it. There isn't. There has been relatively. You know those are extreme statements of what of course, could have __ But, the broad notions still exist. That there is been remarkably less research in innovation in both operating systems and in languages. Since the days when all of us were getting geared up to do this kind of thing. Late '60's. Those were the good days to do those then. The good days don't much seem to be here anymore. I don't see comparable activity taking place, beyond mid '70's. It hasn't. The operating systems that one encounters that are newer than that are so bad as to be almost laughable. DOS? That they call DOS an operating system? It doesn't to my mind. It would have generally at least fit the definition of operating systems of 1960's. Certainly wouldn't in 1980. The definition of a operating system is 1960 would have been, the service routines that handle IO that's it. Period. By 1980, minimum definition for an operating system was process control. DOS don't exactly do that. So, it is indeed almost laughable. But, there haven't been, there has been remarkably little innovative in programming languages and operating systems. Since the UNIX experience. It was the right time to strike and one of the best things about UNIX is. Isn't anything in UNIX itself. But timing. It was a darn good system, coming out at essentially exactly the right time.

MSM: What made it the right time?

Morris: I don't know. I know the Ken was help selling the system and this is all hazy in my mind. Because, I wasn't even particularly close to that. I know that it happened. Ken persuading AT&T operating companies to use UNIX? For various kinds of purposes. Not for text processing. But for one thing like maintenance and things like that and quite a few did. The actually, pieces of the government, peddled the idea of using UNIX to national security agencies. I kind of laughed at the people there. Because, are they aware of the fact that the UNIX that they are now running actually got to NSA in the trunk of my car.

Both: (Laughing)

Morris: In the mid '70's. Ken and Dennis and I went down there one day and bought the tape, Which is the direct predecessor of what they're now using. They didn't upgrade to more recent version.

MSM: Oh, they didn't?

Morris: They are stuck riveted the wheel system, it is actually a system that developed out of that tape, that I brought down there.

MSM: No kidding?

Morris: About fifteen years ago.

MSM: How do you, you said that...

Morris: I don't so, that's a definitive answer. I don't know where I was at the time. I thought about it before and I put together in my mind in some of the pieces that make it clear, that it was the right time. I had thought about it and I do not know the answer.

MSM: You said that, if I remember correctly that AT&T had become something of a technological backwater in computing science. Then the UNIX project or UNIX got underway. Was there a change in the place of computing at the Labs at that time? I mean, I know that at first the project wasn't encouraged but by the same token, new people were being hired.

Morris: In the crucial years, it was not supported. The years that made the difference between it continuing and not continuing. The best one can say management role is, they didn't manage to kill it. Hey, that's fine. In many other organizations, they would have managed to kill it. At Bell Labs, they didn't. I don't see an awful lot of distinction. I was originally hired in the engineering department at Bell Laboratories. Promptly within a year transferred into math research, and computer science was then viewed as essentially a part of math research and indeed my training is, was, is a mathematician. There are relations in a certain way that I do computing and there continue to be relations. The um. We had an IBM 7090 basically, well it had been a 704. It became, in that term 7090. Then that turned into a 7094, etc. The whole period, about a decade, '58 through about '68. Not terribly much changed during that period. At the beginning of it. There was relatively little need for computer science and the parts we did need, had some support. This would be, for example, numerical analysis, support. But, not much and by say 1970, we just sort of '68 through '70 which is sort of crucial date of what we're talking about. This situation was much the same thing. We really didn't have a bunch of people, who were trained in computer science in the way you would expect. Numerical analysis was still getting some support. But, considering the organization, actually to my mind, surprisingly little. Or, this may not have been a management decision in supporting it. Maybe it just getting and holding those people was hard to do and indeed it was. For us, I think in general, it was a good time to do that kind of stuff and lots of people did. They were doing exactly the same thing when I was out in Berkeley, two years previously. People had been doing the same thing. At MIT, eight years previously, they continued and theirs was the, I mean they really were first off the market. The fundamental underlying of ideas came MIT's CTSS. Which stands for something. Compatible time sharing. Some nonsense like that. It was the right time. But, you have to have the right people put together. We did and I think that's a accidental, and. Things would be much more if we hadn't. ___Ken was one that wanted on and saw a machine not being used. He said, "Hey, that machine's not used, you ought to fix that" and that's one important piece of it. Dennis, Rudd Canaday was in with Ken on that end of things. Dennis came in very shortly after and basically and Joe Osanna, probably at or before the transition to the PDP11. I know they did in fact. But, having those people all put together. Having to be the right time and I have no explanation for having the right people all together at that time. Is just an accidental piece of magic it happened. I don't know why.

MSM: Did you, that original core group play any role, selecting the second generation? There is, the core group you've talked about, it doesn't include Brian. For example, or Lorinda ___[NOTE: Probably Lorinda Cherry]. Can one talk about generations involved in this?

Morris: Not really, because people are showed up essentially one by one and simply joined the group. Not in any formal way. But, in some informal way and no there is no such thing as generation, because if you look into where all this lists of people you were talking about had some involvement here. Say by about seven or eight years later. The original people still there and the number of people who had left, was really quite small. I think by 1979, by 1979 the dye was completely cast. UNIX was a living, going thing and what we have now was inevitable of the situation in '79. By that time, I think the only people that had left were Rudd Canaday and Joe Osanna died. Roughly that time period. I would say around '78 or '79, again, the usual plus or minus a year, of the rest of the people that had originally started on it, were still there. The people that had drifted in later.

[END OF SIDE 2]

[TAPE 2, SIDE 1]

MSM: Okay. Uh. One of the more revealing statements that came up in an earlier argument. I was talking to Joe Condon and uh asking about his encounter with the machine because he was in many ways a user of the system... Morris: Oh yes.

MSM: ...and I said, I forget how it came up. He said one day he went to you he went because he didn't find the manual much help and he said something like. "How do you know what these commands do?" He said your response to it was. "What you think they ought to do. Uh. That is what would make sense for them to do. That's pretty much what they probably do do. "

Morris: Excessively a flexible attitude.

MSM: (Laughing) But he took that as sort reflecting of philosophy of what we call UNIX. Do you remember that encounter?

Morris: I don't specifically recognize the encounter. It's the kind of thing I perfectly would have said. Should have said and probably did say. I've had conversations myself that are much the same line. There is for example a collection of formatting software that formats basically mathematically text. There's something I use in my own writing a great deal. Its called EQN, and neither here near there. When it first came out I sort of made a deal with the author of it. That must be Brian. Yeah. That the damn thing ought to work and it ought to work in obvious ways and I didn't have a manual. Wasn't going to get one and never intended to look at one. That if something that I tried is a natural way of creating a construct didn't work. Then the program needed to be changed. His view was and that's in line with my conversation with Condon. His view was completely supportive of that. Uh, uh. That uh his view was if I used common sense and tried to create some construct, uh and I wrote integral from A to B of X that it should damn well produce a nice integral sign and an A at the bottom of it and a B at the top of it and an integrand and do all that without a lot of messing around and if it didn't recognize common sense ways that ordinary people say this is mathematical text so ordinary people who were writing that mathematical text. Then it ought to be changed. And that's the way it stayed. I'm still a user of EQN, and I still never seen a manual with EQN. That's one of the credible ones. Because there are an awful lot of possible differences. I mean looking at competing packages of that sort damn near unusable, because you have to learn so many rules to operate them. Uh, uh. That by the time you learn half of the rules, you're already bored with the whole thing. And uh the, you attempted to do the whole thing in long hand.

MSM: Well WordPerfect has embedded EQN in their mathematical interface?

Morris: Have they?

MSM: Yeah. That's how it's based. I find out you could just write each EQN statements off the keyboard and the mathematical editor will format them.

Morris: That must be more recent; I'm still dealing with...

MSM: This is the WordPerfect 5.1.

Morris: I'm still stuck at 4.2.

MSM: 5.1 has mathematics editor and uh you can have an EQN expression in a file and just import it will become the equation.

Morris: Okay. Well it was a real piece of work. You know it was good time for creativity. Because in many cases what you did in those years changed the world. Uh, uh. yeah. You didn't know at the time what you were doing. In retrospect it turns out a lot of things people did. Awful lot of decisions people made. They restocked and they changed the future. And uh, in hundreds of different ways so that not just the effect is just not on current UNIX the effect is on, current computer environment in an awful lot of ways as you say. Found it's way into WordPerfect.

MSM: Yeah.

Morris: Crazy.

MSM: Did anyone lead exercise any particular leadership in this enterprise?

Morris: No.

MSM: It was more cooperative?

Morris: It was. I don't think there was any time when there was any notion of anybody adopting on leadership. Uh. If Ken, uh, asked somebody to do something, the answer would be, "Go suck a grapefruit."

MSM: (Laughing)

Morris: (Laughing) Oh no matter who he asked. Or if someone in the group had been asked to do something. "Do it yourself." Uh. No. There was no leadership that I detected for being in, was community. No I can't imagine you've heard anything different from that.

MSM: Well I haven't.

Morris: No.

MSM: Well it's a question I...

Morris: You better ask questions. I'm running out of free flow remarks.

MSM: No. Well. It's actually it's been very revealing. When did you leave Bell Labs?

Morris: I left the environment of Bell Labs Research and went to work on a particular focus project at Whippany.

MSM: Uh, uh.

Morris: Military Project in 1981. Uh, uh. I worked on that for about five years. About five years later left Bell Labs at the termination at that project in the fall of '86. Pushing five years now. Uh, uh.

MSM: You felt part of the UNIX project up to that point. Or was there a point you felt UNIX was on its own.

Morris: No. I was part of the UNIX project until I left Murray Hill in '80 or '81. Uh. But the rate of change and the rate of contribution had slowed down tremendously by then. Uh. People were by and large off on relevant but tangential potential things by then. Uh. The all the examples that I brought out is extreme creativity responsiveness throughout early and mid '70's. Uh. The rate of the possibility of that happening simply continued to decrease throughout the 70s until about 1980. It was at that point simply no longer possible. Just say such and such piece of software needs a change, I'm going to go in and change it and install the change.

MSM: That's the bitter price of success.

Morris: Oh sure. But by then of course we had customers all over the damn place. I don't know when Berkeley came into all this. But, relatively early on and I talk in terms say '79 is a good date. We're talking about a complete delivered system that uh is basically the, obviously the predecessor in software now. Uh. The uh. Once either that had happened or feared that it was going to happen. That kind of up and at them creativity was simply no longer appropriate. Because you just couldn't cope with the system of some guy might come in with a hangover and decided he was going to change the way he did things. If the six people are all sitting in the next room. You could say that next morning or at lunch. Hey, I changed the way everybody does things. This is the way everybody does things. That's okay. But, there came a time when that was no longer a user community or user group and uh, perfectly obviously just wouldn't go to that. There had to be some notion of stability. Stability was not one of your watch words in the early days. The system was anything but, not stable.

MSM: (Laughing)

MSM: Thank God. Any further thoughts?

Morris: No. I'm running down on free flow.

MSM: Okay.

Morris: Your questions or subjects.

MSM: No. I've managed to get my questions in too. I'm may at some point think of them.

Dennis Ritchie

The interview date is unknown

Ritchie: He's [Ted Dolotta] involved with - I'm not sure whether it's as a job or whether it's a looser association with some magazine publishing group, that has magazines in Japan. So this was actually for a - to be published in a Japanese magazine.

MSM: Japan seems to be his new stomping ground.

Ritchie: Yes, he spends a lot of time there.

MSM: Yeah. Fortunately, on expense account.

Ritchie: Yes.

MSM: You worked on Multics didn't you?

Ritchie: That's right. I was a graduate student; I worked part time at Project Mac. And there that was sort of the beginning days of Multics. And when I came here - fairly soon after I came here, I also got involved in this part of the [inaudible].

MSM: [Inaudible].

Ritchie: Ah, well it was sort of two different things. At MIT mostly what I did was documentation. I sort of read things. Wrote some descriptions of various aspects of the file system. Did not really do very much programming at all. At least on Multics. When I came here it was divided up, and one of the things that was going on here was working on the terminal [inaudible]; output devices, input/output devices. Things had already begun to quiet down in terms of activity at the Labs. At one time there was a fairly extensive amount of work. Quite a few people involved. And this had pretty much been stopped except for the group here at Murray Hill. And there was a fairly small number of - and that involved Peter Norman, who was with us earlier, activist who was most interested, plus Joe Osanna, Thompson, and various other people would occasionally be involved. I sort of got into that fairly - when I first came I thought I'd stay away from it for awhile. But, then, as things worked out I soon got interested in what was going on there.

MSM: Then your special interest as a grad student?

Ritchie: My work was fairly theoretical. It was in recursive function theory. And in particular, hierarchies of functions in terms of computational complexity. I got involved in real computers and programming mainly by being - well, I was interested even as I came to graduate school. But, I guess it was even the first year I was a teaching fellow in the introductory programming course and I continued that for at least, I guess, at least three years. Being a teaching fellow in that course and also a couple of others, but, ah, this was at Harvard. The computer situation was fairly - reasonably backward there, it characterized [inaudible] quite well-known people. But they didn't really have a comprehensive program. Of course this was early 1963.

MSM: Your Harvard class was '63?

Ritchie: Yes.

MSM: Okay, then we overlapped by just a year then. I was Class of '60.

Ritchie: At that point there were really weren't any, any computer science probably was not even called that practically anyplace. Harvard has always been part of the sort of strange relationship with the subject. That's what's [inaudible]. At that time in particular there were individual courses that were for people who were quite well-known. So, as I said, my actual thesis work was on - was fairly theoretical but I spent a lot of time, also, doing programming.

MSM: Was your thesis work at Harvard?

Ritchie: Yes.

MSM: And in the recursive function area, who were you working with?

Ritchie: Pat Fisher. Who, when - I guess the last year or so he went to the University of British Colombia. He is now at Vanderbilt. Pat was sort of not really the Harvard advisor. I was fairly independent.

MSM: So you wandered down to Project Mac for a summer job?

Ritchie: It wasn't a summer job. I think by that time I guess I was just more interested in doing programming. I don't know how I even found my way to it, precisely. But it was a part-time job throughout the year. Basically to support myself.

MSM: How did you come to Bell Labs?

Ritchie: My father worked for Bell Labs. Hence I knew very much about the place. I knew it because also he was involved with telephony. I came to know the Multics work from MIT. I actually interviewed at several places at Bell Labs. I was out Indian Hill and Whippany as well as the research group here. And this certainly looked the most interesting.

MSM: Did you have an idea of what you wanted to do? A specific sort of agenda in mind?

Ritchie: Not a specific agenda, I would say a general agenda. I guess I definitely wanted to be - by the time finished school it was fairly clear that I didn't want to work anymore in, I didn't want to stay in theoretical. I was just more interested in real computers and what they could do. And particularly struck by the - how much more pleasant it was to have interactive computing as opposed to decks of cards and so forth.

MSM: Had you met that at MIT?

Ritchie: Yes. That's right.

MSM: You worked on CTSS there?

Ritchie: Yes I used CTSS because that was what was used during the development of Multics. I didn't work on that - I didn't have anything to do particularly with the development or maintenance of that system. I was just a user. And, ah...

MSM: At Harvard, at this time they were probably still throwing around card decks.

Ritchie: They were still throwing around card decks. They had some things. They had - there was a thing called, there was a thing--an interactive system that was run out of some place in Southern California. The Color Freed System, which was a fairly special purpose math system. It wasn't symbolic. It really manipulated graphs and functions and could do pointwise arithmetic and functions. It was fairly crude. I mean it was sophisticated in some ways. It did things that were unusual and it had a very fancy special keyboard and all sorts of strange labels on it and so forth. And it was also a cross country connection if they managed to get a phone line in. A data line in to California which at that time was something really very fancy. But that was not, not really generally used. That was a very special sort of experiment of some sort. I was not directly involved with it. I just sort of saw it. The interesting thing of course was that within a few months of that I saw that someone had, at MIT, essentially a simulation of the system on CTSS. Considerably more greater convenience than trying to keep this cross country data link up. Anyway when I came here the Labs was in essentially the same state as far as computing was or a very similar state as Harvard. There was Multics, and the main conflict for the experimental [inaudible] the people who were working on the system was not wide spread. The comp center also had another GE645 which was a Multics machine. But they used it as the GE635 which was the standard large machine with an all-electric main. And at that time the system running on that was just a BAP system. Later they began getting a fairly crude interactive system built on top of [inaudible] which was the name of the operating system for the 635. But Multics was definitely the most sophisticated interactive system there was. And it was really the disappear - the combination of the disappearance of Multics, what it did two or three years later. And just the fact that Ken had always wanted to write an operating system of his own was what led fairly directly to Unix.

MSM: What attracted you to Ken's enterprise? Were you also interested in operating systems or was it that his work held some promise in getting back that interactive system that you just talked about?

Ritchie: I think it was probably a bit more of the later. I knew him already. We had been working together on Multics. There was this strange period which seems now to be longer than it probably was, of maybe 6 months, a little more in which we were agitating very hard to try and get a new machine of our own. A fairly substantial one in the half million dollar range. Nearly 25 years ago, it was a lot more even than it is today. And that sort of was at several stages that sort of almost seemed to be about to go through. And never did. And so we were sort of frustrated with that. Ken actually made a couple of starts at doing the system before there was any special hardware. In the very last days of Multics he actually wrote a very, very inner part of an operating system for the 645 machine standalone. I think he got as far as making it a few characters on the terminal. That didn't really go very far. And it was obvious it was pointless to waste time on it because the machine was not going to be around.

MSM: And you planned on following that?

Ritchie: What I'm getting at is that we had been sort of involved with working with each other in various ways. I had been doing other things as well during this period. I did a compiler for the Altran system which was Stan Brown's algebra system which was completely independent of Multics and that crowd. That was one of the things that made it particularly obvious that having an interactive system was nice. The Altran stuff was actually written on the terminal. I forget now whether the GE TSS stuff was around then or whether it was actually written in Multics terminals and somehow transmitted. But the representation of the program - in the first place was in Fortran, and in the second place it was obvious we were going for punched cards. Typing out on terminals. But the formatting was very rigid and whatnot. And there were batch jobs and object decks and stuff like that. And it really made it very obvious that having a smooth interaction with the machine was a lot more fun, a lot less clumsy. It was really a combination of things that got me involved. Just the fact that the style of thing that Ken was headed for seemed very much, very desirable. I know this just from the work with him.

MSM: What sparked exercise in file systems?

Ritchie: I think that was basically part of Ken's desire to do a system of his own. So I don't know what very specific thing sparked it. But he started about bosses and he started about paging systems and he actually wrote a simulator for paging behavior and then he and I and Rudd Canaday started drawing pictures on the blackboard or maybe white board. Drawing the structure of this proposed system which was in most ways the predecessor of Unix. Some of the ideas appeared even, I think the notion of special files appeared then. I think that was mine. Most of the ideas were Ken's. I think that particular idea was mine. I.e., the devices had a representation in the file system so that they could be opened and closed and whatnot.

MSM: How much of Multics was behind your thinking in this file system?

Ritchie: The relationship of Multics to this is actually interesting and fairly complicated. There were a lot of cultural things that were sort of taken over wholesale. And these range from important things, the hierarchy file system, tree structure file system, which incidentally did not get into the first version of Unix on the PDP-7. This is an example of why the whole thing is complicated. But any rate. Things like the hierarchical file system, choices of simple things like the characters you use to edit lines as you're typing, erase character, [inaudible] character, were the same as those we had. I guess the most important fundamental thing is just the notion that the basic style of interaction with the machine, the fact that there were the notion of command line, the notion was an explicit shell program. In fact the name shell came from Multics. A lot of extremely important things that we completely internalized, and of course this is the way it is. [Inaudible]. A lot of that came through from Multics. As far as other technical details, there were enormous differences. The scale of not only of both of effort and of resources, of machine resources, was just incomparable. The whole, I forget now how big the Multics machine was, it wasn't very big of course by today's standards, but the first PDP-7 was tiny. It was only 8k words of memory, 68k [inaudible]. So there was a vast difference in complexity. And a lot of that was forced just by conditions. But a lot of it really was a taste as well. One of the obvious things that went wrong with Multics as a commercial success was just that it was sort of over-engineered in a sense. There was just too much in it. And it certainly explained why it took so long to get going. Heavily consumptive of resources, of machine and certainly in terms of people required to produce it. I think there was a real reaction in the design of Unix. But this is sort of going back to the other side again. Another strong resemblance is the way that the I/O system worked; the read and write system calls were essentially taken directly from Multics. At least they're the form of the call. On the other hand Multics had a fairly complicated thing called the I/O switch. The argument, the handle that you used to do a read and write was not a file descriptor as in Unix which is a fairly simple object. An I/O screen in Multics that implied a fairly complicated thing called the I/O switch that sort of [inaudible] lots of different modules had a chance to massage the calls as they went around accessing modules and whatnot. And in fact in some ways the Multics I/O switch was like the screen stuff that came much later. On the one hand the read and write I/O system, part of the I/O system in Unix was modeled after that of Multics or at least a simplified version of it. But there was nothing at all of the Multics virtual memory system. That in fact was the most characteristic feature of Multics. That was the thing that made it technically unique. The fact that it so-called one level stored, that the objects that programs manipulated were segments which were named, and the segments caused the memory segments, the things that are visible to the program, that's the named object that you can store into [inaudible] responded also to objects in the file system. That was the absolutely crucial distinguishing thing about Multics. And that just didn't, that was just completely out of Unix. Partly because it seemed very hard to do, partly because it required fairly sophisticated hardware that was memory mapping hardware, segmentation hardware that was just not on any of the machines we had. Until just over the last few years has not been available on [inaudible] of machines. Furthermore, particularly in hindsight and to us, or to me anyway, there was some sort of conceptual problems, in that Multics really wanted to make a very uniform view of the world based on these segments in which the paradigm for all activity was all relationship with the file system was to institute operations on segments in memory. But of course that's not really possible because you always have devices of some sort. We have terminals and whatnot. And those just can't work on the same model. We've got to have a different model for dealing with I/O. And so there were various between these two possibilities in Multics. In particular there was a thing called the FSIM, the File System Interface Module, that really made a segment, a memory object look like a device. Then you could treat this memory thing in the same sort of way. In fact they cleaned things up a little bit later. But in the original thing the only way you could deal with very large objects was through this FSIM which, if something was too big to fit into a given segment it would use several of them. [Inaudible]. That was something that was inconvenient to do by hand. At any rate, my view is that even though Unix is usually understood does not have this segmentation notion. It only has an I/O notion. If you're going to restrict to one main Paradigm, the one Unix has chosen is more powerful in some sense because in the sense it can apply to objects other than addressable memory. In particular that's how things like pipelines and our current form of interprocess communication and so forth all work. By using this same scheme of doing reads and writes. Usually of course people have begun adding something of the segmentation idea, so called mapped files and so forth. They haven't really made it into any of the standards, probably because they're not really a very portable idea, at least with current hardware. Not all machines can handle the notion.

MSM: You said you're interested in getting away from theory, and getting into real computers. One of the things that I've always found interesting about Unix, is that although it might not be theory driven, it nonetheless it's had a strong theoretical component [inaudible]. Neat and sophisticated programming going on here but generally exemplifies something theoretical or has a theoretical base. How far has the theory been from your activities? Have you had it in mind? Thought it out? Have you chosen to do things for theoretical reasons?

Ritchie: No I would say that I haven't, really. The kind of work that I was doing as a graduate student was in some sense fairly abstract. The kind of theorems that were being proved referred--it was kind of strange actually. It was the area of computational complexity. What functions are inherently more complex take longer time to compute than others. This particular bulk of hierarchies of functions. But the interesting is that that hierarchy began at exponential time. So that was sort of the unit [inaudible] size of its input or the value of its input. And, this really is - in some sense dealing with it was partly like programming because when you design a function to exemplify something it bears a strong resemblance to programming a machine. But the results you get are really totally theoretical because, of course, exponential time things are typically too hard. And the reason it's amusing is that about two years or so after I finished the whole business of NP completeness and all this interesting structure and questions within things that take exponential time as opposed to building on top of that. Suddenly the hot field was the stuff that I just sort of said was sort of baseless. We won't examine this because it all seems a little bit too complex whereas we can get a nice smooth structure. I guess the point is that this particular aspect of things really does not have very much direct applicability.

MSM: The sort of stuff that Al Aho was doing when he came.

Ritchie: There are many aspects of theory that do have applicability. Certainly a lot of the insights into languages.

MSM: Has that been an area of interest to you at all?

Ritchie: Not of great interest. It was the sort of thing that was included in [inaudible] and whatnot. Actually, most of the interesting work in parsing came after I was out of school. [Inaudible]. The notion of parsing generators, and so forth. I think to get beyond just me, though, I think that one of the things that is very refreshing is the fact that there are all sorts of people doing quite a range of different things nearby. In particular both theoreticians and more practical-oriented people. And it's a lot easier to keep in touch with everything they're doing here than it seems to be in most places. So yeah, there definitely have been people who have contributed things that are not just sort of hacking out solutions to the problems but doing programs or systems based on some sort of theoretical principal.

MSM: When we speak of it sometime as a programming environment and yet it occurred to me as I was talking to Al this morning, it's almost a meta-programming environment. It just happened?

Ritchie: Well, I don't think it just happens, or at least it seems to me that there has been a conscious effort to hire people who are fairly broad. Whom they really looked on as a plus, even if you're theoretically inclined, if you have say some programming experience. And the pressures to turn something into something theoretical into some kind of practice, they can be quite subtle and not burdensome, but I definitely think that they're there in this organization. And of course sometimes people justify things in saying - they justify it in sort of theoretical terms, or at least when they're following the area of computers. In a lot of cases it really does happen. Things like AWK for example which was the condition of the program to produce parsers from the grammars. I'm not even sure what the exact historical period is. I don't believe that that idea was his, [inaudible], had already been realized that this was the technique by which the grammar describing the language had produced a machine that would recognize the language. He was one of the first actually to do this and produce a package that allowed people really to use this, as opposed to either proving that it could be done or demonstrating it as some sort of private program of their own, but rather producing a general thing. These people had a language that they wanted to try. That they were using tools to help take the description of the language and turn it into the compiler. I think that was the kind of work I really very much encouraged.

MSM: You designed C.

Ritchie: Yes, although not from scratch.

MSM: I see. An adaptation of B?

Ritchie: It was adaptation of B. That was pretty much Ken's. He actually started out as Fortran. Ken one day said the PDP-7 Unix system needed a Fortran compiler in order to be a serious system. So he actually wrote and sat down and started to do the Fortran grammar. This was before AWK. He actually started in TMG. It took him about a day to realize that we wouldn't want to do a Fortran compiler at all. He did this very simple language called B, got it going on the PDP-7 and whatnot. B was actually moved to the 11. A few system programs were written in it, not the operating system itself, but the utilities. It was fairly slow because it was an interpreter. There were sort of two realizations about the problems with B. One was that because the implementation was interpreted it was always going to be slow. And the second was that unlike all the machines we used before which were word oriented we now had a machine that was byte oriented. In that some of the basic notions that were built into B which in turn was based on BCPL were just not really right for this byte oriented machine. In particular, B and BCPL had notions of pointers which were names of storage cells. But on a byte oriented machine in particular, and also one in which the - it had 16 bit words - and I don't think it did originally, but they were clearly intending to have 32 bit and 64 bit floating point numbers. So that there were all these different sizes of objects. And B and BCPL were really only oriented towards a single size of object. From a linguistic point of view that was the biggest limitation of B. Not only the fact that all objects were the same size but also just the whole notion of [inaudible] object didn't fit well with B. So more or less simultaneously I started trying to add types to the language B, and fairly soon afterwards write a compiler for it. The language changes came first. For a while it was called NB for New B. It was also an interpreter. I actually started with the B compiler. [Inaudible]. Because C was written in a language very much like itself and at every stage in the game. So it must have started with the B compiler and sort of merged it into the C compiler and added the various - the type structure. Then tried to convert that into a compiler. That incidentally was sort of another - that the basic construction of the compiler of the co-generator for the compiler was based on an idea that I heard about from someone at the Labs at Indian Hill - I never actually did find and read the thesis, but I had the ideas in it explained to me so that the co-generator for NB which was based on this Ph.D. thesis. It was also the technique used in the language called EPL which was used for switching systems in ESS machines - it stood for ESS Programming Language. The first phase of C was really, it was two phases in short succession of first some language changes from B really adding the type structure without too much change in the syntax, and doing the compiler. The second phase was slower; it all took place within a very few years but it was a bit slower so it seemed. And it stemmed from an attempt, the first attempt to rewrite Unix. Ken started trying it in the summer of probably 1972. He gave up. And it may be because he got tired of it or whatnot, but there were sort of two things that went wrong. One was his problem in that he couldn't figure out how to run the basic sort of co-routine in multi-programming primitives. How to switch control from one process to another. In relationship inside the kernel of different processes. The second thing that he couldn't easily handle, from my point of view the more important, and that was the difficulty of getting proper data structure. The original version of C did not have structures. So to make tables of objects, process tables and file tables and this tables and that tables, it really fairly painful. One of the techniques that we borrowed from seeing it used in BCPO was to define names who are actually small constants and then use these essentially as subscripts. Basically you would use a pointer offset by a small constant that was named to do the equivalent of naming a field of a structure. It was clumsy. I guess people still do the same sort of thing in Fortran. It was a combination of things that caused Ken to give up that summer. Over the year I added structures and probably made the compiler somewhat better. Better code. And so over the next summer that was when we made the concerted effort and actually did redo the whole operating system in C. That was fairly successful. It took the winter of '73 to do that. And there were no really tough problems.

MSM: People, yourself included have said that Unix was a distillation of some of the best ideas in operating systems in the '60's. I want to come back to that point but let me take a variation on that. Is C a distillation of ideas on programming languages as they had emerged during the '60's?

Ritchie: No, only one aspect. It's definitely a limited language variety in various ways. I think Unix probably covers a lot more of the real important ideas of that period than C does. C is quite low level; all the objects it deals with are really very concrete. The operations it provides on them are very [inaudible]-oriented. The control flow in [inaudible] is conservative in terms of [inaudible] straight line. None of the more interesting things like co-routines of various kinds.

MSM: What I found interesting, I counted when I was writing a list interpreter in C was that even the assignment operator returns a value so that I found that at a certain point that my C routines were beginning to look like LISP routines. I had my little C functions and I started embedding them and I started to get a lot of families of parentheses that were long enough and I said to hell with it, I'm going to do a list by [inaudible] instead. But it does have that applicative quality to it. Was that conscious? Am I right in discerning it?

Ritchie: I think you may be exaggerating it. Either that or you found a particular style and application in which it became more visible [inaudible]. Particularly if you - well, I guess there is a style in which there are a lot of different operators that are of one kind or another that are implemented as functions. But since they are not syntactic operators they have - the functions have to be embedded in arguments to each other. I don't think that's unique to see.

MSM: It wasn't something you had consciously?

Ritchie: Let's see... what are the other ways in which C is sort of [inaudible] covers a small part of the space of languages. I guess that's it mainly. I mean - oh, storage. The different kinds of storage that are possible in C itself are very simple in just the automatic variables, stacked variables and static, statically allocated things. There's no built in off-stack heat type storage. There's no garbage collection. Whereas language design - I mean, probably because it's easier to do a language than to do an operating system, there's less work in producing the compiler. Language design has sort of always had a little more freedom associated with it. There are lots more ideas that are really very different from each other as compared to systems. So no, I wouldn't call C a distillation except at the very specific part of it. I guess the thing that has made it successful - well, there are really two things that are making it successful. One is the association with Unix. It just got carried along. The second is the fact that I think that there is a surprising amount of work [tape reverses] so you can keep a [inaudible] the real hardware details. In particular so that the portability is possible with a little care. There are lots of machine dependent things that can be visible to C programs. Part of the art is to learn what sort of things you can depend on, and what you shouldn't. I guess the only real explanation for success is that there were a lot of people writing in the language, typically prose, are now able to write in C. The programs are likely to be a lot better for it. They do have a chance of moving. I think portability, and keeping portability in mind is something that you really have to learn to do. You have to convince yourself that it's important. It's easy to say, look, this is just a one odd program, and I know it's not going to anywhere but here. Why should I care that this is something that will never work on another machine? Sometimes people consciously do that or just below that.

MSM: When did you decide that Unix had to be born?

Ritchie: That was not in there in the beginning. It did have roots. Part of the claim of Multics was that it was going to be portable because - and nobody ever did anything to try and prove that. They sort of upgraded different newer models of the same machine, but nothing less than that. The business about Unix came because there were a couple of things that were happening. A lot of these interesting tools began being developed for Unix. Things like Yak. And of course since it was not a widely used system at the time there was an effort to make them available to other people. And the best way to do that was to have a C compiler on other machines. Even though the idea in general was quite important, a lot of the Altran project was concerned with a Fortran system. And they were very explicit about making that portable and wrote tools to make sure that the dialect, the subset dialect of Fortran was sort of the intersection of all possible of all possible Fortrans in the world. The real insight that we got - I was responsible for grasping this - was the fact that when moving these programs to - these various Unix tools to - the IBM systems and the GE or then Honeywell systems, the difficulties that we ran into were really not due to the underlying machine architecture, even though C made that visible, or made it possible to see, but really had a lot more to do with the operating system differences. How you do I/O. How you write the so called portable libraries. There were messes in implementing some of the - keeping these programs portable. It had nothing to do with the program itself. It had to with its interaction with the rest of the system. And the thing that really was most important was the thought that instead of really spending all this time trying to make individual programs portable and fighting the operating system, why not move the operating system along, too. In general, the portability aspect of work around here has been - but it took a few years before it was specifically called Unix. Although I have to say that Ken had a - one point early in the game. I think we were probably still on the PDP-7. He came up with this idea of writing in B the very simple operating system that would be very, very portable. It would run on all sorts of microcomputers that were just here. It would not be ambitious. The idea would be that this is something that could be distributed widely. I think what he was getting at was on the one hand something perhaps like UCSD Pascal which was a [inaudible]. Maybe something like, some of these operating systems that people like [inaudible] did. In [inaudible], it was written in fairly portable form. I think that was after this... It was the sort of idea that other people had and it never went anywhere as such. The idea was just put out one day and I don't think he spent any time at all working on it. Even though nothing came of that immediately, or very directly, that was the first sort of specific impulse towards Unix portability. Upright system portability.

MSM: This raises a question of perhaps the timing, your first request - you came off a big machine coming off the big GE's. The first request was either for a PDP-10 or a Sigma 7. You either had to settle for a discarded PDP-7, which is a small machine. And in the end Unix has wound up going on small machines.

Ritchie: Not as small as the original though.

MSM: [Laughs] Well, small is a relative term.

Ritchie: Yes, relatively small.

MSM: But I think also what goes with small machines is not only the question of machine size but also an attitude toward who's going to have the machine, what commitment is one making when one buys the machine, because if you buy yourself a small machine, you have an idea that you're going to use it for a few years and you're going to replace it and it may or may not be a machine by the same family. Maybe next time I'll get myself a Mac or I'll get this or I'll get that. I had the sense that the Labs around 1970 were beginning to make a transition as an Institution from the idea of big central computing facilities and big machines to small machines. Smaller machines.

Ritchie: Yeah, but it took longer. It was not until a few years later that it really began to happen.

MSM: Now, did Unix respond to this or did you help to foster it?

Ritchie: No I think we helped to foster it. I think there was - well, it went along with it. There were a couple of things happening. First, that was when the machines like the PDP-11 began to appear and there had been these earlier machines that tended to be for fairly quite specific purposes. The PDP-7 was a graphics engine. That was the time when a lot of projects began developing what are called OSS's, for Operations Support Systems. The way these worked out were that they tended to be mini computers dedicated mainly to doing a specific support sort of thing for the telephone company. A very typical one was one which would keep - collect and keep trouble records. The ESS machine or Crossbar machine or something like that, you know, spits out in one form or another records of things that have the text going wrong, with individual lines or whatnot. Traditionally these had been punched on cards and then sorted somewhere else by a process I don't understand. The technicians would understand it. And so that an Operation Support System might be something that collects these automatically and puts them in bins and whatnot and makes printouts. These things existed for billing and for taking orders and just all sorts of telephone things. And this was all quite independent of the [inaudible] itself. A lot of people began buying machines like PDP-11's to do this sort of stuff. And some fraction of them - this exemplifies what you're saying, that there were these things away from the main comp center. But at least groups like these, the product they were producing was something that was sort of inappropriate for comp center anyway, it was really a new thing. But of course they had to do their own computation someplace. You know, when you're producing a support system it's not as if it doesn't involve a lot of programming. So I guess the idea of getting your own machine, the departmental machine, along with being more sensible - the availability of reasonably powerful and affordable machines I think was the most important thing. It was not a software issue, it was this. And one of the great strokes of luck was that Unix was a system that appeared at just the time that this new phenomenon that was beginning to - was occurring, because there was really no chance that we would, just as there was no chance that we, or at least, didn't persuade our own management to spring for all this money for this untried thing. There was really very little chance that Unix at that time would [inaudible] someone who was running a big comp center. It was just too unformed. It wasn't even a just a matter of being risky, it just didn't do enough. There were just too many things that inaudible]. That was when people were - the combination of having machines that were sort of affordable and did more or less lead to the effort; they really did more or less lead - ultimately lead to the near overthrow of comp centers in the traditional sense, or at least the great weakening of their power. Software for all these machines tended to be pretty [inaudible].

MSM: You think that within that [inaudible] this operating system that worked on these small machines? Give people added insurance. [Inaudible].

Ritchie: Yes, although there were plenty of projects that were either working on their own operating systems or using manufacturers' systems [inaudible]was clearly a very fertile [inaudible]. MSM: So that was Ken's system, and then he tells me that you guys figured out a way to get the console to act as a second terminal. I mean the display to work as a second terminal. So then it became Ken and Dennis's machine.

Ritchie: Most ideas in the system, and actually most of the working out of the ideas were his, but Thompson was in it from the start, and [inaudible] at least in some phases we sort of worked together, and periods in which we sort of wrote programs together.

MSM: What I was getting at was that issue of leadership/ownership; you must've had a terrific sense ownership the two of you had in the beginning. There must also have been a point at which you had to loosen that sense of ownership to open the thing up. Were you conscious of that happening?

Ritchie: I was conscious of it on and off. You have to remember that this did take, this had been going on over [inaudible] there was no particular moment in which there was a sort of [inaudible]. Even in the '70's there was this history started that Bell Labs [inaudible] that did the programmers [inaudible]. And the point about these groups is that in fact sort of one of the interesting things about the whole development of the system is there always were people outside our own group who were actually [inaudible] never a matter of distributing something [inaudible] other people. There were always lots of people who opened up the box. They always did have independent rules and needs. So it really never was a stage acceptance. The very, very beginning of which he had complete control on what was going on. By continuing to make progress and generally by doing a reasonably good job of producing sort of the next generation of things was an effective, a very strong [inaudible] just because other groups, and this date was later sort of extended [inaudible]. There was always a very strong influence because people tended to pick up what we did and it continued for years afterwards with a diminishing fraction of the total system. As long as the USG had PDP-11's, the compiler that Aho did for the PDP-11 was the one that they used. Even by this time they had their own version of the operating system, that they controlled and wasn't ours, until - probably until this very day [inaudible] at this point we've got [inaudible] fraction at least, and AWK, too, was still owned by the AWK conspiracy, or consortium. So there's obviously been an enormous loss of control over [inaudible], a fraction that we can do anything about. It really isn't spread out over a long time. I guess the biggest realization I have now is occasionally getting into search of things that the Summit People do or the standards committees do or Berkeley does or whatever is just the - things have such an enormous momentum, that to deflect them requires enormous effort. Occasionally we get involved in something and say this is wrong. We really should do this instead of that. Or just not do that. I don't care what you do as long as it's not that. And, it really does take a lot of effort.

MSM: You're anticipating a question I wanted to ask Ken. It's the counterpart to your question about, or to the observation that Unix is a distillation of the best ideas. Were there bad ideas of operating systems in the '60's and about computing in the '60's you didn't want to see? [Inaudible] Whatever else is going to be, it is not going to be this, and it's not going to have this [inaudible]. Do you have any bad examples in mind that you were working early on?

Ritchie: I've never been convinced that Multics's virtual memory model was right, and in an interesting experiment is coming back. I think it was over sold. Of course it was not the common idea even then. It wasn't pioneer enough to do it because very few other people had it. I don't know, I guess we didn't think in those terms. I guess the thing that, particularly in retrospect, it may have happened, some of it unconsciously, but honestly I wasn't very conscious of, is the extent to which things were not put into Unix because we didn't yet know how to - well, a combination of we didn't know how to do them and we didn't actually need them. And this actually caused general weaknesses as far as [inaudible]. The whole business of inter- process communication of which [inaudible] sort of classic [inaudible], the whole business is very cleverly designed to do sort of exactly what we wanted and very little more. It fits together...

MSM: You were talking in your evolution article about essentially the hack of the message this never received. God help the system if it ever worked.

Ritchie: Right, in the later development that went away and the whole business of float [inaudible] and so forth [inaudible]. All this works very, very neatly and there's no need to talk to each other by means of pipes which we had sort of set up. A little more general scheme was put in place and as a result it was a very big succession of word schemes that people, because they felt they really needed to do something. Having one process call another out of the blue.

MSM: I think they were communicating [inaudible] sequential processes was about that time. That was an issue of some [inaudible].

Ritchie: Yeah, everybody else sort of knew that this was required. In the first place it was not required by anything we wanted to do. And therefore no scheme was worked out.

MSM: Did the size of the system, was the size of the machine and the size of the system you were working on dictate that?

Ritchie: In a general way, but not in any particular thing. There was nothing we decided that we could not do because it wouldn't fit. That never happened. There was no specific feature. Put it that way. It induced an approach to things.

MSM: I tend to think that a process communications been using on big central systems and you weren't building a big central system [inaudible] size constraint.

Ritchie: I think more it was a matter of [inaudible] things the style of computing - we were just interested in using the machine in a limited number of ways. It wasn't required for the kinds of things we were interested in doing.

MSM: And those ways, where were they coming from?

Ritchie: It was just a matter of wanting to, most of the programs are either straightforward and interactive commands that we type, or perhaps they derived it. Or perhaps some actual computation that takes in the place in the background. Nothing to do with autonomous events happening wanting to tell somebody that this event is happening. What's a better example? Well this isn't quite in the same track but it does serve. Some people's interprocess communications problems came for reasons that were directly related to the machine being small. And that is that they had something that was logically one single process but it wouldn't fit. And therefore they had to chop it up. And then the pieces had the problem of communicating. That of course is an artificial example. Theoretically it's a sort of artificial example because we shouldn't have chopped it up. But of course they had to do it. [Inaudible]. They had to work because of artificial restrictions. [Inaudible]. Except that there are definitely limitations on Unix. Many of them they are simply because we did not [inaudible] bother with that and the result of something that is a lot more coherent, because we're not going to solve all the problems. I guess the sort of genius in both Unix and C for that matter is the fact that while both languages have this approach they have a fairly strict approach about what they are willing to do and what they're not willing to do. The fact they manage to cover sufficiently large fractions of what people really needed, or at least some group really needed, while still retaining a sort of smallness of compactness of design. It really was not planned that feature, that aspect was not planned in an explicit way. It can't be. You can try but it's very hard to do. And I suppose the reason is that things work that way is that we did in fact start with some fairly well formed ideas on what we wanted. It wasn't [inaudible]. But, these designs were pushed to the point that they still showed that they solve problems that we are interested in solving themselves as opposed to satisfying all the things or doing all the things on a bulletin list, or surveying all the people that we could find and ask them what it was that they wanted. It didn't really have to prove a point in the same sense that most other people do. It obviously was important to make something available as other people became interested. But we didn't have to make a product. We didn't have to write enough pages to get a thesis. It really was a matter of being able to push things in directions that are interesting to go. And you only had to push as far as seemed to be worthwhile. [Inaudible] I think the keys to this that made this succeed where people or talents might not have made such a...

MSM: And similar tastes?

Ritchie: And tastes. It might have been more constrained than in other environments. As far as the success is concerned there was a good deal of luck involved in being in a position to ride this particular wave of the growth of machines that was suitable. Lucky to have the license it required - that the licensing stuff worked the way it did, too. There was a long period being able to have lots and lots of universities. A small number of commercial and government firms kept it on very good terms. A lot of people were interested in the system. [Inaudible].

MSM: It seems ironic it's effective marketing when marketing was not the intention and there was no product to sell.

Ritchie: Yes. On the other hand marketing takes a rather luxurious approach, namely to say we'll give it away for nearly free for ten years. And then start - in most cases you can't arrange that.

Berk Tague

The interview date is unknown

Tague: ???????????????? But you and I were in Boston I guess at the same time. I was at MIT from September of '58 through February of '60.

MSM: I was there September '57 through June of '60.

Tague: Yeah, Okay. I spent a summer, I guess it was the summer of '56 I was at Wesleyan doing my undergraduate work after 4 years in the service in the middle of my checkered academic career. And I was sent up there. There was a 704 that was being run that IBM had 8 hours of and MIT had 8 hours of and a consortium of New England universities had 8 hours of. Wesleyan was part of the consortium. My professor took mercy on me one summer and gave me a grant to go up there in the summer to learn to program. Fernando J. Corbat`o, who I met again in the '60s on Multics, turned out to be my instructor in that course. That was my first real program for the 704. We had programming courses at Wesleyan but no machine and in retrospect it was really rather silly. We had a professor from Yale, an astronomer who came up and had us writing things on coding for him, and for ??????? in that era. I started out in physics and discovered indeed that, one, I didn't much care for the laboratory and, two, I didn't seem to have much talent for physical intuition of certain sorts. And math was easy but boring. And when I went away to the service they cleaned house in the Math department in Wesleyan and brought in this fellow [name] who was really terrific and brought in some real mathematicians. In correspondence courses in the service I had discovered what mathematics really was all about and fell into the camp of pure mathematics for a while there until I made some judgments about what my talents were in that area and my interests. ?????????? career at MIT.

MSM: So you went to MIT as pre-math?

Tague: Yes. I worked with Art Madduck who I guess just went emeritus as being head of the department. I did my Masters' Thesis under him. I edited a Ph.D. program and after a year and a half; looking myself in the mirror saying what are you going to be when you grow up and said let's get out of here and do something with it. I came down to the Labs. When I was in the service I discovered everything good in radar was done at a place called Bell Laboratories. I subscribed to one of the company magazines. I had a girlfriend who worked here one summer. I asked her to get me subscription to BSTJ and she got me a subscription of the Bell Labs Record instead. It was all right. I got some idea of what was going on. Those were exciting times. Shannon was around here. There was a lot going on in information theories. Still see some of those guys who were in early computing.

MSM: So you started out with systems research department? And doing ??????? simulation?

Tague: Yes, there was a program, indeed the program that when I got here there was a program that had been written by an electrical engineer under the guidance of my supervisor there, a fellow named Runyon who was interested in telephone traffic. He invented something called the sequence diagram which was just a diagram, kind of a block diagram, of the steps in call processing. In looking at these diagrams which he was putting together to understand the phone system at that time was a lot of interest up in research. They were doing PCM research and the T1 digital stuff was just coming in; I missed T0, actually, the very first micro and digital links. And they also had a system called diad which proved to be a fairly prescient runner up for toady's digital telephony. In trying to understand how the phone system worked John had put together these diagrams. He recognized he had the idea by his little marks kind of running through this diagram. I could actually simulate the office if I move them along according to these sort of timing machines. A professor from Wisconsin named Dietmeir came in for a summer and at the end of the summer he had 3000 lines of absolutely unaccommodating assembly codes that didn't work. My first assignment when I arrived in February was to work with a fellow named Jeff Gordon who was in Transmission and had some interest in the application of this, straighten it out. And Jeff had put some comments in it so the structure was a little more evident. I made the thing run and I really made my research career out of it. It turned out to be one of those really neat deals that I took it around and I simulated everything from missile traffic for the early Nike stuff to the telephone offices to the traffic at the World's Fair buildings to elevators at the Holmdel open house to factory lines down in Western Electric. It was really terrific. I got a really nice view of the company. And the program that Jeff Gordon got in one of these binds where his organization was moving south. He wanted out of his organization but they froze everybody. Meaning you have a choice. You can either quit or you can go to Holmdel. And he said he had no problem going to Holmdel, he didn't want to go with his organization. But that didn't wash. He went off to IBM carrying the program, which showed up a couple of years later as the general for the system simulator out at IBM, GPSS.

MSM: This was the forerunner of GPSS?

Tague: Yes, GPSS. At that point I was in research and by this time it was getting rather burdensome to in effect to spend all of my time running around helping people run simulations. So when GPSS came along they said use that, it's essentially the equivalent and I began the SDS and went off into what eventually became the Multics project.

MSM: What did you do in the Multics project?

Tague: I was in a couple of roles. First of all they got me involved with the documentation. Everything was done in triads. And there was a firm of Haig, Tague and McGee that were the GE, MIT and Bell Labs pieces that tried to get the documentation automated. They didn't think they could use CTSS to get this done so we were trying to use some punch paper tapes systems and other primitive stuff. I volunteered to do that because I became secretary of a triumvirate which was really ??????? started out with 3 people who were really running the project at the operational level. I became secretary to that committee which gave me a preview of what was going on and after a year or so was charging my obligations to get the documentation scheme going. I protested and got assigned to interprocess communication. I got to work with Jerry Saltzer designing that. And that brought me to about '67 where it was pretty clear to me that contradictions inherent in this 3 headed monster were not going to lead to success so I decided to get off the sinking ship before the last raft left and came over here to Whippany where Safeguard was going on.

MSM: I'm going to stop for a second here and talk a little bit more about Multics. What had attracted you to that project in the first place?

Tague: Oh, that's pretty simple. There was a, ... as I say, I got into simulation and when I got into simulation one of the things you ran up against, of course, was the deficiencies that occur in languages and so forth. And we had macro [fat] but I wrote my simulator. I did a re-write of it along about spring. I said I came in February of '60. I had the program running somewhere around March and in March I discovered there was a fatal flaw in the method of timing. There was just a basic logical flaw and I went to my boss and said I think I understand this program. I want to throw it away and re-write it. And he recoiled in horror and said don't do that. But I duplicated the deck and went home and did it anyway. And we came back and said I did it anyway. Tom and I got it running. How do you like that? He said that's terrific and then we went on from there. And then I re-wrote it from a 7094 series which was coming in the spring and I can really revise this thing and use the macros. And I got into data structures in a fairly heavy way and it became apparent to me that the real key to this program was really the data manipulations and well, things were not very well understood most days. But basically the eventless timing was something we invented and embedded in this program and those 2 things said that there was a pretty clear way to put the program together. I got that one done and set some records on the number of lines of working codes produced which is something I'm happy to brag about. But to be perfectly honest about it that was simply if you really thoroughly understand the program and are writing to a spec that's as good as that it really is pretty to set records. But it was a good deal. But that had shown me that the operating system first of all was lacking some things I needed. One of the things for example in those days, when you put your job in you put in an estimated running time with the operators but the operators thought they could tell when the program was looping. A simulator is basically a big loop and they couldn't tell when it was looping because subtle changes that would go through this thing weren't evident looking at flashing lights. They kept cutting my damned program. At some point in that era why IBM came in with a clock that was programmable so I can put on the card how much I'm willing to spend and then the rule was keep your hands off and if I get a, you know... occasionally would have a runaway which they had cut it. But it was a much better deal. And that got me involved in the operating interface with the Thesis series at that time. And there was a re-organization also where the computing systems research and those in acoustics research and those in math research and some others all kind of got blocked together under a math center Henry Pollack took over.

MSM: When was this?

Tague: This was probably around '62-'63. Somewhere around there.

MSM: Is this when computing research started?

Tague: Yes. Ed David came in. Let's see, Ed David became our Director with Crowley as head and David became executive director and Crowley became director on the Multics project which was starting at about that time. I'd gone down to an FJCC, a fellow joint in Washington in which there was a TRW system described down there where they took 3 screens, I think. It was quite elaborate for that day. It completely took over a rather sizable disk machine. It was a 650-like machine made by TRW, a brand that no longer exists, Bendix maybe, I don't know. But the thing that was intriguing was this was one of the first interactive systems ever put together. It was an interactive system to do mathematics. It essentially handled numerical analysis and algebra in a peculiar mix. And it would put up in real time it would graph equations for you and so forth. And there was a good paper given by somebody who had solved a significant mathematical problem. The problem was I think a differential equation solution and there were 3 or 4 other papers at this FJCC which was speaking to interactive use of computers. And I came back from that and I was sort of singing for my supper and gave a seminar within the research department saying we really ought to get in to this time sharing stuff. We didn't probably call it that at that time which we really ought to build our operating system to be interactive. And I was not the only one singing that by a long shot. There were a lot of people and essentially during that time why Ed David I know heard my talk. We talked a little bit about what was going on and out of that came the nucleus of the Multics project. The machine generations were changing. IBM was not doing ???????? in 7094. They came in with a 360 with a long suffering salesman who everyone felt quite sorry for. He was a very competent individual. I think he was carrying the message up to Poughkepsee repeatedly. You're not offering these guys what they want. You kept telling them to go back and sell them what we've got. And that ended up in a bidding war between GE and IBM which IBM won. I mean GE won. And I remember vividly that on the last day of acceptance of proposals a limousine from Poughkepsee raced up to the door and dropped off this proposal to the receptionist at Murray Hill. And it was the TSS system. But that was too little too late from our point of view. We'd been working with GE and they had a very good designer down there, I can't remember what his name was. He was the designer of the 635. And it just looked a lot better to us. And I'd say it didn't hurt that they had 6 bit bytes in a 36 bit word ?????? conversion from what we had was easier and of course in the event the TSS proposal was picked up by the switching people who were then down in Holmdel and who ????? the TSS out there, it eventually became an effective product for them at about '69 or thereabouts it actually began to work and at the same time GE went belly up in the computer business and Honeywell took it over and things looked good for a while. Honeywell ???????? basic structure of that project of course was kind of crazy. GE was in it to get into the computer business and get out a product. The deadlines of some financial accountability. MIT wanted to write the specifications of the ultimate operating system and we had a mixture of the 2 where we wanted researchers to participate in the MIT side of things and on the other hand we had a deadline where supposedly in 6 months or something we were supposed to have this operating system up and running on new hardware. It was just incredibly naive what set off to do. It was kind of recognized as to how much trouble we were in. Probably we were off by an order of magnitude even in our pessimistic views. It certainly was ????? I think for most of us. There were a number of people going on at that point trying to put up new software on new hardware at the same time and it took a while for people to learn that you have to do some kind of a cross compiling game. You've got to use the machine you've got. Corby wrote a good paper on Multics saying if he it to do over the first thing he would have done was move CTSS over to the 635 and go from there. That's probably a good idea.

MSM: Is this the '72 paper he did on "Multics, the First Seven Years"?

Tague: Yes. But at any rate I came out of Multics in '67. I came over here on Safeguard because I'd always felt that I should leave research and go into management. I was willing to wear a 3 piece suit and that might have been more telling of my talent than doing computing research in competition with some of the folks over at Murray Hill there. I came over to Safeguard and took kind of bath because I arrived here with a group of 8 people and by Christmas I had 70 reporting to me in 3 states and it was just an amazing circus. In retrospect a good learning experience but after 2 years of that I quit and came back to Murray Hill in the Comp Center just at the time that Multics had died. The summer of '69 one of my friends in Research Bill Baker called them all together one day and like Viet Nam he declared victory and got out of Multics.

MSM: He hadn't played any role or done any consulting at all in that decision?

Tague: No.

MSM: Was that decision really made right at the time?

Tague: I suspect so. Yes. I think it was Bill, I think it was Bill Baker's decision to make it. He'd insisted from the start that it was a research project and there was a conflict in there from the beginning. Doug McIlroy, who was my boss during that period, had said, if we're going to do a research project on operating systems I don't want to be a part of it. My condition for getting involved in this is that it'd be the operating system for Bell Labs. It'd be the successor for the ?????? chain, and that was accepted at one level. On the other hand Bill Baker was very insistent that this was a research project not a development project and he was certainly right in the way it was run. And on the other hand there were people in Comp Centers such as here in Whippany, who bought 635's [and] had military business critically dependent on it. And there were the Holmdel folks who I say should have bought into TSS and were struggling trying to get something that actually worked there out of IBM and I don't know what was behind that bifurcation but I suspect that ESS was big enough and powerful enough at that time that they could just ????? But Bill Baker I think had one fundamental misunderstanding about the computer business that he didn't really cotton to until the end of the '60's. And that was that computing for research and computing research are 2 different things. I mean the legitimate niche when I was in the Comp Center ?????? was some hapless business coming in with this Fortran deck saying what have you guys done to screw me up? My program ran yesterday and doesn't run today and would you kindly not do me any favors. And perfectly legitimate beef and one that was not responded to at all. I mean the systems research people ran the computer at that time. We found nothing that?????? knocking it down for an hour or 2 in the middle of the day to put up some new stuff or to screw around with. We'd take it down at lunch time and play biological games. Some of which were quite stimulating and interesting. But nonetheless it didn't help the production along very well. It was batch processing so it wasn't what it would be in today's terms by a long shot. You expected kind of a half day turnaround on your job which was kind of the norm. But one of the reasons that I kind of got out of this whole circus was that I was leading ??????? about how computing should be done and they didn't quite agree with the way Research was doing things. But I came back one of the things I was delighted with was that they had made the split and the computers were taken over by a new division formed under a man named Thayer whose job was to take all these disks ??????? who ever happened to get the largest computer at each location first and pull them into a coherent computing service. And that spoke to me because I thought that the right role of this outfit was for the computing research guys to do their computing research on some machines that were appropriate and dedicated to the task and that should be in Murray Hill in Production System which should integrate the research technology with production au lieu and when we ran things to schedule and kept machines up and got service to customers was the primary goal. I came back in September of '69 and at the end of '69 I was offered a job, a promotion to head a department that had a very peculiar history. The government had requested that we put together a planning department. Again I wasn't in on this, this had all gone before I left Safeguard. But I think it was kind of in response to the Brooks Bill. Are you familiar with this?

MSM: No

Tague: The Brooks Bill in Congress was a bill that established how the government should buy computers. And it was a pretty horrible bureaucracy. It's still with us to the day. And it's the reason with these government people it takes them 2 years to get the permission to buy a machine. And then they have all these lawsuits anyway at the end of it. But the whole thing established a bidding structure and made sure that there was competition and the rest of this. And as part of the pressure on the organization... now, at that time Safeguard was something like 20% of Bell Laboratories; I mean it was a big project, multi-millions being spent on it and I think we got big enough that we fell under the Brooks Bill. The Whippany Comp Center here had to buy machines to procure them under these regulations and it was all pretty hairy, and pretty meaningless. The government didn't understand that you can't go out and put bids on a computer the same way you could on a two or three eighths film pencil. Brooks was smarter than that but not smart enough to understand what the degrees of freedom were and not to understand the locking that you had with the vendor unless you buy into their software. So the result was that everything sort of had the flavor of bidding but actually came out to the sole source. So outfits like RCA and Honeywell were offering IBM compatibility packages to try to pull this off and their weakness was typically that their hardware was just not nearly reliable enough relative to IBM's, that you touch with Honeywell and GE machines were multiprocessor ?????????????. One of my bosses said it's a good thing because you need it all. Half the machine is broken all the time. So if you didn't have twice as much gear it wouldn't run. Tape units were just disastrous. But the result of this was I asked them to create a department that would review computing purchases for Bell Laboratories. In any event the way it was set up in the job I was offered was to a head a department which would review every computing purchase in Bell Laboratories with my ED Thayer as head of the computing division had a sign off as to whether you could actually purchase a computer or not. On the one hand it was an impossible charter. I mean we were even then buying computers and many were just starting to come in. But the sales were in terms of hundreds a year and the department that had 2 groups of probably less than a dozen people total. One of the groups was occupied almost entirely with just finding out what we owned and put together the first real database on what computers we had and what they were running, and the other part was doing mixed reviews

MSM: Did the result of that survey surprise you?

Tague: Not particularly. I guess it surprised some people. I mean the growth rates were quite spectacular with all these exponential curves rising up in the prediction that it would saturate and they were met. And it kept repeating itself of course with maxis and minis.

MSM: Was that first list showing mostly big systems or was the mini beginning to show up?

Tague: No the mini was showing. The PEB series was around in a large way and there were many of them around. We also at one point there a little later kept track of terminals. And that was a real surprise as people discovered that there was more than one terminal per technical staff. Typically it ended up being 2 or 3 in the end. But that was a useful thing. One of things we did is we learned to manipulate that database so when someone at the top of the house would ask a question involving computing we almost always could get at, you know, reformulate the question in such a way to shed some light on the problem they were trying to shed some light on by going into this database and pulling some data off and manipulating it a little bit and coming back with it. The real stick was this business of having to sign off on computers and if you know the culture around here that was very much a counter culture kind of act. And indeed after I got the job I was then shown this correspondence which uniformly in the computer committee at that time which would have been the people representing each BP area. They all said that this shouldn't exist. And the good news was a comment from Ed David that if it's going to have to exist then ??????? might as well run it ????????????? But Thayer, the man I worked for, was a guy with some real backbone and some good sense he agreed early on that the thing to do was to choose our targets. That we couldn't review everything. We really rubber-stamped most of it. But if he saw some foolishness going on he'd really dig in and use really as a lever to try to clean up the computing business. And we started out at that time on the outside time sharing business. The total computing budget was probably under $50M in the Labs at that time. $30M of it was going out to time sharing. Outside time sharing sources. We had 35 or 40 suppliers with absolutely no rhyme or reason. It was sort off whatever salesmen did in the offices that made them sign up. We extended and interpreted the charter to say that outside time sharing contracts would cover it. We got sign off on that and pulled them down to 2. We ended up with GE that provided very good time sharing service. Basic and so forth. Based on Honeywell machines. And that fit with a lot of Honeywell traffic we had around. And then IBM VM-based services, VM had appeared on the horizon at that time and we got I think 1 or 2 VM suppliers and cut everybody down to that and just told them if you want to do outside time sharing here's what you do and then internally in the newly formed division to provide computing services we started racing like mad to try to get a time share with a decent interactive approach to Fortran ?????? computing going in most of GE contacts than IBM contacts. GE kind of led the charge on that since they had the ????? a pretty good system, again Multics ?????????????? There was still some Multics going on, research, buy it died pretty quickly. The VM stuff, we started getting into VM I think on some CICS that was tried for a while. Third party system I forgot. But basically we started chipping away at this outside time sharing business to try to bring it inside because we were nervous about having our databases outside. There were some things you couldn't do with the databases fragmented among the suppliers. The cost was getting pretty high. We thought ???????????

MSM: Were you aware of the CMS project that was going on at the Cambridge center?

Tague: Yes.

MSM: Was that at all attractive?

Tague: It was but it came too late. By the time it came we were committed in other directions. The TSS business had really taken over. It was being effective for ESS which said there was a TSS community that was pretty large. And the GE stuff as well as the Honeywell stuff was beginning to work on ??????? so we had more ????? covered on that score. And we tried VM, we tried CMS, but the more popular system was, I'm trying to think of what it was. It was a proprietary system that was mostly interpretive and folks really liked it for interactive Fortran kind of computing???????? The NBS turned out to be satisfactory as far say the design engineering ??????? CAD/CAM ??????? by various minis ?????? But after we got the time sharing cleaned up we then went after consolidation with the Comp Centers and we bid off some budding comp centers in places like Allentown PA and made them go to remote stations to the larger centers of Holmdel and Murray Hill and whatever. And Indian Hill came into the fold. We took over that comp center as part of the division. We bounced off Columbus and Merrimac Valley for good reason. Merrimac Valley is where I can see it most clearly. That was the one place where I got into an argument with my boss because he wanted to fight on standards. And we told him we'd lose, and we fought and we lost. But they had an interesting setup. It turns out that the factory at Merrimac Valley and its attached lab had the property, had several things that came together. First of all they were beginning to feel outside competition. The Japanese and others were getting into the transmission business at that time. So they had to run a little tighter ship. The were the only place in the Bell System or in Bell Laboratories where you knew where your product was going to be produced. That factory was dedicated to transmission and the Merrimac Valley people knew where their designs were going to be produced. They were in the same building. They established a very good rapport with the factory and really started making some CAD/CAM, sort of putting the CIM kind of stuff work. But I'd go up there to talk to the guys I worked with. ?????????? downstairs now ???????? one of my customers again. ??????? The thing that fascinated me was that he justified his computers in quite a different way. He did not charge back by the job. He allocated the cost across his organization. The computing center was dedicated to his center. But it was only a center. It wasn't even a division. It was just one lab that was up there. But the way he justified it was to me absolutely the right way. Instead of talking in the number of jobs they processed every day and the number of ???????? and all this kind of stuff that the traditional comp center used he simply said before I put in the CDC machines and those that were CDC which was a different thing and he did hybrid. You know, he plugged hybrid stuff into the side of the CDC and that's pretty good service now. He said before I got these computers I would take one of my designers and they would turn out 2 designs a year. And they now turn out 10. Take a look at these economics. I can pay for that comp center 14 times over so don't give me a hard time. To me that said, hey, don't screw with this fella. We're down here counting jobs in Holmdel, 50% of which are JCL errors and we're calling it productivity. I said this is the way to do this thing so let's not screw. Well, my boss who also incidentally ran the DDS function and they were kind of out-grouped on DDS. It was pretty much a battle, although we won't get into that. But he lost, he lost ultimately gracefully and we went to Merrimac Valley. And to this day they're not part of my organization. They run their own comp center up there. They still run it with much the same flavor. We've gotten a lot smarter in the comp centers about how we allocate costs and we'll sell you dedicated and allocated machines and all kinds of stuff. That's been a big help in getting us to be more serviceable to our customers' bottom line. But after having done that part of things and kind of gotten the main comp centers under way the minis were then beginning to appear. And the affirmative thing was there were some HP based systems that had been developed by the Transmission folks. And they were measuring, on the one hand they were measuring traffic and on the other hand they were doing things like collecting alarm signals from these remote transmission towers and analyzing troubles and stuff like that, dispatching people. And I ran across a guy, again up in Merrimac Valley who happened, it was sort of accidental, a guy up there who complained that your guys are designing these systems and I have to go out and do bulk sales and the sole source purchases of HP machines. I can't go out for bids. I don't like that. And we talked a little bit and understood the problem and pointed out to him that it's kind of difficult to do otherwise. We really can't ????? around. But I was aware that my buddies in Research were working portability. We'd heard about this thing called UNIX. It actually took place over probably a year and a half but I got to the position where I said look the right answer in this area, we started calling these things Operations Support Systems or Operations Systems and there were a lot of them. So the right thing to do here is get a hold of UNIX, a portable UNIX, and I was able to go to my boss and say look, we put this stuff on UNIX. If you want me to I can fix say 3 vendors and well put UNIX up on those 3 vendors and people can now continue to develop on whatever UNIX they happen to have in their lab and when we go out for bids we can generally go out and among these 3 vendors get them to compete for the volume. The volumes weren't large. The typical problem was a program or somewhere between a dozen or 50 machines. They were typically regionalized. There weren't that many of them. Though there were a few of the smaller ones that had little PDP sitting out in the central offices and data collection peripheral roles, thousands of them. But the Labs wasn't ready for them.

MSM: When was this now?

Tague: This was probably around '73, '74. Yes. To get the timing right I got into the UNIX business. The date that's firm in my mind is in September of '73 I got permission to put together the first UNIX support group in Bell Laboratories. I put a supervisory group together and staffed that up. And at that time I was also interested in supporting MIRC. I thought I'd do MIRC for real time and UNIX for a time sharing kind of application. MIRC never got off the ground. We wasted energy on that. Though MIRC actually got embedded in some of the UNIX line systems that underlined the ESS processors. That stream did continue in a peculiar way. But what we discovered was that the real time part of the business we had in these OSS systems at that point was really handled in one of two ways. You can either write a specialized driver and do all the real tidy stuff down in the driver, or you can buy yourself a PDP8 and quaff it down and put the real time in the PDP8 and the PDP8 would then appear much like it did external in terms of its response needs. And we had to do, the other things we had to do some database activity in there. And the typical thing people did was to put a process up that would manage the database and then we added interprocess communication features. 3 of them. It seemed to be a surplus of things. But I was driven by my customers. When I went into business all of my customers knew more than my people did. So we spent the first year in documenting the product, getting an LDI to Western that made it an official product which is a submission of design information that had to be done. And my people learning to be as good as their customers were in understanding what it was we had. But we quickly got to the point where we understood what the business was and we were trying to gain control of the customers because in Columbus there were a bunch of people who were doing these things and even there they invented 3 different interprocess communication mechanisms which ??????????? smaller number. But typically they'd have it locked in the product and out in the field by the time that you raise the thing up to anybody's consciousness. We ended up just at the end putting in a lot of that stuff in UNIX to hold it together.

MSM: How did you find out about UNIX?

Tague: That was very easy. I left Multics you see in '67 and I overlapped a little bit with Thompson and Ritchie but I still knew those guys in Research and indeed part of my role in this planning job you see really became the planning department for the comp centers. So keeping in touch with Research was one of my officials chores anyway. And at that time you looked around the mini area at the end of the '70's. The typical mini computer operating system was all out like a PC DOS. The PC DOS would be sophisticated compared to many file system. Flat file system, ???????? processing and so on. And Thompson was sort of the legends in the Multics anyway.

MSM: What made him legendary?

Tague: Oh. It was very simple. Vic Vyssotsky was a very good friend for many years. And Vic made the comment, because Vic was sort of heading up the Multics effort at that time as far as his building was concerned. He said Thompson arrived on our premises with a sort of mixed story from UCLA, I mean from Berkeley, saying that we've got this guy out here who's really good. He writes terrific programs but we can't get him to write his thesis and we don't think he's going to make it. When we took him on, and as Vic said, Thompson had shuffled into his office and wrote on the blackboard saying there's sort of a problem here. Do you think it would be worthwhile solving. If you do something about that it would be terrific. Well about 2 days later he shuffled back in and said look what I've got. And it would be solved and solved very elegantly. But I say it was about that time that I departed from the Multics project and spent a couple of years over here in Safeguard, between '67 and '69. But by the time I came back to Murray Hill there were a couple of competing operating systems for minis. There were really 3 efforts that I remember. One was Sandy Fraser had done his spider thing, the forerunner of datakit. And he had some operating system stuff. It was pretty primitive but he did some multi programming things. That was really never much of a contender. But there was a crew not in Research but in a kind of an exploratory CAD/CAM department and they existed in Murray Hill was then under a fella named Charlie Rosenthal. A fella named Larry Rossel who was a very bright guy who subsequently made some contributions to UNIX put together a little operating system that ran the PDP series and looked like it could do some good stuff. And the other one was UNIX. And just talking to people it became apparent that UNIX looked like a class act and Stan Brown who I worked with at Alpac when I was in Research on Altran. He an I did some joint papers there back in the '60's. And Stan was interested in portability and was telling me good things about where we were on ?????? portability, and C indeed looked like B and C and its predecessors looked like a real good deal. I did enough time in development then to understand that it was going to very tough to wean the developers off the macro fat because as long as you could tell them that a compiler couldn't do certain things it was very difficult to get them to write in the high level language. And I would ???????? high speed routine ????? assembly. And B and C offered the promise that they could really write in the sort of semi higher level language from the start. And it was a big seller. C was no problem but the way I got interested in the business was in '62 I saw these guys starting

MSM: '72 ?

Tague: Yes, '72, I'm sorry. I can't get my decades right.

MSM: I know exactly how you feel. [laughter]

Tague: A long time ago. Yes, '72, for example, here in Whippany there were a bunch of people coming off of Safeguard who had gotten into this operations systems business. And I vividly remember the first guy I sold UNIX to. There was a fellow here at Whippany and he'd gotten a crew of pretty good programming talent off of Safeguard. They'd never written for anything but large machines. They'd never done an operating system before or a compiler or anything very sophisticated in the way of systems software. And they had a schedule that said they were going to buy a PDP1120 it probably was at that time. They're going to build an operating system. They were going to write their own language and they were going to compile an application that was going to be in the field in the spring. I came around to review this purchase. And I sat down with this fella, a fella named Jan Norton, a very nice Dutchman. And he and I were eyeball to eyeball pretty quickly because ??????? I'm not going to aprove this. And he got his dander up pretty good at that. I said look, here's the deal. I understand you guys will probably the world's most portable operating system, but what I'm going to insist you do, is you pick up UNIX and that you use it as a basis for your development because it'll get this machine running. And if you don't do that you don't have a prayer. I'll bet you money on that. So I said you can go on and do your own operating system. Of course I knew what would happen when they got this thing up. And they really realized what they were up against. UNIX would be the only way they had a prayer of getting anything done even close to the time schedule. And indeed that was. And Jan was a big enough guy that I got a very nice letter from him along about January. That deal took place in the fall. He said thanks very much. He said if my guys hadn't had the opportunity of reading Ken's admittedly uncommented code [laughter] he said that they would never have learned how to program this machine properly and never would made it without using the UNIX operating system as a base. And I repeated that process with several people and the PDP11 deck had a good reputation. It was clearly the machine they liked. The transmission people stuck with Hewlett Packard and they simply went into some volume price agreements with them and then DEC screwed up very badly which helped us out quite a bit. I can't remember the acronym for their operating system but they promised it eventually it was going to have a whole bunch of features and was going to be the world's most wonderful and be upward compatible. It was none of those. And when they de- committed from all that there was a project down in Holmdel associated with automatic intercept under a director named Townsend who had (a development) who's dependent on DEC following through on this, I guess. And when they bombed on it he really was just ????? and just screwed his schedules. And we made a deal with him that he actually funded me from September to December of '73 to get my department started. Gave me a key individual. A fella named Jerry Vogel who's right down the hall as a matter of fact who joined me as a member of that first UNIX group and put us in business. And we started delivering to him. His people eventually went to Columbus and were part of the nucleus of the operating systems at Columbus which were UNIX based and kind of made the business go. But at that point I was getting kind of tired of the planning job. I've got kind of a 3 year time constant personally. Every 3 years I change things and go to something different. So what I was doing at that time was maneuvering. It was clear that people wanted central support for UNIX. For a developer to take an uncommented batch or code from Research would normally be impossible. But you see these guys had (hooked) themselves. Because they were promising to write their own operating system from scratch. So I could point out to them look, you're going to have to support an operating system so you might as well support one that exists. And don't tell me it's going to be easier to write your own and to beat this guy who's doing his 3rd operating system and by that time it was beginning to get some momentum. So that was a seller. But I knew life would be easier if we had central support. So I went to my boss and in effect what we agreed to do was to split the planning department into 2 pieces. And I took on a department that became UNIX-MIRC development and the planning function went to calling to mind Russ Archer. And he took over all that business in carrying forward. And that really got me started. The PWB programer's workbench was an independent development under a bunch of people that at Piscataway in the BIS project. Are you familiar with this one?

MSM: Ted DeLotta and I were old swimming parents together.

Tague: Very good, okay. Well, Ted was key, Rudd Canaday who's still around was one guy. The inventor of the UNIX file system was down there and he kind of brought UNIX in. Ted was a key guy. Ivan, I said a minute ago, went out to Utah. And Dick Hague. Dick Hague was kind of the guy who became a proprietor of UNIX and he and Ted came in to work for me. They came in about '76. They brought a fella with them named Larry Weir. And a remarkable thing happened because I had some misgivings on these guys moving in.

MSM: Let's get the relationships clear. PWB had started up and then came under you?

Tague: Yes.

MSM: It started up independently?

Tague: It started up independently and it had a quite different charter you see. I was really driven by these operations systems and they needed a database plus a little real time and stuff like that. Dick's thing was simply to put a time sharing front end on this huge array of machines that BIS was committed to. But they got out on a bid per project. So they had Xerox, they had RCA, they had IBM, they had Univac. And it was driving them crazy. Not only that of course the people behind UNIX had sense enough to realize this is really what you needed to edit and compare stuff. The big payoff you see was that they put a UNIX front end down in front of something like an IBM, say ?????? They put the IBM experts to work canning all those terrible JCL sequences and getting them down to the 2 parameters that people actually had to do. They embedded all in a shell and then offered somebody a shell. And they kicked this stuff off and the source would be driven across the channel link and put on the machine to run. The body would be brought back on to UNIX. They could walk over the body on the UNIX files, keep it or throw it away as they wished and all the code control that comes with bill control. They were the guys who made the SCCS the code control apparatus go with the rest. And it was a nice compliment as you see and we had these people doing these kind of real time database sort of things and people doing time sharing system. They were going to come together. We'd each been busily modifying the ??????? to some extent to get this thing done. But I was not looking forward to this clash between my established group under Joe Maranzano and Dick Hague again, and his guy ????? and my guy Tom Rolly. And I thought that there'd be great conflict. And to my delight Weir was so good. ??? [tape fades out, end of side one] ??? We said we'll use the PWB base and put this other stuff into the PWB base; with Larry's help it'd probably be the other way around, and that was a decision I never regretted. Weir was excellent at keeping track of that system and running it in his head. Quite remarkable.

MSM: I heard somewhere there had been some conflict.

Tague: There was, let's put it this way. Weir and Research didn't always get along very well. And Dick Hague was a very prickly character. He was working for me again up until last year. He retired; he's now got a venture operation down in Clemson. And Dick had strongly held opinions which he made no bones about sliding. On the other hand he was frequently right. My arguments with Dick generally were that I really believed that there were such things as large developments and they had to be handled somewhat differently than what I would consider kind of ?????? which Dick was very good at running. And Craig Dodd in Buffalo did work in that in that mode. But he for example thought nothing of changing the system incompatibly in a way that would just wipe out stuff. And his attitude was generally, things are 2 years old they ought to be redone anyway. Well, then there's context in which that is true and probably more context than we're willing to admit, but there are context in which that isn't true and that was where many of the tensions came. But that wasn't a big problem. It was manageable. We got that going and we managed to modulize things so that people could leave some stuff out if they didn't need it. Then we'd work from a standard system base but with sort of add-ons as needed to ?????? it free with the operations systems market or PWB market. And there were very good tools that Dick and his people had produced on the PWB for managing code and doing code control and that sort of thing. Dick was not very patient for that but he appreciated; his managers needed it. We referred to them as a manager's "Linus' blanket," and there was a certain amount of fairness about it. I personally wanted to have a configuration control of some formality and perfection is rarely obtainable. If you can't tell me what it is you're delivering to the field, I'd say you're probably in deep trouble on a project of any size.

MSM: I must say my job down in Holmdel working for Charlie Stenard was to scout out software development environments for the AWIPS project. I was the person who identified RDD100 as the most promising one. Cemented that relationship between Holmdel and Ascent Logic[?] [and] did the report on it. But before that project, before we did not get the contract, one of my concerns was how are we going to interface ??????? that but we were going to have to have some source control with configuration management on line. No question, talking about 200,000 lines of code just for the platform and then a million lines of government code that was somehow going to have to be introduced.

Tague: Yeah, projects like that, you just, you know, they're simply wrong. You can't run those by the senior pants. His retort to that, if he were, here would be to point out those projects were doomed to failure. They never worked anyway. The only way they worked is you break them off into smaller projects that can be run my way. Again there's a certain amount of truth in that. But again you won't get an ESS kind of effort.

MSM: I was watching a smaller project that wasn't doing too well either.

Tague: Yes. In credit to Dick there's not many people I would find as credible in promising to bring a small project off on schedule. He was very good at moving in the requirements, cutting them down to feasibility, hiring a lean and mean team, he very much believed in the 10 to 1 ratio of programmers. He knew who the 10's were and who the 1's were. He'd end up with the 10's and he didn't care what he had to pay. And there's no question in my mind that if you run a project that way it's very effective, cost effective ???? [voice fades out] ??????

MSM: I'm going to back you up a bit. Back to Klein. You said something earlier about coming in and talking about the comp centers, and the need to separate comp centers from the research people because computing in research and computing research are 2 different things. You can't have people tearing down the system over lunch. It seems to me one of the conclusions that we'd follow up on that is you set up the comp center and you take the machines you put in something actually possible. And you say look for computing in research that's the system. But we have a stake in computing research and therefore we ought to let these computing research people have a machine from which they can work. But the big story is that they couldn't get hold of a machine. But they lost their CTSS and their Multics. And here they were in 1969 sitting there without a machine that they named they really could play with. Had you recommended that they get a machine or was there anybody speaking for them?

Tague: No let me tell you the timing on that. When I arrived in '69, Research was really in a blue funk. They'd really been kind of ripped up. And there were a few last folks still working with a Multics that was up on the 5th floor being run as a Multics a few hours a day or something like that. Multics still wasn't working much. ????????? There was a last crew still on the shift. All of whom were no longer there within a couple of years. Joe died rather suddenly tragically, Peter went off to Stanford Research Institute and a few others have dispersed. And the computing research people were asked to divide themselves into 2 parts. When I came over to take the planning job I had 2 directors. Sam Morgan who was a director of computing research. He had a co-director named George Baldwin who had the Murray Hill or Whippany comp center and the Murray Hill comp center piece of this ???????? kind of split off in some way and Sam would manage the transition. And there were a number of difficult choices for people in Research. Because what they're all trying to do of course is they wanted the best of both worlds. They still wanted to influence the production computing but they wanted to do research. They weren't permitted to have that choice. And there were some fairly bitter personal conflicts that got in there. I was working for Charlie Roberts who was the department head when I came back. He was a physicist who co-opted in the comp center. And he was working very hard to make Fortran run in the G codes. And there was one other researchers, a fella named Sterling who had a competing thing called Guts. And Joel was an exceedingly and competent programmer who had already built things that mind you are rather fragile and it took him to keep them going. It didn't seem to have much appreciation of the fact that you couldn't build things that way, that the world just wasn't going to be that regular. He always had logic on his side but logic isn't the winning rule in most people's lives. I got caught between the 2. They're both good friends of mine and actually they're both people who I had known slightly but became friends with when I came back to Murray Hill. I was trying to be at some merger of best worlds here, but that eventually... well, Charlie always had the right idea. He knew he had to have G codes support. He couldn't afford to tinker (with) an operating system and worry that you hadn't done this or there was a whole bunch of custom code and datanet 355 front end which was at least at least a program and Charlie was trying to swim with GE or Honeywell's plans at that time to something ????????? He had continual problems and couldn't support it. And Joel stayed with Research and eventually left the company and basically came over here and ???????? for a while. It was sort of a difficult time and Haming was around at that time and Haming at that time was a department head without a department. He was sort of a ?????????? I was finding it very refreshing, you know finding and talking to other people and some of them would use other adjectives. But the thing I liked about Dick was that he'd sit you down, particularly in my younger years, he'd sit you down and kind of pull you up from the day to day hassle. Particularly when I was here on Safeguard. I was very unhappy and feeling very incompetent as I was wrestling with all these problems and not doing very well at it. He'd take me to lunch and kind of pull me back from all this and get me thinking about what the real problems were in a very useful role and research and take these people and tell them to quit writing papers, go out and write a book which is probably the right answer for anybody but for everybody. But for some people it's a good thing. One of his other quotes I gathered that I always liked is that the problem with computing is that most scientists stand on one anothers' shoulders and computing stand on each other's toes. And he had a sense I think of what computing science as a science ought to be. He wasn't always right about it. He's not one who ranks very high in clairvoyance as to where the business is going in certain ways. But he had a very keen sense I think of what people could do, what they should be doing and how research was going to be different from development and some of those issues. And he was going in to Ed David who was executive director at that time. I remember one of the quotes was, he said, Ed if you buy those guys a machine I'm going to lie down on your floor and scream. ?????????? everybody had just done that. There was a proposal in for PDP10. That was one that again I was in a position at that time, I was going to have to review that PDP10. And I went up talking to the research people, Sam Morgan, as to whether this was a good idea to get this thing or not. Let me back up a little bit. Henry said don't buy a machine until they get their act together and tell you what they're going to do. I think that was a good input. And David was certainly his own man. I don't know how much he was influenced by Hamming, but they go back a long ways together and he paid some attention to Dick. But by and large he did not let them get a machine. And it was partly made easy for him because there wasn't much with the demise of Multics. There were a lot of knives that had been sharpened for that over the years as it kept missing its schedules and screwed up development and so forth. So I think Bill Baker realized he was not in a very good position to go looking for a few mil to buy a machine for these guys if they didn't have a story just what they were going to do with it. And that forced his famous statement that they're going down and playing with left over PDP7s and stuff from the lab to get their thing done.

MSM: If you asked Ken, "What are you going to do with this?" he'd say, "I'm going to build an operating system." Now that would not have been an acceptable answer?

Tague: That might have been an acceptable answer but probably not. I would guess not. And if that sounded too much like you guys just want to do Multics again and this was not the time to do Multics again. One of the observations being made was if Multics was influencing various vendors in various ways and there were some case to be made that you'd see some of these things maybe not on the right path. But I think there was pretty good recognition that the computing business had matured that we're building your own operating system for a large machine which was probably not possible. And on the other hand I think Ken recognized was, about minis, it was not only possible it was needed. And jumped into that window. But you see they were going for kind of a mini. But that PDP10 was not really a mini. The deck couldn't think of it that way. They thought of it as their maxi entry.

MSM: Yes. If I remember it correctly what I've read, it is, "Can we have PDP-7 or a Sigma 7?" We're not talking minicomputers.

Tague: So as I say during that era I certainly wasn't playing much of a role around that time. As I say David I think was just digging in and shortly before David left I think he was feeling the penalties of having of having Multics come in proper and again I don't know any other little stories. But I think it's not coincidentally right now that he ?????? science advisor I think ??????? career ??????. He probably was taking a lack of from this thing. He was very bitter about GE I know. GE kind of backed away from this thing and there was some truth to that. On the one hand there were some other people rather early in the project somebody observing the ?????? that it looks to me like you can do jet engines, nuclear reactors, and computers. Maybe 2 out of the 3 but not all 3.

MSM: Yes.

Tague: That was confirmed. We might have seen that coming.

MSM: Did Dick Hamming play a role in shaping the style of computing research? Is it a very theoretical group, or...?

Tague: Not really. Not really. Let's put it this way. Dick had a blind spot I think on computing and that is I really do believe and still believe that there's a sort of experimental computer and a guy like Thompson who's a typical practitioner in experimental research and computing. And there was a very narrow myth that I think I helped with where Sam Morgan was getting pressures at this time, '69-'70 to sort of turn the computing research department into an entirely computer complexity blah blah blah automota... you know, that kind of stuff. That was computing research. This other stuff was something else. And I spent a lot of time with Morgan pointing out to him that I thought it'd be a terrible mistake not to support this other strain. It may not publish the same kind of papers and doesn't look much like mathematics but it's terribly important and it's good stuff. We need it. We need it very badly. The other place where I personally think I played some role was in the time later on where it looked they were going to get a PDP10. This was about '72-'73. The issue was should they get a PDP10 or should they get a more than one smaller machine. And the machine they were looking at in that context was the first 32 bit mini: the south Jersey outfit; they later became ---

MSM: Oh, I know. Perkin.

Tague: Yeah, Perkin-Elmer took them over and whatever predecessor company was ????????

MSM: They're now, oh I forget. My wife is Princeton's technology transfer manager. And it was that company in south Jersey that took over from Perkin-Elmer and picked up the ????????????? machine. It's a household word for a while.

Tague: Yeah. In any case I intervened as accurately as I could on that. It was the research management saying,. and Ritchie and Thompson himself saying look I think they'll do more for the company if you get a lot of little machines in order to work them together. Rather than one big machine. If you do one big machine then put Unix on another machine. So ho hum so what. And, you know, DEC may have a future in the big machine business but that's pretty iffy. And it doesn't look en route too much. Whereas if you can learn to work a file system with us, clusters of machines and so forth that will be a good deal. It was somewhere in that era that I wrote up a little talk that I gave to Research entitled something like "The Cloudy Crystal Ball" but what I was saying I had this vision we ought to be able to take Unix as an operating system but as a company we can support this as an internal standard operating system along with C in an environment. And then we can then front end a large external agency and commercial agency in this. With the idea that people would sort of see the machine and use a common front. It was not well received by Research.

MSM: Partly PWB.

Tague: Yes. It was a PWB kind of proposal and it predated the PWB I think by a year or so. My story is they may not have appreciated it but it all came true. That really is pretty much the way the business has gone.

MSM: What was their objection to it?

Tague: Oh, just that they felt the right thing to do was to put it all together on one machine. They had a pretty clear picture of what the problems were of making a lot of little ones act like one big one and they didn't think this was very workable. But you see I was kind of coming at it from the developer's point of view. I knew what developers put up with. And there was a lot less elegant than what Research was used to and would it concern a decent support environment. And in that context the idea that you, that you--- and I also understood about you know what a project like ESS needs to make a bill. It isn't going to get done on a PDP10. They're going to be out there looking for the biggest machine they can fine with more bytes than you can possibly imagine and that isn't going to stop. It's driven that way. And you can say what you wish about there being a better way to do this or what have you. But, let's not kid ourselves. This kind of combination looked pretty good. Some of the laboratory things brought in with Unix. There's another tune that we were singing about that time is hard storms were in the system where you'd have a PDP8 in the lab with Unix behind it another elegant thing where you can download C programs. That was sort of a semi-Unix environment where the PDP8 you can sort of program pretty much as though you had full Unix. They would come back to the disk on the big machine across the line and make certain calls that didn't exist in the little machine with all the real timing stuff that was done out there. He had some rather ???? things to do. In the context of MIRC and all that I was trying to get some support for that but there was never a big enough market or enough bucks. I couldn't find a way to get funded.

MSM: Did you decide at a certain point then that it was time to take over the latest version of Unix and standardize it?

Tague: Yes. As I say in '73 it was apparent that we needed the support and the right thing to do was to go up to Research and tell Ritchie. And I might add that was a really nice interface where he worked with Dennis and Ken. They were quite good about telling me when they had things wrapped up, when it was time to go up and carry one away again. And we synchronized reasonably well in that and my people took care of the dog work of putting together the design information files and things that Western required in order to capture the configuration and to do configuration control. And graduated off some internal gurus that were competent at fixing the system and modifying the system as need be. And you could talked with our customers on a basis ???? and just containing the story of the next stage. The next major milestone by '76 as I say I've got to have the whole thing together here in terms of Unix support going and Unix internally was pretty much a sole product. In September of '78 Jack Scanlon was putting together the initial computing business center. They picked up, I guess there were 5 of us. I was brought in for Unix, Lee Thomas was brought in for the Mackie micro-processor chip, Nick Martalotto was brought in for some of the software support tools for Jay and Dick Haddon, database--- something like that. Tom Arnold had the... I believe there was another whole hardware center that did the 3B development. The 3B was going to kind of machine based and that started the real development and we got very quickly a lot more accepting with some of the Columbus fixings and tried to put together a single Unix that would sell very easily across the board in those places. The business in trying to get 3B hardware in shape to support it and--- one stranger I might mention that was of interest. During the '70's I had been telling other vendors that they ought to go get a license for C and put C on their machines. They were all eager to try to port Unix and I was sort of discouraging that. I wasn't sure that they would be able to do it and do it right. There was some feeling that they were going to port Unix to get it to come out right. It was probably going to be necessary that we do it ourselves. That was probably a mistake in retrospect. And I was saved by Research and ????????? down in Product License department and went out and licensed Unix. And I was very clear with Sam Morgan at that time that I want no part of this. My nightmare was, you know, bank one in Ohio with this guy from ????????? Miller who sits on their board and the AT&T board picking up Unix and putting something important to their bank on it, and my getting called out of bed at 2:00 in the morning to fix the thing. So I told Sam, you want to go into this business, that's terrific. But you guys support it. My support is fully occupied by my internal customers and I'm not going to answer the phone for these people outside. If you do that you can set up your own business. I have no regrets about the position I took. I am very glad that they went ahead and put it out because in effect it worked out just right. The people who picked it up were the Rand Corporations and the universities, the banks didn't touch it with a 10 foot pole. That was all an unnecessary concern on my part and there was tremendous payoff for all of us involved on getting this. I'm very glad they didn't pay any attention to me and my suggestion and licensed Unix. And I got religion on licensing Unix by the second half of the '70's because by the time we got there we came up to parent the deal for the systems picture. It was the right thing. But the problem I ran into was it was a real stone wall was that the computing business was being driven by by the western iron mongers and the idea was that this one early on that I finally had something to do there was that we thought we could build better iron than the next guy because we understood Unix in terms we could do it. Well it took me about a year of working in that problem to come to the conclusion that it was only a couple of things that made Unix run better, a fast process switch and a good handle on your memory pointers, a few things like this. Almost all of which really were coming along in the hardware designers from every vendor anyway. It was no big deal.

MSM: I was talking to Joe Condon and was surprised to learn from him that there had been in the Steve Johnson business of trying to build a C machine. Is this what you're referring to?

Tague: Yes. The idea was well, Steve Johnson had the C compiler so a C machine was one angle on it. But the other more generally was just Unix. The C machine was all very nice but they really wanted to have the hottest Unix in the marketplace out there.

MSM: So this would be a Unix machine?

Tague: Yes. The 3B should sell itself because it would be the hottest Unix box around was the idea behind it. And the hope was that if we can get the hottest Unix box around by building into the 3B hardware stuff that made Unix run better. Well, as I say, about a year I was trying to do that. After a year I became a proponent of it and it was probably the start of my departure from the DSG business in there. I never really reconciled that with my bosses and so indeed I made a serious personal mistake in not recognizing for almost a year that Scanlon really didn't have the same picture in mind as I did which I should have recognized. But I saw building of the OSS niche business as the place we could sell 3Bs and the rest. Incidentally if you look where our market is why that and the government is where it is at the moment.

MSM: Yes, I haven't seen a lot 3Bs outside the Labs.

Tague: They were busily ??????????? Cobol up on Unix and other chimeras and I understood the need to have Cobol there but I didn't think we'd ever get anybody to use the thing. I don't know how that one's come out in the marketplace. But I'd be surprised if there's very much Cobol code running on Unix anywhere in the world. But the business at time as I say was to sell iron and the management view of things as it was and perhaps still is, I've been out of that for, I left I think in '83, and was really out of the planning of it by '82, but still Unix was a vehicle for selling hardware and that you couldn't be in the computing business without a hardware base and there's no ?????? Nobody could find a software company that didn't want $50M a year. And AT&T's thinking $50M just isn't enough to pay any attention to.

MSM: Anyone see the micros coming?

Tague: Yes. And not to my knowledge anybody who saw how quickly and how pervasive they'd be. Lee Thomas who was a fellow I think with some vision was a great one for extrapolating the language of chips down and what you can do with those chips. And he was pretty accurate as to what was going to be achievable. Like everyone in the business he was probably off by a fact or two in how long he thought it would take. Except ?????? I suspect the politics in the game are you ???????? you insist everything is winning and say that you're going to be able to do this in the next year and you know there's going to be some second order pops up that's going to make it difficult to do that. You deal with that when it comes. But they go around that chain and they by and large deliver. That's how you just order later. The later we always because every time you push the technology down some term of the equation would surface and to deal with it when it was ?????????????????? There's been a lot of debate; there still is. I've always seen the business as having 3 layers. There's always been a top and middle and a small. And those have changed their definition over the years but from about the end of the '60s on I can always find those 3 layers and they're defined not just by machine size but the approach to the marketing machine was bundled is how it is. And it ranges from the large end which is this thing when you buy a machine we put people on your premises. It's all a package. The unbundling of course has attacked that a little bit but it still stems from that tradition. It's very much seen.

MSM: It's like selling telephones.

Tague: Yes. But you know that these guys become part of your team. These IBM guys, they work for me. And they're in my offices and they come down and you can't tell them from my people. And the minis coming off the low end came out of this. You know, buy and put your lab machine and your control apparatus together. So the support there was pretty much here's the hardware and do with it what you will. As they work in the operating systems it never got the elaborate structures there until the business was well matured and there is almost a continuum at this point between the high end minis and the low end maxis as to the way they're sold. But then the micros came along and it's the same thing. ?????????????? But it went much more rapidly then as people realized that what I really want for this marketplace is a turnkey package. And that says that's really a quite different business at this point. It's the mini business where I still see the kind of boards being delivered. You know it comes in Unix these days of course. But it's not all that different I guess in some sense in taking delivery on a PDP in the late '60s.

MSM: Yes, the contrast that we seem to be getting at it does strike me strange. You find that the high and the low now in the middle that you expect the owner or user of the machine to know about the machine. You buy a big system. I don't want to know about it. I just want to use it. And a lot of the micro business, development of software in the micro business, has been to free to use it but we need to know it. Whereas minis there has always been an assumption that people who buy these things are well to learn how to use them.

Tague: They're knowledgeable. The mini is the VAR business, is one way to look at it, the VAR business or value- added reseller. The guys bring these things in and the people who buy them put stuff around them and they turn them over to somebody who may view as a turnkey system.

MSM: This is what you were doing with OSS?

Tague: Yes, the operations systems were turnkey systems and the craft as we called it would sit at these things and they would well you started out knowing that much about computing. Of course pretty soon you'd walk into the operating company and you'd see there's acres and acres of minis. Practically guys on roller skates skating from console to console trying to find what was up and down.

MSM: You've been with the company a long time. When did Bell Labs realize that programming was going to become a major activity and indeed a problematic activity?

Tague: The 60's, I think. ESS did it. The history of the ESS project which started before I got here. I arrived in '60. But I got an early view because I went to work in Systems Research in February and Tom asked me to go over here to Whippany where the switching people were at that time on a 3 way bounce Whippany to Holmdel to Indian Hill was there oddessey. But they were over here at that time in the Morris trial, which was this first electronic switch was put in Morris Illinois that used all kinds of funny technology ?????.

MSM: Oh yes.

Tague: Stuff like that. And the flying fox store. An end marked network that broke down neon niods to make switching paths and stuff like that. He sent me over here to get out of the ivory tower and learn what switching was all about and also to look into the computing business because we were clearly heading in the direction of computing research. And this was a big software project. And that project in 1960 was in a very interesting position. The guy who started it had started it with the idea of taking the number 5 crossbar switch which was an electro-mechanical switch and turning the translation memory into a Williams tool okay. And the translation memory on that switch, I think this is the one, when you look at it there's a bunch of big iron yokes and they'd go down in the rack. And you take a wire up here and you run it in and out of these yokes. When that line is pulsed, an electromagnetic field--- that yoke, it does things like changing line numbers into calling numbers and stuff like this. All with a bunch of relays and things. But his idea was I could actually just store the bits that represented these numbers and to look them up and find a spot to store. So the idea was I'd take a number 5 switch. By the time I'd arrived the schedules had been missed, the project was growing ????????? but Morris actually had been put together. And if you asked what the Morris trial did for us since there wasn't a single bit of the product in that machine that ever made the field that's the final ESS number 1. What it really did was that project went through transition. This was in the last half of the '50s. From this idea of putting a Williams tube on a number 5 crossbar to a centrally programmed controlled machine. And somebody recognized that was what they were doing at that time. And I don't know who they were. Er, ... Keister, Ritchie and Washburn. Ritchie's father was the Ritchie involved. He wrote a book at that time which was the first hardware digital design bible, and all those 3 guys were here at Whippany handling the ESS project. They had a big training program going that was training people in the logical designers. There was for example Erna Hoover who I shared an office with and retired recently as a department head and whose husband was Charlie Hoover. He was an E.D. who retired here recently ???????? Yale. Erna had a degree in Philosophy from Welleselly. And she was busily teaching and learning boolean algebra in this other context. And indeed there are a whole bunch of philosophers in this office under Bill Keister who was in Systems Engineering ????????? they worked with. They're a delightful bunch of folks to work with. Since I've always been an amateur philosopher in science I think I'm a minor in that along the way. ???????? So these people were getting hardware training. Of course that gradually moved along to software training and the ESS people were the first people to miss their schedules and cost estimates by orders of magnitude. A dubious honor but pretty clear. But if you look at the Morris trials what it did, what they really had to do was for the first time to get a requirements description of what a switching office did in one place. And they discovered remarkable things. I was over here sort of on the fringe of this business. One of the papers I'm kind of proud of was at that time I said what you guys should do is buy a commercial computer and hook it up to a switching machine so that you can download the switching machine and drive it. You have to put a big memory on this thing. I don't care if you can't afford much memory when you get into the field. You need the memory for development. And of course I had some inkling that memory was going to get cheaper along the way. I had no idea how fast and how quick but we spend an awful lot of time honing code that fit into something that didn't need to be done. But the other thing was trying to get these people to understand and to get me to understand what the economics of the phone business were. One of the numbers I remember was they discovered they had 115 different kinds of trunks and signaling systems. And the word at that time was that's no problem. We could do it all in a program. 115 trunks. We'll just program them and even them up. Now noticed that we were talking of very complicated real time programming protocols and the context was a single CTU duplexed. Doing all this in real time all by its lonesome. The people I worked with, a very good engineer there, had invented a thing called the signal processor which was the first idea of an outboard peripheral that handled the real timing stuff. One of the key timing things of that first ESS was when your phone rings and you pick it up you've got to turn around very quickly something that shuts of ringing. Otherwise you're going to get that in your ear and you aren't going to be happy and it'll probably burn out the receiver on the handset as well. So one of the key timing loops was a loop that's spent all of it's time just looking to see if somebody had come of hook and get down and clamp that ringing tone ??????? [tape becomes unclear; sound of banging heard] ?????????????? Mike ??????? had invented this SB. So I put this old outboard in this little computer. Computers were getting cheaper, that sort of thing. The single processor finally came in. It took 8 years I think from the time, from 1960 when that was being proposed. But we had an upstairs and downstairs at that time here in Whippany. Downstairs were the Systems Engineers which is the group I was with. Upstairs were the developers who had done the Morris trial. The upstairs developers were used to programming bit by bit using bit oriented machines that worked. They knew how to use every bit. And word orientation, you know word organized machines were coming at them. They were existing vitally. "I can't do efficient programs with words. You waste bits." How many times had we gone around that kind of story in this business? It's just frightening to see.

MSM: Well, it was the time when throwing away bytes must have just seem too wasteful.

Tague: The bit cost at time was something like over a dollar and the idea that it was, we knew already it had to get down to around a penny before the stuff would really work and the idea to get down to tenths of hundreds of a cent was just science fiction. My favorite quote is in ?????? he said, I am always too optimistic in what I think I can get done in a year and much too pessimistic in what I think can be done in ten. That's something that I have to keep reminding myself. But during that thing we started training programmers. There were programming courses coming along, configuration control of a sort was invented with ESS, one of the first data dictionaries was embedded with ESS. It was to keep track of symbols on ESS. These would conflict and these huge hundreds of programmers all putting this stuff together, make and build techniques were developed in that context, and one of the unfortunate things is that resesarch never really made contact with these people. I don't know how many times that I would go out to Indian Hill or down to Holmdel or wherever they were at the time. We'd sit in on a research review. Frequent requests ??????? and it would go like this time and time again. The research guys would be there telling them how to write programs in the context of cottage industry. These other guys knew they had a factory going and it never came together. The sad part was that unfortunately each side kind of dismissed the other. And there were some things that they badly needed. Research was absolutely right about the necessity of getting some kind of notion of an operating system in higher level languages into the game. These folks just don't understand. One of the things they understood very early was that something like 90% of the programming of the ESS machines is for maintenance. In those days this mortal machine ??????????????? It was a pretty remarkable concept and it still is. People out there would change the operating system; never take the machine down. Try that on your IBM machine. There's a lot of very clever stuff that goes on that these people understand and if you know you have to do that you get very cautious about being too clever in things like moving things around in memory and dynamic memory management. They depended on sort of knowing where things were locked in core so they could do this step using their two processors where the old processors running the old operating system this one kind of starts running the new one and they slowly do this interchange. Lots of good stuff. One of the first research contributions that really took was Joe ????????? multi-dimensional analysis. The way it was used was ESS had invented a card in those days. They went around and every type of board they had they took multiple copies of that board and they took a copy of that board and put switches in. They could put hard zero one faults everywhere the made any sense to do so. They plugged the board, they'd flip a switch and they'd run their diagnostic programs and record the symptoms. And they'd build a big dictionary. The idea was to get it down to a board replacement. The craft simply when something went wrong he'd sit at this console and the console would come back and say we'd run this test if this happens, punch this button and then you go through a whole catechism and ?????? would say ???????????? And they pretty much did it. But Joe Cruscle went out there with his multi- dimensional analysis. He took all these troubles and tests and in effect was able to tell them something about which test they needn't bother to run because it wasn't doing any isolation for them, what dimensions they needed injected. But it took years to get the idea of operating system and languages in out there. They were very good in the tool area that as they recognized pretty quickly they ought to get on a commercial machine, an interactive commercial machine. They went on TSS and put all their support software. Those guys were very sophisticated. But there was real resistance on those people who did this real time programming on the system and insisting they couldn't stand having a compiler around and they were right. What you needed was this model that said you write stuff at higher level languages, you measure where the body is buried on the real time loops and then you code those that you have to in whatever assembly level [language] is appropriate. But that really didn't get broken in until C. With C they finally realized and plus the economics in this stuff. That was the other thing that made it tough. You knew a compiler was not going to be efficient ????????? code and they couldn't afford the memory. It was a valid excuse through much of the '60s. But it was not excused by the end of the '60s. Took another 5 years or so before they got religion. But that was the first one. BIS in the '70s was another one. Safeguard at the end of the '60s was another one. Safeguard profited tremendously from ESS. I was on Safeguard the year we picked up their macro assembly language. It saved my bacon. My first responsibility was a compiler that was going to be an extension of Fortran. It had real time, complex arithmetic and every other thing and Univac was going to build it. It's very embarrassing for me to say but it took me a year to kill that thing. I should have been faster. And there was another project that got started off. They were building this 10 processor machine which was a pretty hot machine in its time and only transistorized mill spec, all kinds of stuff, radiation hardened, and the only peripheral gear they had on it was a model 33 teletype and that was what they were going to do to debug the machine. That was one contribution I made. I was at that time in the language area and some guys ??????? as a matter of fact built a GE time sharing system on a GE engine here. We finally got them around to an MBS base set of tools on a standard IBM ??????? that really started making the thing go. We could pick up this stuff from ESS ???????? code control gave us language configuration control. The language PiDense, Program Identification. Unique identifiers in this program so you keep track of what it was. An elaborate scheme of course for keeping track of vintages and programs and what had to come together to do the build. So that continued and one of the things in both Safeguard and In BIS and almost every large BIS project I claim you can see the same phenomenon that occurred on ESS. You take on one of these big projects. First of all ?????????? You don't think you're going to build a prototype. Then you said you were calling it by a different name but you will. But what typically happens in the building of the prototype what you're really doing if you look back at it in retrospect is you're putting together a programmable requirement of the job to be done. And you're educating people on both the application in the computing end to understand enough about each other's business that you start talking sensibly about where you can understand what is feasible and what's possible and negotiate the right compromise. Typically the application side coming at you thinking computers are magic and if they get empowered insisting the magic be done. And, you know, it of course always results in disaster. And the computing people are trying to communicate what is truly feasible on the one hand but also understanding that when these guys tell you that this interface won't work for my clerks to pay attention to that. Those clerks are not the same as you guys at the terminal and have to get those things done. We've been around that wheel several times and I sort of despair that there's a better way to do it. But I don't think our company is unique. I hear less in detail about what goes on in other large corporations. But I watch enough large disasters going on. The airlines reservations system have their stories. It came out during the late '60s early '70s as they kind of got their act together.

MSM: The major book I'm working on is the origin of the software crisis as it emerged in the '60s and how the industry got into that situation.

Tague: ESS is an interesting study because it's pretty well documented. If you go through the BSTJ and read about the Morris trial and then there's probably a half a dozen issues that were just devoted entirely to ESS at various epics. And if you read those ---

Ken Thompson

Wednesday, September 6th 1989

MSM: Is it six? Is it six? Pass says seven. Okay, I 'll be here tomorrow. Okay. I was going by the pass.

MSM: Various accounts I've read of UNIX, Ritchie's retrospective on it, and even an interview you did with some people for a video back in 1981, talk about the system as being, or UNIX as being, sort of culling all the best ideas in operating systems that emerged during the '60's. What were those ideas and how did you first encounter them, how did you encounter them as ideas?

Thompson: My background for obtaining these ideas was uh, there was a I went to the school at Berkeley and there was a thing called Project Genie at Berkeley. As project Genie it was never very heavily advertised. But, what they is brought a SDS930 through an ARPA grant and cannibalized it, put paging in it and it became what SDS later marketed as SDS940,which was a time sharing system. In it there were some Mel Butler, Lampson, Peter Deutch and Mel Hurdle were there. They were the chief people there, who went on to do other things. But, they essentially made a cleaned up version of MIT's operating system. Time sharing system.

MSM: The CTSS?

Thompson: Actually, no PB1060. (not clear) It's a TDA. It's a three- letter acronym. IDN or ISN or I something. I can't remember. Anyway they had a lot of fun ideas in there and there and a nice clean file system. Then when I went to Bell Laboratories, I worked on CTSS, I used CTSS per say. I used CTSS and did some, a lot of programming on CTSS and I worked on MULTICS.

MSM: What did you promote?

Thompson: We were involved with the file system, which never really came to exist, because um the addressing is built into the paging system--the whole process is seen by paging--and what we did was try to develop read and write calls that were sequential calls that turned around and ended just reading sequentially out of pages, it's sort of upside down notion. And the um there were problems with the segments, things called files, and that they were fairly short and maximum size. Through the eighteen words of addressing, max. So, if you want big files you had to concatenate segments and walk across to the two-dimensional address--one dimension being the segment number and the other dimension being the word within the segment. Anyway, it was to try to clean up some of those problems with paging. But, it... so anyway... That's were most of the ideas came from was the combination of those three systems. The 940 system... what became the 940 system. CTSS and Multics, you know a couple of new ideas.

MSM: Which ones were they?

Thompson: Um Pipes. There were a lot of things that were talked about but weren't really done. Like treating files and devices the same, you know having the same read calls. Typically during those days there were special calls for the terminal and then the file system itself. Those calls weren't the same. Confusing them and redirecting IO was just not done in those days. So, that was... I think everyone sort of viewed that as a clean concept and the right thing to do but for some reason it just wasn't done. It was just the right time to actually install the feedback; and, uh, the things we stole: We stole a shell out of a MULTICS, the concept of a shell. We stole per process execution. You know create a process--execute the command. From a combination of the two, although, neither of them really did it, MULTICS wanted to do it. But, it was so expensive creating a process that it ended up creating a few processes and then using them and putting them back on the shelf, then picking them up and reinitializing them. So, they never really created a process for command because it was just too expensive. The ION direction and the stuff like that and later in fact streams came from um the IO switch, that we worked on in MULTICS. Having everything work the same and just directing, you know, changing what it really pointed to. Hard to think. I remember at the time that there was a discussion on whether we should go to six or eight bytes. Seems like silly discussion now. Wasting all that space, you know, going to eight bit bytes when there was only six bits of information there. (Laughing) It doesn't seem like a grave decision, but it really was. In higher level language which was still (not clear), we had always wanted to do that. The original wasn't, was written in a simple language. But,

MSM: Go you wanted to go to high level from the star t?

Thompson: Right from the start. Knew we had to.

MSM: Was that MULTICS influence?

Thompson: That was MULTICS influence. And just the complexity of maintaining the thing, we just knew that, you can't maintain something. Even write it, get it going. But, it will evolve.

MSM: Did the choice seem obvious to you? As to which high-level language to use?

Thompson: No. Not at all. Because none was really good. PL/1 was too high for us. Which was what MULTICS did. Or even the simpler versions of PL/1that we used in MULTICS. Like there was a thing called EPL. The 360 was around, although it was IBM- proprietary. After UNIX was up, or, simultaneous with UNIX coming out, BCPL was just emerging and that was a clear winner with both of us. Both of us were really taken by the language and did a lot of work with it.

MSM: How did you come up with it, it's an English language wasn't it?

Thompson: Ah yes, but the guy who did, Martin Richards, actually developed it at MIT. It was available in a very informal way, on CTSS and we pulled it off of CTSS and got a version running on GECOS here and did system programming there. It was too big a language to run on the UNIX machines that were 4K machines. That's when B was developed. Which was ...

MSM: Did you develop B?

Thompson: I did B.

MSM: As a subset of BCPL

Thompson: It wasn't a subset. It was almost exactly the same. It was a interpreter instead of a compiler. It had two passes. One went into intermediate language and which one was the interpreter of the intermediate language. Dennis wrote a compiler for B, that worked out of the intermediate language. It was very portable and in less than a day you could get very versatile (not clear). Typically the interpreter was a set macros for your interpreter, they were very field orientated and you just define these macros with these fields and then write a little interpreter that would switch the set routines, and you had to write about twenty three- line routines, and it would run. And it was very small, very clean. It was the same language as BCPL, it looked completely different, syntactically it was, you know, a redo. The semantics was exactly the same as BCPL. And in fact the syntax of it was, if you looked at, you didn't look too close, you would say it was C. Because in fact it was C, without types. There's no word like interchar or struct or anything like that. The word for... There was a word for extern, which means to declare an external thing. There was a word auto, which declared an auto thing. So, it would be like auto XYZ, instead int XYZ and it meant "word". Which was the only time.

MSM: So it operated really at the machine level.

Thompson: Yeah. It was used to a very small extent. It was written in its own language. That's why it's so portable. Because you just pull it through and it's up real quickly. Um... But, the interpreters, the interpreter for the 11 was having some trouble. It wasn't a word machine, and this thing had a word notion, and so on almost every operator you had shift left and shift right, shift left and shift right. It was just not a good match at all and part of this is we didn't have a good--on top of the interpreter problem-, it wasn't even a good interpreter on the 11, because of the mismatch of the machine and that we wanted something better as the systems language is what prompted Dennis to slowly permute it into C.

MSM: So C essentially contains B?

Thompson: Well, some of the anachronisms of C, that are now gone, or, at least are not or are unpublished to the point that no one knows they're there, are B anachronisms. Like auto. There's a word called auto. No one knows, I think it's actually ANSI finally. The word oriented parts of C, as C emerged were in fact the basic routines. And in fact one of the major, at least in my view (not clear) with C is that a arrays to are promoted to the address of the base of the array every time you touch them and that's one of the fundamental things of the NBCPL. That there's no such thing as an array but there's these things called vectors. A vector is a list of words and declaration of a vector is a word containing a pointer to a list of words. If you say auto x of 5, there's no such thing as x of five, you know, that's a type, and there is no types in this language. So, what it is, it's a single word called x and then five words that are unnamed and a pointer, initialization of a pointer into x to the base of the five words. To keep that semantics and develop a notion of an array, which we want to promote. The name of an array into the address to do it at run time. Anyway,

MSM: It always seems to be one of the neat features. The way you could step through an array with arithmetic.

Thompson: Oh yeah, yeah.

MSM: You prompted a question when you talked about portability of B and of course one makes a great deal of the portability of UNIX itself and it's a portability, if I understand you correctly, based on self-reference, or almost self-modification, which was the theme you were pursuing in your Turing Award talk, largely to suggest the dangers of doing it. Is that a theme of continuing interest to you?

Thompson: Have I got it right to start with? I guess it's wrapped up. Von Neumann machines in the real sense. There's a lot of power in executing data--generating data and executing data. In fact, that's how languages work and in college I worked for the comp center and it was thrown upon me to maintain a language called NELIAC and it's no longer wanted. Then later on then another language called Smalgol as a subset of Algol. Which were compilers both written in their own language. You get a sense of, I don't know, bootstrapping and of self-modifying programs and of self-replicated programs when you are in a position of maintaining a language written in its own language. Even if it's written in a simple language, you know, you get this feeling of bootstrapping and moving on and I used to do a lot of that stuff, earlier. In fact, the Turing talk was about work I did a long, long time ago. I'm really sure I referenced the date that it was done in the talk.

MSM: You talked about the game of writing the shortest program that writes itself. You said, "I imagine people programmed in Fortran for the same reason they took three-legged races."

Thompson: (Laughing) I shouldn't say such things.

MSM: Well, all right. It's a great remark.

Thompson: Last year I taught at University of Sydney I gave that to my class, the shortest self-reproducing program in C, and I got a surprise. I didn't think there was a surprise there to be had. But, I got somebody who has the shortest one I've ever seen, which is a record breaker, by about four characters of what I had proved to myself was the shortest program, and they did it by a totally different mechanism which of course nullified the proof.

MSM: Did you spend any time up at MIT during MULTICS ? Did you come...

Thompson: I just went in and out for a day at a time. Maybe for ten times. Something like that. Yeah. I'd go up there for... just ran through the halls and did work and go to meetings and stuff like that. I spent no time, I didn't teach and I didn't stay there for more than a day at a time .

MSM: 'Cause some of these things were very much a part of that environment: Minsky and then LISP, which essentially is a language written in itself.

Thompson: Well, LISP , least the original LISP, you know, the book, 1.5 is... you know I think it's a horrible language. I really do. But, I was struck with that book and the idea of defining very, very low level semantics, you know cons and (not clear). Essentially that's all that's defined, maybe a few more. From that, developing a... it's not so much written in itself that it defines its own interpreter, in a way that gets into the what I think is the whole semantics for (hearing?) languages. It's always been a problem when you write a language or describe a language to say what constructs it recognizes and what they mean and what they actually do and that was the cleanest, simplest, most recursive, beautiful semantics of a language I've ever seen. Probably even to this day. But, unfortunately, what it describes I think is just a horrible language. I agree. That's really striking, 1.5. I did a lot of that. I did a lot of compiling. Even in college and out of college I did a lot of on- the-fly compilers. Ah. ah. I wrote a GREP-like program. It would... You type in ..., you'd say what you wanted it to look for, and a sed-like thing also. That you'd say, I want to do a substitute of A for B or some block of text. What it would do is compile a program that would look for A and substitute in B and then run the compiled program so that one level removed from it do I direct my (unclear) and the early languages, the regular expression searching stuff in ED and its predecessors on CTSS and those things were in fact compilers for searches. They in fact compiled regular...

MSM: Does this reflect itself in UNIX as it was developed?

Thompson: Not a whole lot. Outside of operating systems in general tend to operate on programs and they have to somehow turn the notion of data and programs inside out. They're operating on what they think are data, and that data are running programs. The whole (unclear) is encapsulating processes as not variables just data comes into it. But, no it's nothing real fancy in terms of.... Do you know this kid Henry Heslin (?) He's a PHD student at Columbia. He's the doing a lot of weird stuff very similar to this now. He has a UNIX mailbox that does 68,000. But, when he issues a open on a file. It's the same semantics as UNIX. He compiles into what would be the open file table. Build the subroutines to getchar, putchar, read and rrite and getchar, putchar, that are just amazingly fast with all the checking built in. You know the files open, you know the descriptors here. You know all of this so that.... A read call traps right into this pre-compiled code for that at one character per time in a system that he gets faster than most systems get and are doing 8K at a time. He does a lot of that stuff.

MSM: I see. Does he work from here?

Thompson: No, no. He's...

MSM: How do you know about him?

Thompson: Um ... he wrote a paper that some people hate and some people love. I was struck by it. It's called Super Optimizer. What he does, he defines a function he wants to write, and see, and then he by trial and error, he builds that machine language that will implement the function, he uses the function to check the machine language. So, he'll try essentially all programs and then see if that program equals that program, but semantically.

MSM: (Laughing) I like to see what I'm getting... . It's a difference of opinion.(Laughing)

Thompson: And um, it generates shortest possible program for small functions, you can't do big things. It generates code that is absolutely inhuman. It's, it's indescribable, to be honest. Um, and um code you,... it's easy...there's no way to describe it except that it proves it. I've use that idea, since I read that paper, I've used that idea around four or five times. On one case I used it for a compiler I'm writing for 68000 um, multiply takes thirty-two seconds no matter what. So, if you multiply something by three, thirty-two cycles. Those same thirty-two cycles, thirty-two adds, on this machine. So, what a combination if you change a multiply into shifts and adds. Multiply by a constant with shifts and adds of, you know, the original thing. You're going to always beat the multiply because, the multiply is implemented so badly on this chip and so what I did is write super optimizer, which tries all combinations of shifts and adds to generate, to simulate a multiply by constants between one and ten thousand or something like that, and put them into tables and take the C the compiler and generate explicit code which is the best shift and adds and subtract.

MSM: So the multiply go to the table, look up at....

Thompson: No, no it doesn't go to the table, the compiler goes to the table. You say multiply by five and the compiler goes to the table and does shift left of four and add. It's four plus one.

MSM: So it picks up a particular combination of shifts and adds that will work for that particular multiplication.

Thompson: Right, shifts, adds, and multiplies.

MSM: By doing table lookup and then imbedding code.

Thompson: Right. And it's optimal because that's how the table was generated, by trial and error, all shifts and adds that can generate all multiplies of all things. Another one, is that the bit blit on this thing is um... it's read a pixel, a block of pixels, perform some operation on a block of pixels. It's like plus equals. You know, pixel block plus equals pixel block. Where a plus is a pixel is an XOR an man / you know all these operators. So, you put in any of the arbitrary binary sixteen, any of the sixteen binary operators in this opcode for the bit blit. And the whole thing's compiled. When you do a bit blit you compile the code and run it, and you want the best compiled code for these operations. You had to find the best compiled code for these operations. Put it into tables that are up and generated by trying all of the programs.

MSM: What machines?

Thompson: 68020.

MSM: Is that the NeXT symbol of the NeXT machine? Or is that just the (unclear) right there?

Thompson: No it's just a joke.

Thompson: That's the machine sitting on the table. It's a terminal in.... It's...tactically, if you want to use the word, it's almost a Sun3. It's the 68020 floating point, four-meg memory. Network interface which is an ether--it's a (unclear)

MSM: Did you design that yourself?

Thompson: No, no. It was designed here. Not by me.

MSM: Let me pull you back. ...Talked about this distillation of all the good ideas. Were there ideas that you particularly wanted to avoid, or features you wanted to avoid, or that you had in mind as representative of what was bad with operating systems?

Thompson: Yeah. There were lots of them. I wanted to avoid, special IO for terminals. I wanted to have virtual memory, at least as it's coupled with file systems. I wanted to keep file systems really exclusive and separate from virtual memory--as not be read and be write. There were lots of things. Ah. I wanted to avoid this thing called an "executive". The word has lost its meaning now. What it was is a pseudo-shell, built into the kernel, that somehow controlled the console and execute the commands for you and to drag that out and make it a process of any process could execute any command.

MSM: Just to make sure that every processor...it sets every processor the same as a user processor and having this privileged.

Thompson: Yeah and also to make the thing that became known as the shell it's handled in like any other program. There was no 'the shell' that came with the system that you were stuck with for life. In fact, we started off with two or three different shells and the shell had life of its own. A new shell would come in and supplant the old one and there were... shells performed different functions. Like, there was a shell for a video interface. A shell for a voice synthesizer. You know, what you would do is bring in a touch tone phone and put another shell in its place. So, anyway, the idea that there was no built in known level of command, that, that was just a replacement program that we could avoid like any other. We tried to avoid, you know, records. We were told over and over that was probably the most serious mistake and the reason was the system would never catch on, because we didn't have records. Essentially, the record manager was images imbedded in disk images. Having just this uniform sequence of lights, they said over and over to us that was a serious mistake, but we stuck by it.

MSM: I've just been having exchange systems programmer down at Princeton on the IBM mainframe. The problem, default record formats and what happens when you try and do a get on a file that's got a different format, losing (unclear) records when...do you have a code?

Thompson: I have um. I have um...in that era, we weren't trying to promote this idea. I'd give talks, we always come up, you know, why you didn't do records and I'd have some extra slides, cause I knew I'd be asked this. You know, you know, you jumped and said, " Well, I just happen to have a couple of these laying around. (Laughing) There, the best slide and best story is McIlroy's test. You ever heard of it?

MSM: Sort of finding a....

Thompson: Yeah it's a Fortran program that works ....

MSM: ... the first 'e' in the in the eighth column, and you do it on the Fortran program itself.

Thompson: Right. To ask them to go through the steps is just priceless--to see what happens in these systems when you do that. It all has to do with record formats. Confusing program and data, in a file format. You know, that things... You know, there's text files that are data formatted. You know, on and on and on. (not clear) It's just.... That was one of the things. The other thing is that, there's a series of thunderbolts out of manuals. Describing um. (not clear) By chance...

(Shuffling of papers)

Thompson: I think this might be it...No, this isn't it... .This is very similar.

Thompson: You know about the Yeah. It's putting it there . In our UNIX paper. Um, um. Dennis wrote this. It offers a number of features (not clear) it was actually a joke. It means nothing in a sense. It's those kind of things that people write in papers. People picked it up. Some people picked it as a joke, and some people didn't really understand it as a joke.(Laughing) Variations. Variations on that and that's how it gets picked up. It was a joke. (Laughing) ... four Princeton (unclear) larger bankrupt packages. Can you picture (not clear) ever wearing this thing.(Laughing) BT52, DEC's newest version of (not clear) (Laughing) So, and the other is, the one I was trying to find is, it, it, it was one of the HP3000, brand new operating system, post-UNIX. Talks about the editor and says that, "The editor edits um um binary um card images 84 columns--whatever, some magic number--in a variable format. It's a variable column format, with columns set to 84 and this is what their editor edits and there's about ten computations like that, describing, you know, formats. Record formats and what this has do to convert this to this, you know.

MSM: Is the absence of those kinds record formats the reason why the UNIX editors had no concept of column? That is, if I am in a CMS editor, I can do column substitution, column searches, it not only has the notion of a line, but it has a column and I can go directly to it, do column locates and column changes.

Thompson: I don't know, I think mostly, it has no notion of columns, because none of the languages have notions. Grant, if we edited Fortran, I assume that you'd put a column thing in there. There are regular expressions that you can use to get your (not clear) at things.

MSM: Just no one found that feature particularly useful.

Thompson: If it's a notion that you need or want then I'm sure it will easily. I don't think it has anything to do with records, because, in fact, you know, the only thing important about lines there is newlines. There is a notion of lines and a notion of columns. It's just that we never (unclear)

MSM: The story, as I gather, is that behind UNIX stood MULTICS. All of you been working on MULTICS, then the word came down: no more MULTICS. How did you feel about that?

Thompson: Um. Mixed. Um. Technically, I thought it was a good idea that we were getting out of MULTICS. That it was too big, too expensive, too over-designed. It was just clear it was an exercise in building monstrosities. Efficiency would never come back to the point of where it was .... was cost effective and useful. Most of the efficiencies were dumped into features that were there because they were ... I don't know how to describe them. They weren't there because they were good features, they were there because they were neat technical acts. Um. So, on one hand, I thought it was the right decision. Even then. On the other hand, we, meaning essentially Dennis and I, two or three others, had a ten million dollar personal computer. It was clear that this decision was aimed at getting rid of that. You know, the side effects of this decisions was that this thing was going out the door. Our personal way of life was going to go much more spartan. So, in that sense, we didn't want this decision to go. Um. There's a deeper decision in it than just MULTICS, the crew wanted to work on MULTICS in Bell Laboratories, and that's that computer science research shouldn't work on operating systems. Operating systems were dead. This was the whole.... There was a whole change in thought at this point that, operating system research was dead. Um. Manufacturers, in a laboratory environment, you couldn't build a workable operating system. It really required a development kind of mentality and you know, grind it out. That we provide insight, but we couldn't build one. They were too big, too expensive to build or maintain. The whole computer science research was going to go back to theoretical, paper and pencil kind... There was a signaling of a very strange change here, at that point. Essentially getting out of the computing type of computer science as opposed to the theoretical type. When we persisted we were almost outlaws. We had to beg and borrow machines from weird places and weird sources.

MSM: Why did you persist?

Thompson: It's what I do.

MSM: You wanted to work on operating systems?

Thompson: Well, no not per say. I just wanted to work on computing and programs and it wasn't in essence no operating system. I never really viewed almost anything I did, as what I worked on. It's what I wanted to do next, for some other goal. After MULTICS went away and things settled after this, our computing environment.... Computer science and the Computer Center were one, and it split and the Computer Center went off to the services area, you know, like people who do the air conditioning. Computer science went into research. Um. We then had to go over a fence to talk to the computers. The computers were not with us anymore. We were a service organization where, you know, you had input boxes and output boxes and submitted cards over a counter. Very, very different approach what we were used to up until this point when we, since it controlled everything. The operating systems became vendor-supplied. In particular we went GECOS, and a word on top of GECOS, called TSS. Which was their time sharing system. Which was nothing but batch card entry. Quick turnaround batch card entry into the batch world. That's what they call it: TSS with a partition for editing. It was horrible just to use that. The operating system, I think was just a (not clear) to get into a environment (not clear).

MSM: I was thinking about this yesterday. As you may know from what Doug has said, I'm doing a history of software in general, during the '50's and'60's, working up to the roots and the kind of thinking that was going on in the late '60's as the software crisis emerged. Basically the question: how did the industry get itself into that, that situation? I was thinking about the operating systems of the '60's, which, if I understood them correctly, as someone who, when he was programming in the late '50's for a small company, still on the machine at night and worked at the console that to debug a program. I never went through that: hand on your cards and wait until the next day to get your output, first stage of program computing. That the notion of the operating system was to make the machine efficient. That the notion of a system like UNIX is more making the program more efficiently. As it's a programmers system rather than ...

Thompson: It was a combination of both. I mean there's reason they would be mutually exclusive. Um, um. The talk of the day in the conventional wisdom, which I never really bought, was that they were mutual exclusive.

MSM: That was the feeling at the time?

Thompson: Yes, and that um, time sharing would never survive because, you're spending all of your time on this big mainframe, you know, all floating point hardware and all of this stuff, you know, fielding these ratty little interims from people typing on flex-o-writers. And it was self-fulfilling prophecy, they believed that, in the systems they that built. Believing that, demonstrated that. Because, it makes it what it had to be. I think that in time sharing you can do better than batch. That you have a better mix of things to do and you can do scheduling in such a way that you just can't get in batch.

MSM: Follow that up, because, again, there is the lore that has grown up around that. On one hand, I gather that what you all felt most strongly about at the end of the MULTICS project, other than the fact is that you have a ten-million dollar personal computer, was that notion of communal or convivial computing, that is that you have been able to share files with one another, become a medium of communication among you and that you felt--Doug at least said he felt that that really hurt to lose out. Then the other story is that UNIX started off as a personal system. A one-person system. Those two stories (People laughing) aren't entirely compatible. That is...did you have a notion when you started UNIX of restoring that sharing? Was that in from the beginning? It was going to be multi-user system from the start?

Thompson: Not, explicitly, I think. I was more interested myself. Just selfish notions of trying to get a environment to work in.

MSM: Were you trying to build a programming environment for yourself?

Thompson: We always wanted to expand it and turn it back into communal things. We were always trying to get machines that we could take home, you know and share among wider groups of people. There's massive amounts of software that had to be developed, languages and all applications and all sorts of things. You just can't sit there with that Model 33, you know, wired right into a computer and do it all yourself. You can get your own work done, but you can really work faster if there's a community of ideas, a community of help. Application programs you can use and rely on. (People talking in the background)

MSM: As you were the developing the system did you have it in mind to keep that option open at all times, with decisions informed?

Thompson: Well, it was always time sharing in that sense. Sometimes it was a single-user system, but, it was always a time sharing system. I think it was implicit. It was never voiced, but it was always meant to be a shared system with lots of users.

MSM: When you and Canaday and Ritchie, I think that's the three, settled down to find a file system, what were you looking for? Because, the file system you designed looked like, if I understand it correctly, looked a lot like the MULTICS file system.

Thompson: Up to the point of writing simulators. Ah. The idea of the file system was to um, to have the activity locus of manipulation of data for user one and user two.... to be disjoint, so that in fact, wouldn't be locking common tables. Wouldn't be going through anything common unless we in fact shared files. To try to keep up real high, efficient access to disks. In fact, interleave accesses in a way. If two users... one user would expect some sort of response call or whatever it is and that at least with the disks of the disks of the day, two users will be able to command it and interleave seek times on the disks, and would not degrade each other. That was the idea behind the file system and the design; to move the addresses to the point where things could be cached and that your working and my working wouldn't interfere with each other in a locking sense or in a real sense in any way that (not clear). Um. I had built this system in a high level simulation of the whole file system and had gotten as results that these common disks of the day that in fact, you could enter(not clear) of your requests and get lots and lots of users happy at the same time.

MSM: Was this the one you were doing on the 645?

Thompson: Yeah. I was doing it on the 635 at the time. Yeah . I got these exponential curves where before it would get into trouble it would go way out and get lots and lots of simultaneous accesses going... I was playing with a disk sorting algorithms and caching algorithms at the time. All of those actually went into UNIX. Um.

MSM: This would be the research aspect of the work?

Thompson: Yeah. Then in the actual design. At that point, it just went to... There was a model of a user and a model of this, and they generated activities, and the activity went into the disks that were sorted and things like that. Um, um. It was never down to a design to the point of where you put the addresses, how you expand files and things like that. It was never down to that level. It was always at some higher level. I think it was just like one or two meetings, Dennis and Canaday and myself. Was just discussing these ideas of the general nature of keeping the files out of each other's hair and the nitty-gritty of expanding. Of the real implementation, where you put the block addresses, where you put this and this. I remember, um, we did it in Canaday's office. At the end of this discussion Canaday picked up the phone, and there was a new service in Bell Laboratories, dictation, where you call up essentially a tape recorder and you give notes, and then the next morning notes are typed and sent to you. The next day, these notes came back and the acronyms were butchered, like "inode" was "eyen..." (Laughing)

MSM: You should see the transcripts of your '81 interview. (Laughing)

Thompson: So, we get back these, (unclear) description and they were copied and we each got copies of them. They became the working document for the file system, which was just built in a day or two on the PDP-7.

MSM: But to the user it would look roughly the same as a hierarchy of directories.

Thompson: No, the first one was a DG. In fact, it wasn't even a acyclic. If you understand the UNIX file system, it was.... there was the I-list, which is a definition of all the files on the system. And then some of those files, were directories which just contained name and I-number. There's nothing in there that constrains it to a tree. So it was not in fact, not hierarchical at all.

MSM: I see.

Thompson: And we did not restrain it to a tree. We were experimenting with various topologies. What we ended up doing is turning into concrete and forcing the topologies that in fact were the topologies that came by convention from that system. The... Every time we made a directory, by convention we put it in another directory called directory--directory, which was dd. Its name was dd and that all the users directories and in fact most other directories, users maintain their own directory systems, had pointers back to dd, and dd got shortened into 'dot- dot,' and dd was for directory-directory. It was the place back to where you could to get to all the other directories in the system to maintain this spaghetti bowl. So, I mean this tuff in various forms, which was strictly convention in this DG implementation of just random set of directories and files got forced into a typology that we maintained. When we started writing things like file systems checking programs and stuff, the locking of the spaghetti bowl directories and finding of disjointed things, I mean you'd dissever something and never get it back, because you know you'd lost it. Those problems became close to insurmountable, and so in the next implementation we forced a typology stronger than that.

MSM: The PDP-7, you used the famous graphics machines you found. Um you went to when you found out you had in mind to just put the file system on there or ...?

Thompson: At first, yes, we used it for other things, the famous space travel game, and it was a natural candidate of a place to put the file system. When we hacked out this rough design of a file system on the dictation that day in Canaday's office, um I went off and implemented it on the PDP-7.

MSM: Ok the PDP-7 was already around at that point.

Thompson: Yeah. We had already done uh...we'd spent a lot of the summer doing it... space travel...we had a lot of the pads worked out, we had assemblers and...the assemblers were actually on GECOS, and they'd generate paper tape and we'd carry the paper tape down the hall and...

MSM: Were you looking for a graphics machine, was that...because of the space travel game?

Thompson: No, no, we used it because it was there, it was a graphics machine before. It was designed to be a circuit design system where you'd lay out resistors and transistors and things.

MSM: So originally you grabbed that from doing the s pace travel, worked up a certain number of tools on that in order to implement space travel, and then came the file system and you went to implement that.

Thompson: The file system didn't exist by itself very long. What we did was... to run the file system you had to create files and delete files, re-unite files to see how well it performed. To do that you needed a script of what kind of traffic you wanted on the file system, and the script we had was, you know, paper tapes, that said, you know, read a file, read a file, write a file, this kind of stuff. And you'd run the script through the paper tape and it would rattle the disk a little bit...you wouldn't know what happened. You just couldn't look at it, you couldn't see it, you couldn't do anything. Um and um we built a couple of tools on the file system...we used this paper tape to load the file system with these tools, and then we would run the tools out of the file system, that's called an "exec" by the way (laughter), and type at these tools that was called a "shell", by the way, to drive the file system into the contortions that we wanted it to uh, measure how it worked and reacted. So uh it only lasted by itself for maybe a day or two before we started developing the things that we needed to load it.

MSM: At what point did you feel you had something here?

Thompson: Um, well, the first one was not at all multiprogrammed, and was almost like subroutines on the file system. The read call, the system read call, was in fact the call "read" of the file system and it was very synchronous, just subroutine call to the file systems for these applications. And um there was a very quick rewrite that admitted it was an operating system, and it had a kernel user interface that you trapped across. I really can't remember what the realization was, I mean, the whole time span, from initially starting with...walking downstairs, down there with the idea that we were going to build a file system.

MSM: When was this, do you remember the time?

Thompson: Yeah, it was the summer of '69.

MSM: Summer of '69 ok

Thompson: In fact um my wife went on vacation to my family's place in California to visit my parents--we'd just had a new son in August '68--and uh they hadn't seen the kid so (unclear) took te kid to visit my family and she was gone a month to California and I allocated a week each to the shell, to the operating system, the shell, the editor, and the assembler, to reproduce itself. During the month she was gone, which was in the summer of '69, it was totally rewritten in a form that looked like an operating system, with tool that were sort of known, you know assembler an editor and a shell. If not maintaining itself, right on the verge of maintaining itself, to totally sever the GECOS connection.

MSM: So that you could work directly on it.

Thompson: Yeah. And from then on it kept pulling up files.

MSM: So we're talking about a month's development.

Thompson: Essentially one person for a month, it was just my self.

MSM: How'd the others get involved?

Thompson: um Doug got involved (unclear). Uh it was multiprogrammed...processes from the beginning, but it was just one console. And with just a little bit of work we turned the graphics scope into just another typewriter. You know, you print on the screen by inking characters all by hand as well. And so then it became two users, and it was constantly full, it was constantly at two users on it. (Unclear) got involved he was doing TMG, which was a compiler compiler language predecessory to the yacc kind of languages. Dennis got involved with ...during his language work. Uh (unclear) who was doing, he didn't do too much. I mean when it was in the PDP-7 form he didn't do too much. He did some... a number of theoretical kind of things.

MSM: Who else was involved?

Thompson: There were a lot of people involved, in a political sense, you know, trying to keep the machine for us, and get us the next machine, and that kind of stuff that weren't doing programming.

MSM: Who were these people?

Thompson: Uh Peter Neumann, Lee McMahon, (unclear) Matthews.

MSM: They were running interference with managers?

Thompson: Yeah. Joe Osanna did for ... at that point also. Uh he later became very involved in the thing. His pet thing was to develop a um text processing system, to um, which you call a desktop publishing or whatever word processing. A text processor for... he had ideas about secretaries and typing pools. And he was constantly on the lookout for good typewriters, in the sense that secretaries would use, and that could use a touch type, you know, IBM Selectric type typewriters, that were computer interfaced. And we'd go to almost every toy show, with this in mind. Looking for...I mean the industry was in sad shape at that point in trying to (unclear) things that we needed to accomplish some of these goals. But um everything that connected to computers was upper-case only, six bit generated and are very, very expensive. There's the 1050--you know what that is?--it's an IBM Selectric but it's about this big, and was loud and was about this tall on a console. So anyway they were interested in typesetting equation ... not typesetting but ... typewriter setting equations and doing TMS and documentation.

MSM: So was it Joe figured this was something he could sell to management? Keep your system (unclear) going?

Thompson: I don't know his motives. I won't guess his motives. Um I know he was genuinely interested in it, uh he in fact got a commercial type-setter and uh got it interfaced with the computer. Essentially ripped out the paper...it was meant to be driven by paper tape, and the paper tapes were to be, you know these typewriter to paper tape things, and what we did was we cannibalized the paper tape interface and just ran it over to a parallel interface on a computer, and we just punched paper tape...logical paper tape over to it over a wire. And uh it really had the first typesetting of this sort, so it was all way ahead of it's time and that was all Osanna's work. And it was all towards this ultimate goal of computer text processing.

MSM: I know the um when I asked Doug about pipes in (unclear), the story that I was telling him when I was coming up to talk to him--my my daughter who is a computer science/music major up at Harvard--said uh "Well, what did he do?', and I said "Well, he's (unclear) who had the idea of pipes. And she said, "Oh, well, you ought to call this project 'pipe dreams'." Uh I asked Doug about pipes and he talked about what the background to it had been, but he also told me that you were able to implement that overnight.

Thompson: Yeah,well, Doug had was for years and years, well it seemed like years, I don't know the actual span was probably one year, Doug had uh, and he talked to us continually about it, a notion of interconnecting computers in grids, and arrays, you know very complex, you know, and there were always problems in his proposals. That what you would type would be linear and what he wanted was three-dimensional...n-dimensional...I mean he wanted just topological connection of programs and to build programs with loops and and you know horrid things. I mean he had such grandiose ideas and we were just saying, you know, 'God, it's worthless, the complexity you're generating just can't be fathomed. You don't sit down and you don't type these kind of connections together.' And he persisted with his the grandiose ideas where you get into Kirchoff's law problems, where you get into you know, what happens if you have a feedback loop and every program doubles the number of characters, you know, it reads one and writes two? You know, what happens to...it's got to go somewhere you know. And you get these synchronization just, I mean there's just no way to implement his ideas and we kept trying to pare him down and weed him down and get him down, you know, and get something useful and distill it. What was going on, what was needed, what was real ideas, what was the fantasy of his ...and we there were constant discussions all through this period, and it hit just one night, it just hit, and they went in instantly, I mean they are utterly trivial.

MSM: And that a reflection of the basic structure of the system or was it just coincidence?

Thompson: No it was just we had control over it, it was our system. We could....it wasn't a big system, it wasn't a big thing to put in it was just, it just took minutes to do because we knew what...

MSM: Is pipes the sort of thing...pipelines the sort of thing that can be implemented in any system or are there certain system requirements?

Thompson: Uh well you really have to have real processes, and some places (unclear)data. Um for them to work in a um for them to actually work you have to have the notion of reading and writing streams, or whatever you read and write, and that the I/O cannot be different from the files.

MSM: Oh so that goes back to that idea, that that's a prerequisite.

Thompson: Yeah. Because if you have programs that sit there and read terminals, and then manipulate files back and forth there's just no way to connect them. Because what they read and what they write have to be the same thing.

MSM: How long was this the skunk works when did you . .. well you said in the beginning you were building an operating system in spite of what was supposed to be going on. Uh when did you go public with it, within the company?

Thompson: Uh we never really did. Um every step was painful . (Unclear) We couldn't have...uh it was an obsolete machine at the time the company the the, we didn't own it, uh it was another department that owned it, and when it would break, it would be a hassle over who maintained it, and we didn't maintain it because we couldn't get our department to pay for maintenance. There was, you know, no money at all but they just didn't want us to do this. We not only had to buoy this company, this department that owned the machine and wanted to throw it away, but to keep it, on their space and maintain it for us. That was a precarious situation, and that persisted. Then when it became clear that these machines were nearing the end of their life, uh we either tried to get them officially ours, which failed, our manager wouldn't pick up these machines, at zero cost, you know, they didn't want...the cost of the space. Then we started on a set of proposals for getting a new machine, through our management to replace it, to get a new machine, and they were all um... There was no explicit policy that we weren't going to get back into the computer business, (unclear) we really know the rules, you know, but the rules were in effect. So what would happen was that we would take these proposals for these machines and do all the research on them and get the vendors in and waste everybody's time, and get these proposals up and they'd be thought about our management for a extended periods of time and they'd say 'no' for some funny reason, you know, never for a real one (unclear) computing anymore. There were several, really several, of these big rounds of trying to get a vendor and a machine and, to get....to do this work. Most of it was carried on by Osanna and me, and the interference type people. Ultimately what happened was um we found a PDP-11, it was in fact not announced yet, but uh it was right on the edge of being announced. We would like the for the idea of text-processing we liked the expandible IO of the Unibus, where we could build our own interfaces, they had general purpose interfaces, they had lots of com gear, uh that we could do for...I mean it had everything. It looked like it was going to expand to any machine we wanted to make it. Um and these people, Osanna and I put together a proposal to buy a PDP-11 to do text-processing, research in text processing, (unclear) and document preparation, this type of stuff. Uh it was the first of the goals that were specific, uh we want to do this for this machine, um for this purpose. The other ones were...we wanted to play with computers and operating systems, and they were unspecific, and the our management went off and thought about it, and rejected it again. But in the meantime going up and down the hierarchy a sister department, 122, psychology research, uh came over and said 'well we'll fund it out of our area,' embarrassed the hell out of our management. And they bought it, gave it to us, and...

MSM: What were you looking for?

Thompson: Well it was interesting, they thought it was interesting. They just had insight, and inspiration and unfortunately our management didn't. They were suffering from wounds, our management was suffering from wounds from the MULTICS days and you know ...

MSM: MULTICS really hurt?

Thompson: Yes. Lots of promises to lots of people to develop software that would be everything to everybody. It was sold, company wide, to be the computing utility. There'd be, there would be a plug for 110 volts, and right next to it there would be a MULTICS plug, and you'd just plug it in and suck out whatever cycles you wanted for anything you wanted. You know it just, it would just be the utility, you know just like a power utility or a phone utility, it was just the computing utility. For everybody. Everybody would have all the cycles they wanted. It was sold big all the way down the company and...

MSM: So it was a notion of once burned, twice wary .

Thompson: Anyway the 11 came in, um it say for a month in Osanna's office, because uh, it had no disk, the disk was delayed, it didn't come with it. And we'd type stand-alone type things, this stuff, um. Then when the disk was just ready to ... you know the disk was just ordered and was on its way, they were actually starting to manufacture and we were on the waiting list, we brought the machine up next to the PDP-11, which was what we were working on, and we started writing all the cross stuff. In B. We wrote a PDP-11 assembler in B, and ran on the PDP-7 the PDP-11 assembly code and punched paper tape out of the 7, you know out of the...across the floor into the 11 and had fake file systems that were done in memory, and we got it almost running, the disk came in and in probably another week we got UNIX running on it...At that point a lot of things came into being...the topology of the directory structure was fixed on more convention than convention by that point...

MSM: When was this, 1971

Thompson: Yeah, let me see, 71? Maybe '2? I don't know that. It's mentioned in one of the UNIX manuals, the dates rolled up....(unclear) And we moved over...Osanna...I was just interested in operating systems, I went along with the text processing (unclear). It didn't interfere with my plans so I ...went along with it. The editing, and the stuff around the text processing, and Osanna did the... went on to the nroff, troff stuff or the text processing. We instantly put all our secretaries on it. They did our mail messages and our documents and did that so we did text processing for that, then we uh as part of the demonstration Osanna got the patent people, patent application to come over--they were just about to buy a horrible little commercial type setting package--called, we shouldn't mention this...AstroText was the name of it...and it was just truly bad, and we could cobble together something that would be vastly superior to what they were about to pay real hard...you know a lot of hard money for. Um, and so we put their stuff together and developed a package for them that was specific to their applications, you know, they have very different kind of formatting (unclear). Um and in fact they liked it and they still had this money in the budget for this AstroText thing, and we talked them into buying our system, physically, you know, the hardware, move it out, and we took their money and bought an 11/45 with it. (Unclear) interim machine was a um. Before the 11/45 was available we bought a PDP-11 that had PDP-10 memory management, KS-1, it was a one of a kind machine, and that was the first time we ran the production of program development along with these--all in assembly language--along with these typists typing real applications and uh (unclear) on unprotected machines.

MSM: You hadn't gone over to C yet.

Thompson: No. C was fairly late.

MSM: (unclear) DEC machines. Did DEC ever show any interest in what you were doing?

Thompson: No. At one point we put a notion to them, and said um...the way it started running internally, is the word just got around, and these random groups would come in and say you know....everyone, technically would look around for a machine and choose a DEC machine, and DEC had no software, they were real late in the delivery of their software, and when it came it was horrible, just...that was probably the early reason UNIX thrived is because it had no vendor competition at all, none. It was the only software around for the DEC machine, and so they'd look around, they'd find DEC machines, they were just without technical peer. And a project would buy a DEC machine and they'd look around for software after that, and they'd hear our names, they'd come and talk to us. And they'd decide that they were going to run UNIX for their software development, develop their application and then run their application standalone; it never happened, they never got rid of UNIX. You know their application would run on top of UNIX (unclear). The story was always the same: that they were going to use software development, develop their application, and then deliver it with the application. And these things kept proliferating, more and more and more of these things, it was all underground. No one, you know, we were the only ones doing the development, and they'd want records or they'd want this or they'd want that, and we'd tell them no, we didn't like that, doesn't fit into our plans, so to hell with it. Uh and that's how the UNIX development group got involved is to do the to be more responsive than we were to the needs of the people. (Unclear) were starting to put these machines in (Unclear) telephone applications.

MSM: Would you say... is this the point at which UNI X became standardized in some sense, got settled?

Thompson: No, no um we had momentum, in our department, we were working...these guys were just fighting--the development group--were just fighting to learn what it was. By the time they learned, it was something else. I mean things were really moving fast in those days, and they would spend most of their time, coming up to speed with some version they'd cloned in the past, and in the meantime there would be three more of their customers that would have cloned from us, because they needed some new thing that we had and, then they'd end up retrofitting our current version back into you know their version, and most of their updates were in fact taking our version out. And this went on for several years, where they were just some sort of conduit buffer, and trying to learn what was going on. Um probably an unenviable position for them to be in. And it wasn't until there was a second group from (unclear) that cloned a version of our system and started doing...going off in their own direction, really doing their own work for it themselves. And they merged um (unclear) and, and a combination of our system and their system turned into the development system, which was the standard system, which, I think, turned into System 3. And from then on they were fairly separate, and just took ideas rather than massive amounts of code.

MSM: I was going to say, when did it wind down for you, or did it ever?

Thompson: Um at some point it got ponderous, and I decided to get out from under it. And I did, I took a sabbatical at Berkeley, just disappeared for a year. And you know, if you're here, you are indispensable; if you're not here, you know, (laughing).

MSM: That's why I'm going away next year...

Thompson: Yeah so I went away for a year and when I came back it was just...I was just not in it anymore, not in the mainstream and not needed for(unclear). It was actually planned.

MSM: So what did you go off to do?

Thompson: Uh, (unclear) I actually did a lot of system development for them, it was the start of their ascension. Most of the names you know were in fact students of mine.

MSM: I see...(unclear) the development of UCB.

Thompson: Yeah...when I went there they had one UNIX machine . It was (unclear) statistics, that they'd run it three days a week and statistics would run it three and they'd fight over it the last day, or run maintenance on it that day. When I left it was in almost every one of their courses. They had about three machines on order, they had three or four machines installed, real confident students.

MSM: Looking back (!phone!)...just one more, because we have been going for a long while. Um you look back on it...is there something fundamental you'd like to have done differently?

Thompson: Um, I had regrets about a couple things. Um probably the biggest thing is I had some little lash-up applications, uh with remote shells, and distributed machines where you had a shell where you could execute pipelines with different parts of different machines. Um and I never pursued that, and because of it there's these, you know, the stuff that we laid out and distributed was hardly ever changed; our file system, the composed read/write, the pipes, and you know all these things. The stuff that we left fuzzy, got done either poorly or multiple ways and their different, different systems and their addressing strange (unclear). And I think that if we had worked harder, had the insight or done more in networking in those days then you know things would be different. But uh it was, it's, it's nothing that I could have predicted, it had to be in retrospect to think of that. I dabbled in that area, and just never, never installed it, never distributed it as part of the system.

MSM: It's always easy to be wise after the fact, and hard to imagine how one thought otherwise about certain things, but, one thing about these timesharing systems of the late-60's...operating systems and the notion of making them time-sharing was the shared notion that computing was going to become generally available, it was going to be through a plug in the wall to a large central computer, when, in fact, that's not how computing has become available to people at all. Were you still thinking in the late-60's early-70's when you were doing UNIX about using a central computer, or did you...

Thompson: Yeah, in fact, I still think that way. Um in those days I typically thought of using one central computer, um mainly because of the expense and stuff like that, you know, RAM, and lack of networking although I'd done the interconnection of UNIXes to some extent. But now I am thinking of still central computing, but with multiple central computers, designing new operating systems that way, um I think that there... the comp centers maintain hardware better than people do in their offices. And um if you compute in your office, like a workstation mentality notion, that you are always stuck with a small machine, that you can't afford, on that machine, to put a hundred megabytes, but uh, on a central machine you can, and that for short periods of time you can use the 100megabytes... um for you applications. And that the sum of these, the distributions of how much memory you need and how much I need averages out much quicker on big machines than they do with one person with one machine on your desk. So I think that small amounts of sharing in central computing is better for everyone; it's cheaper and everybody gets better service and better cycles than they do on their machine on their desk. So I still feel that way.

MSM: But it would be a distributed system.

Thompson: Yeah, it would be several of these uh compute servers, call them whatever they are, but they're just there for these economies of scale, and you get these economies of scale with a few users.

MSM: Ok...

Peter J. Weinberger

Friday, September 8th 1989

MSM: You joined AT&T in '76?

Weinberger: That's right.

MSM: From what?

Weinberger: From the University of Michigan. I was teaching mathematics. My background is in mathematics. Got my Ph.D. in '69 from Berkeley. And uh...

MSM: What kind of math had you done?

Weinberger: Number theory. Analytic and algebraic number theory. And I worked for a year in Washington then I went to the University of Michigan, taught math, wrote math papers and stuff. And then I didn't get tenure. And so I looked around for.... It's a big decision... It's what would I rather do? You could pretend you have many choices but the basic choice was would I rather be at a first class place or would I rather keep doing number theory and end up living in a place where perhaps I didn't want to live. I don't know that I could have gotten tenure at the University of Illinois but that was the kind of place that...where I didn't particularly want to live and I managed to get a job at Bell Labs in Development in '76 and worked on computer stuff -data bases and things. And in about a year and a half (as I remember - my memory for this stuff is not good) I transferred over into research. That was done by when we started working AWK.

MSM: I see...so you came in with AWK. How did AWK come about?

Weinberger: Well, as I remember, I came over to ask while I was doing this data base work in development (up the hill someplace)...I came over to ask Aho about parsing because there these...there was this sort of current about extensible languages. And it seemed like it would be convenient to, you know, add.... It was one of those things where the name is more than what the technique actually provided, ok. Extensible languages seems very desirable. The user could adjust the syntax in the language in some way and the composite would somehow automatically understand it and it would all be more convenient for the user, and so forth. And, um...Al was not very enthusiastic about that approach for...the technical reasons where that he was at that time, and I think as everybody is now, much more in favor of table driven parsers, in particular LR Parsers, and if you've compiled a table it's a little hard to adjust the syntax. And I suspect in retrospect he didn't think much of the usefulness of the technique. And I think in retrospect, he was probably right. Extensible languages is not something that worked out well. And the places where people are very enthusiastic about tailoring the syntax of...of...for users. There's two of them that I can think of. One is emacs, which is this editor where you can bind keys in weird ways. And the other is with something called Read Macros and Lisp. And the effect of both of those is that I can't enter your world, because each person personalizes his world in some...some way they like and nobody else can cope. So in fact it's not at all clear it was a good idea. But he said 'oh, you're in databases?'. He and Kernighan had been talking about some database-y extensions to UNIX. So we sat around and talked about this stuff and there's roughly speaking 2 pieces to databases. One is the question of how you get stuff out of the database. And the other is the question of how you sort of put stuff into the database. And putting stuff into a database gets involved in these 'are we going to allow for concurrent transactions' and 'do we have to do locking' because UNIX was not particularly good...was incapable of in those days. And it was just all too weird. Eventually we settled on the idea of what we wanted was some...thing that 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. I don't know exactly what. Then stuff like grep, which just search for these patterns. That was all it did. But you didn't want to give that stuff up either. So whatever you were going to do was in this world of.... It wasn't going to just go into the database world, which to this day doesn't understand regular expressions. It believes everything. A lot of them are firmly into fixed size fields. And a lot of other stuff is pushed by a somewhat spurious view of efficiency, at least in small databases. So that's AWK, ok? AWK is like graphics, except it understands numbers and it understands that things could be divided into fields, and.... We went through a bunch of versions. As with everything, you get a lot of versions right at the beginning, and then things get stable with only slower changes.

MSM: Can you assign responsibilities to the AW&K?

Weinberger: Not so much in the finished object. I can pick out in no particular chronological order some of the things that people did. Always, Aho was in charge of the regular expression stuff, because you need some variant of regular expression stuff and he can just write it. He doesn't have to worry about it.

MSM: ????????

Weinberger: I did...we discussed syntax a lot. Kernighan likes free-form syntax. That is without extra parentheses and stuff, because it's so much easier to type. The problem with free-form syntax is that after a while the language becomes very ambiguous, and it's hard to see what it all means. I like more parentheses and stuff like that. So we tried out a couple of different syntaxes. We spent a lot of time discussing, all of us discussing, this pattern-in-action business...was that really what we wanted to do? And several rather more elaborate ways of doing it which were more database-y, which in the end didn't go in because either...we couldn't either...it turned out they didn't add anything. It was just do the same stuff anyway. Or we can figure out exactly what they meant and how to make them work. I think I wrote the first...a very early translator to try to...all it did was take these provisional languages and put out C-codes so you compile it. And...this may not be quite right. I think Kernighan wrote an interpreter, and then I wrote an interpreter and then some years later Kernighan re-wrote the interpreter. Or we both re-wrote the interpreter.

MSM: Am I right that there's a certain YACCy flavor to it? It looks a lot like C-code...

Weinberger: I ought to say a few words about the appearance to the users of the whole thing. Yeah, the pattern action stuff is...I'm not sure that yacc...yacc must have been in our mind. Because in those days especially there were not very many models of that stuff. There's another, I forget whether these are mark off somethings or post somethings...one of these constructs in theoretical computer science. Maybe they're post-productions...you match the left side and transform according to the right side, which is also vaguely the yacc model. It's not just yacc, it's several things. The C-like appearance of it all is...instead.... Well, the idea is if you made it just like C then you wouldn't have to explain it to the people around here. Or, that's how I remember the idea. We may not have been quite so concrete about it. What's interesting is that at the same time that we were doing AWK, there was a project at Xerox Park called Poplar. Maybe called Poplar. Anyway, whatever it was called there was this project at Xerox Park, which had fairly similar goals. That is they were going 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. And they put a lot of work into clever ideas. It was a functional programming language. Which that's...especially then a big deal, now it's less of a big deal. And it was supposed to be user friendly and in addition you wrote the program sort of here and then you worked an example on the other side of the page and the compiler checked that the program worked the example the same way you had. So that you had some feeling for what the program was doing. And there were several other quite nice ideas. It 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. A lot of the stuff we were just prepared to push on. And, so this is a probably fairly friendly user interface. I don't remember the language but you had to learn it but it wasn't really complicated. Whereas we had all the C-grot and there's lots of C-grot that...particularly bad partly because of power syntax. There's this...the...one of the less...one of the ideas that I pushed fairly hard, which in retrospect is a little mixed, was this idea that to do stringing catenation, you just...stick the stuff there. And this just gave the parser complete hell. It's a swell idea but it doesn't mix well with, you know, minus signs or something. And, we really went through hell keeping that working. They had all sorts of stuff. And AWK lived and Poplar died. And I don't know...you know...this has affected my view about people who talk about user interface fairly severely. I'm no longer convinced anybody knows anything about user interface. It's clear some things are easier to use and some things are harder to use. That's okay. But it's also clear that people...people...learn a lot. Okay, and that some kind of...that, 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, okay? And then the fact that it's a little weird isn't so bad. Because, you know...you're just changing it. AWK lives partly, I think, because of it's programming by example. The style you write code. Um....

MSM: I have Poly-AWK on my home computer, so I use it quite a bit. Indeed, I use it...I got it because I was just interested in it and I discovered it down in Holmdel. But then I had to deal with the ASCII file output of the database and I didn't know...it proves that I can do anything that....

Weinberger: I know, I know...it's...it's been a real success. It really worked out well and all I can...the only reason I can think of for that is because what we wanted to do with it was something that was worth having a tool that does. A lot of the other aspects of the program are irrelevant compared to the fact that it does something useful.

MSM: Let's take that back for a second, because one of the big criticisms of UNIX is user interface. It's a difficult system to learn. I wonder to what extent what you just said about AWK applies to UNIX as well?

Weinberger: Well, there's 2 pieces to that. Let me do not the one you asked but the one I thought you were about to ask. The way you compose programs in UNIX is this pike. What the pike...and...well, that's just what the system provides the way it's used. Almost invariably, is...this guy puts out text and this guy takes in text and this is essentially aside from that very low level thing. This is a technique with no structure. So it's academically completely unrespectable. Because there's no types. Everybody's got to agree. Now, in UNIX the convention that makes this work is everything is line oriented. Or, almost everything is line oriented and everybody at least knows they're getting lines and they have to cope as best they can. But for many years UNIX took a lot of crap on that I think in academic circles because it's so untyped. Academics don't think of ASCII as the type, right? I thought of something much stricter. But one of the experiences I think of all that sort of computing is that there is a balance between safety and usefulness and a balance between various flavors of generality. And the kinds of generality I think you have here is that if...if...if only passed typed objects, of course, some kind of small talk interface...if everything came with the type. That would be one kind of generality. The other kind of generality is you just passed random bits and its up to everybody to cope. I think UNIX was successful because it turned out that a lot of the safety that people relied on or that academically seemed respectable because you can say things about it...just...just was pointless. There's no need for it in many things. But of course, UNIX programs screw up all the time. Because one guy puts out output in a form the other guy cannot accept as input. That's one of the reasons for AWK, after all...is you gotta transform the output. But...if the...you can view this in retrospect of course...part of the UNIX philosophy as being...that's just inevitable. And it's important that the system provides a convenient way of coping with that. So the idea that you have...that you can stick an extra guy in the pipeline, shell scripts or AWK or whatever, to somehow adjust all of this is very much in the UNIX flavor of things. On the other hand, it means that UNIX is a system for people who...who...for people to use it like that. People have to be prepared to tinker. And if you provide a system where people can tinker, it's bound to have a lot more stuff at the top level than a system where people can't tinker. And I think you could contrast that with PC interfaces. This is long after the fact. People say 'well the PC interface is uniform'. Well it's not uniform at all in fact it's really crappy. But it does have properties. That is when you get Word Perfect...Word Perfect has 17 flags...you want Lotus 123 output, you want text output, you want Harvard Graphics output, you want all these different kinds of graphic output. And you buy something that either has the features you want or you can't have it. There's no chance of adjusting it yourself. And although people say UNIX is hard to learn, I noticed that each application that comes with your PC has a manual that's the size of the full UNIX documentation, at least the full research UNIX documentation. Now it's a hell of a lot less terse. But nonetheless, this idea that, for each dollar you buy on some paper software you deserve 10 pages of documentation, seems to sort of pervade the PC world. So, yeah, I think it's a little more...somewhat more complicated and that...in...but I don't believe it's all that much more complicated. I do believe nobody explains it very well. And certainly those of us who are experts are not very good at explaining well and probably not capable of explaining it well. My guess is that there is a modest amount to learn and you can use it. And the truth is our secretaries use it. We don't have a special system for secretaries. They just use it. Now, when you watch them use it you say 'oh, but there's so many easier ways of doing it...there this and this'...but it doesn't really matter. They don't have to use it perfectly.

MSM: Did you know about it before you came here?

Weinberger: When I knew I was coming here, I started looking into it. I'd heard of it, but it wasn't something that was easy to find.

MSM: What was the status in '76?

Weinberger: Well, it was being shipped to universities out of research. I think that was version 5 in those days. Possibly the beginning of version 6. Version 5 I'm pretty sure was the assembly line version.

MSM: It hadn't reached Berkeley by the time you left?

Weinberger: Oh no that was '69, no, no...and I think it went to Berkeley with Ken's sabbatical, which was probably '75. In '69 it was hardly anywhere. Even here. But you can find it at universities. But I went back to Berkeley the summer of '75, I think. I don't remember when I was back in Berkeley. But anyway, that's where I had...I think it probably was in between semesters or something...it was the winter. And Ken was there and I met Ken at the house of a mutual acquaintance and learned to use some UNIX stuff. And found it...you know, I was learning C at that point too...and continued to learn when I got here. But I found it much easier to use than the world I was used to. The...one of the...it had a bunch of really good properties which I suspect are partly Doug's responsibility. You can take the manual which was pretty big even in those days and you could read it once and do some things and you could read it again and read it again and by the third time through you actually understood how the system worked to a large extent. All of a sudden things became much less surprising. And then all the source code was on-line in those days. It wasn't all that much source code. And you could look at it. And a large fraction of it had been written by people with very good style. Right, like say Dennis. And you could to write C from it too. So I found it very easy to learn and I found it very easy to switch from FORTRAN to C.

MSM: FORTRAN is what you had been using?

Weinberger: Yes FORTRAN is what I've been using.

MSM: You spend a lot of time around computers in Michigan?

Weinberger: Yes.

MSM: Because Michigan had a computer environment.

Weinberger: For an academic computer center, they had a first class place. It was very innovative. They had their own operating system, which was not a bad operating system. Like all home grown operating systems, it had these places with just appalling weakness, but usually users don't notice them...just like our home grown operating system. They had quite a good computer setup and it was all interactive. I'd been doing a fair amount of computing. My advisor D.H. Schlamer did...does...did...does a lot of computing.

MSM: He was one of the first to suggest using computers.

Weinberger: He started using them as soon as you could get on them...which is of course about '46. And kept using them quite productively....very ingenious things. Built special purpose fiber and all sorts of stuff. So I was pretty much into believing that they were useful and certainly in straightforward number theory. You could use them for experiments, which was quite convenient. You could use them to find numbers which...the world of mathematics is a very peculiar world. It's essentially a human creation but it's pretty clearly somehow there. So the experiments you do with computers in mathematics are the investigation you do using computers aren't...it isn't like the simulations weather people which is just a model. That's reality. It's the one case where you're actually at reality. Hugh Montgomery and I, for instance, wrote a paper where we did substantial calculation. I did the substantial calculation and he did the substantial mathematics and found some numbers that were unnaturally close. There were zeroes of some L function...all that sort of number theories. They were unnaturally close. It turned out this pair of unnaturally close numbers could be used to...you did a whole bunch of estimates and stuff like that and...and they could be used to cover a range from something like 10 to the 400th or 10 to the 2500 of cases in some other problem. So in this peculiar business of sort of missing...ontological gap which is the normal situation in modeling when you computers in mathematics. That's right. The things you discover are there. They're not just hypothetically there. You don't have to pretend the model is the reality, you know....

MSM: You have somebody reading them...reading Introduction to Minsky's in 1969 book on mathematics and computation, finite machines, he talks in the beginning there about that, the difference between the computer as a machine and ??????????, one's a model and the other is...

Weinberger: Yeah, but see, in mathematics there are at least...if you're...there are cases where there is no difference in mathematics. What you tell the machine to do it's not doing it on the model it's doing it on the mathematical reality. There's no gap. Which, I think, makes it very appealing. And one of the...there's a difference between a computer program and a theorem, which some people...I think is a fundamental difference, at least to me. Which is that 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. You could do something you couldn't do before. And I think people are attracted to different...in different...to these kinds of things. I've always found thinking a lot of work. And anything you can get the computer to do that's not what you would call thinking. But I've always found it hard to get things right. And once the program is working, it's working and if it can do different forms of the calculation for you, it's not just that it's faster, it's also more accurate than doing them over and over by hand, when you can get it to do it. So I've always been pushed in that direction...by myself...by my weaknesses...

MSM: One of the things I've noticed...

Weinberger: It's going to take us away from UNIX but that's okay. We can get back. As long as your tape holds out.

MSM: One interesting thing about discussions among numerical analysts, Wilkinson...Forsythe...toward the end of the '60's, is a concern that this marvelous tool for numerical analysis was, as it were, luring away good numerical analysts into what the authors was referring to as computerology. That is, they started off using the machine to do computations, but then they were getting interested in the machine itself. Is that happening among number theory?

Weinberger: I think it happened to some extent among...I think it's a...I don't know. I don't really have an answer to that. There is...

MSM: Did Lehmer ever complain about that?

Weinberger: No. Lehmer...Lehmer...Lehmer had a lot of strong views and as long as you weren't just completely out of touch on logic he didn't care what your views were either. No, I don't think Lehmer complained about that. I think Lehmer was amused by whatever, you know...whatever people did amused Lehmer. But he wouldn't take money from the government. Which I used to sort of wonder about and now I don't think it was a position of principle, I think it was pragmatically valuable. It's too much trouble to deal with the government if you can get by. But lots of people can't get by.

MSM: I've had government funding and had private foundation funding, and believe me, the second is a lot easier.

Weinberger: Yeah, absolutely. But there is a...something very seductive about hacking on the computer. Whatever it is. I'm sure it's different for different people. And that distracts people who...also computing in theoretical computer science and computing in general is another place where mathematically good people could go. And as long as it looks like the rewards are much greater people steer themselves in that direction. I think that...the fascination of programming is only part of that. So, yeah, I think...on the other hand it leads to a lot of...it's not clear what you ought to learn in the computer science education that's going to be of any particular value in 5 or 10 years.

MSM: One of the chapters...search in the '60's for what computer science was a science of.

Weinberger: I think that's well worth it. Especially since I don't think the answers are at all clear now.

MSM: They're not clear yet.

Weinberger: That's right. The optimistic way of looking at business, like saying 'well, it's like mathematics was at this point. Nobody was quite sure what the real subject was.' The other point of view is that we're just totally, you know...it's just totally wrong and it's just totally badly organized and we will discover where the subject we think we're studying doesn't...isn't there. And that it's actually some other set of subjects. It just breaks up some other way. Who knows? It's not predetermined. It's just that things may work out that there's a different division. Now, that's not easy because the way subjects develop is, you know, 'why is there a subject like this', 'well, because it's very much the way it was yesterday.' It's a historical development. So probably computer science will look a lot like computer science does. But I'm not sure it ought. I'm not sure what they're teaching is what they ought to be teaching. I don't have any...I'm sure if people thought of better things to teach, they'd teach them. I'm very uncomfortable with the state of computing as computer science education. And it's not just the subject matter. However, this is irrelevant for your book but while I'm talking, I'll talk. Push me back to whatever subject you want to talk about.

MSM: No, I've got a couple of books on the fire. So keep talking.

Weinberger: Okay. The problem I have with computer science education is I think that graduate students are...this is, of course, unfair to condemn them all. But on average lazy. Compared to say the graduate students in...biochemistry, which is a hard science that's moving fast and competitive. And computing science is a something science that's moving fast and potentially competitive. But I think there's just a significant difference in attitude. And part of it is, this is of course all conjecture, part of it is that the students feel they have it made because they're in this leading field. But part of it is that the standards of rigor aren't very high. If you're a biochemist you have an idea about what it takes to do an experiment that's publishable...about what the science of biochemistry is. And if you're a computer scientist I don't know how the hell you'd ever figure that out.

MSM: Hopcroft goes after that in his Turing Award lecture. He points out that the advantage that a new field like molecular biology has is that it's got very strong disciplines behind it. It's clearly an amalgam of the two. So when a graduate student comes in and wants to do molecular biology, 'you have to know this, you have to know this' and 'the courses are fair' and 'if you don't know this you can't do the field'...

Weinberger: But it's also clear what constitutes research. Or how you tell the difference between good research and bad research.

MSM: Yeah, because the problems are clear. And...

Weinberger: I really don't know. In some sense, of course, because the problems are clearer. But I don't understand the real difference. But there's a real difference. I just don't know how to articulate it.

MSM: Let me pick up and take it just a slightly different direction. Because one of the things that struck me about UNIX as a system, but also about the environment in which it has grown up, is that on the one hand there's a lot of very clever computing going on and yet so much of it seems to be, if not theory driven, at least an exploration of theory. You turn around and look at this feature and there's a theoretical paper behind it. You look at this feature and there's a theoretical paper. So there's a discipline behind you that...might be surprising. I think that's the way to which it's a hack....

Weinberger: I think that's very interesting. I think it's true. (phone rings) (phone rings) It's clear that the most powerful pieces of it have that property and that many of the pieces, even where there's no clear theoretical piece behind them, have sort of...the next best cousin in programming language, designer stuff like that. But there's a lot of...there certainly was in the past, a lot of push towards solving the whole problem. Not that the program solved the whole problem. UNIX is famous for this theory that it's best to do 80% because the last 20% is way too hard. But if there were a big piece you could chop off then you did it. And that's why you get general regular expressions instead of some other version. Or all those other things that come to mind. But I think regular expressions is clearly the most...the single thing that distinguishes the UNIX way from other ways, the MS DOS way and many others. Yes I think the compromises that are made are made somewhere else. Not made in these places where there are strong algorithms. They don't seem to put that sort of stuff in. Because there's also a somewhat minimalist tendency, which of course has affected the user interface too.

MSM: Yes. What led me to that was being exposed to a particular computer science curriculum, which is very much a Bell Labs, I think...influenced partly because the people involved in this seem to have a Princeton connection, only that as one moved through the introduction of programming systems, which in my year was taught by Peter Honeyman, worked on UNIX and one worked ones way up through to theory of computation, theory of automata...one was reading Aho, Hopcroft, and Ullman. There was a sequence where one began with very practical programming problems...and when in doubt...seeing a body of theory and the connection between the two. Which seemed to me the right way to go about it, if one could do a little better job of articulating it than they were doing...but still it was....

Weinberger: I think the other tendency has been a feeling, this is not a dominant tendency, but there's definitely been a tendency is, if you don't know how to do it right, just don't bother in the UNIX development. And I think that's one of the things that leads you...leads one to choose things that are backed by theory.

MSM: That's an ethos, it seems to me.

Weinberger: I think that's right.

MSM: How is it, I don't want to use the word 'enforced', but clearly it was something that you had to acquire when you got here. You acquired when you came into research. Do you have any sense on how that happened? If we can answer....

Weinberger: That's extremely hard to answer. I'll have to think about that. Let me put it this way. I think I was more receptive to it. I don't know how I acquired it and I don't know when I got it and all that sort of stuff. But this business...this point of view that the computer would do my work for me is a very absolutist point of view. Because I have this feeling I make mistakes, everybody makes mistakes, I also have this feeling that you never want to have to touch the programs. So it's important to do it right early and that it always be okay. So it always has to be...it's not just a problem of the minute, although one writes a lot of code that's got to do the problem of the minute, it's got to fill the niche permanently, which is completely unrealistic but it's certainly an attitude. And I think that matches this other. If it's just going to be a slipshod temporary hacked up way of doing it it's just not going to work long enough. And you're going to just have to come back and do it again and it's just too much like work. Not that reality actually matches this in any way but I think that's the attitude. I think that makes it easier to pick up that ethos.

MSM: When you talk to one another about stuff you're doing do the questions tend to drift back to what lies behind the code? What theory are you applying here, what makes this solution general? Can you verify this for me?

Weinberger: Verify it for you....

MSM: You show somebody something and say that's pretty neat but can you show me how it's going to work?

Weinberger: I don't think so. I don't think that's the way that works. My impression is that what happens when people talk about their work.... They explain the theoretical backdrop and all the problems and how they work it out and stuff like that. But...the effect of the sort of...external face of the work is that it's general and does a lot. And frequently people are surprised and disappointed, surprised and pleased, whatever by...things. For instance, the well-known UNIX regular expression stuff is not at all uniform. There's this business about back referencing. Sometimes you can say...later in the pattern, you take apart that matched in the first. It's got to be there again. That sort of stuff. Okay. And some of the pattern matchers do that stuff and some of them don't and people keep saying 'well how about this' or 'how about that?' And somebody has to point out that, well, if you put that in, the potential running time has just gone to unreasonable things. If you only use this class of regular expressions, then we can make the whole thing very fast, but if you use this class, then something else. So there's an awareness of the strengths and weaknesses of that stuff. And there's a sensitivity to the implications. And why...because the half...there's a problem with using theory based solutions. 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.

MSM: When you say weaknesses do you mean the theory tends to have longer run times?

Weinberger: No, I mean...well...The implicit claim for LR parsing...in fact it's an explicit theorem in LR parsing and turns into an implicit claim about LR parsers, is that they find an error at the first possible time. An LR parser does nothing once it comes to a symbol that cannot be illegal. It just can't beat them. Unfortunately that doesn't mean that an LR parser does that in any realistic sense. Because the parser doesn't see what you type out...the parser sees the output of some other program. It would just be endlessly confused. So people say you look at your buggy code and you say 'you could see right back there that is not a legal program'. Supervisor says 'yes that's right'. He says 'parser didn't notice until here'...'yes, that's right'... Well, but syntactically, without all this other stuff it was a legal program. The parser is just a little piece of it. There's a...the...when people give the talks that are backed by theory, of course you explain the theorems, and all the theorems...it's fairly typical, I think, of theorems in computing, is that there's a marketing piece to them which is that they.... (I guess it was not your thing clicking....) There's a marketing piece to them. People use terminology that makes their results sound more important. You end up hearing about, you know, absolutely invulnerable oracles. That turns out that just doesn't mean anything. And this LR parser theorem is another example. The theory is correct. The theorems are correct. But the implications aren't what they sound like. You learn...that's one of the annoyances. Now on the other hand, if you don't base it on theory, it's just chaos, you say 'well I can hack it'. We have programs which are not based on theory and some of our quite successful programs are not based on theory. The extremes in that are Mike Lesk's contribution, TBL, one of the more extreme.... Can I get TBL to do this and the answer was 'in 45 minutes'. He didn't say that literally but the true answer was in 45 minutes. And you say here's a bug in TBL and it's fixed in 45 minutes. But although that started with a model, Lesk's style, which he was extremely good at, was just to go in and hack it. The model got weaker and distorted and confused and 'well, listen the problem mostly works.' But my feeling about that code was, which I use all the time in the ways that I understand how it works, was...there's this joke about farmlands in New England and farmlands in Iowa, right. If you take a rock out of a farm in Iowa, you have some feeling it's the last rock. The farm in New England is nothing but rocks surrounded by water. So it is with bugs and these two styles of programs. If you have a theory based program you can believe you got the last bug out. If you have a hacked up program, all it is, is bugs. Surrounded by, you know, something that does something. You never get the last bug out. So we've got both kinds. And it's partly the style of the programmer. Both kinds are useful. But one kind's a lot easier to explain and understand even if it's not more useful.

MSM: The community tends to have a tolerance across the reach.

Weinberger: I think the community, sure.... There's some balance between any program that's sufficiently useful can have any number of bad effects...properties. But people prefer small, clean, easy to understand programs. But they will use big horrible grotesque disgusting buggy programs if they're sufficiently useful. And some will complain louder than others but it's a rare few who will say 'this is just so awful I won't use it.' We've got more of those few here than in many places.

MSM: Sandy Fraser was telling me the other day that the UNIX manual was the first one to explicitly to cite its bugs, in a open, honest fashion. Is that part of that?

Weinberger: That's interesting. I don't know who did that style. The oral history around here is that's essentially Doug's style. He may be right. There's a couple other things that happened here. It may not be true, of course. There's a couple other things that I think are related to that. Not necessarily having anything to do with Doug, and are possibly the consequences of the fact that we don't have to go out and get funding, which is that there's a tendency not to go out and talk outside about your work a lot until it's finished. As opposed to well before you start.

MSM: When you say go outside, do you mean go outside your own office?

Weinberger: No, I mean go outside your organization. And there's also a tendency not to talk too much formally inside the group about what you're working on until it's done informally. There's a lot of that. And I think that's part of this same kind of flavor...calling it intellectual honest would be a little pretentious but it's that same flavor of approach that leads to bug sections in the manual. Well, this stuff is good and bad and here's the good and here's the bad.

MSM: I've gotten the sense from several conversations, not the least of which with Doug himself, that the early versions he used the manual as a way of...sort of getting people to clean things up. Go through a new version of the manual...anybody go through your code and want to clean it up a little bit?

Weinberger: I'd like to be able to take it so you can explain it in a short amount of time. I think that's also one of the...a common feel that's common in computing. The story is if you read the documentation early, it's likely it'll be possible to explain what your program does, whereas if you wait until your program is completely finished, you may discover that however coherent it looked while you writing the various pieces, it's impossible to explain it.

MSM: There's a guy down in Holmdel that had on his door a sign that said documenting a software project is like changing a tire on a truck while it's moving.

Weinberger: That's a bigger scale than we do.

MSM: You came in then on AWK?

Weinberger: Yes.

MSM: How did you pick up your next mission.... I'm interested in how people pick up missions in this....

Weinberger: I'm not sure I remember. I know one of the things I worked on almost immediately is FORTRAN I/O library. Stu Feldman and I were sitting around talking and...FORTRAN 77 had just come out, and we had this idea that it would be easy to implement a FORTRAN compiler because we had all these great compiler tools. So we were talking about it and I said...I think this was probably while I was still in development, I started on this also...well, we talked about the parts that are hard. There's essentially two things that are real aggravation in FORTRAN. One is the lexical analysis. Once you've figured where the tokens are, it's not all that hard, 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. So we divided it up. He would write a compiler. I would write the I/O library. And we'd just get this done in almost no time at all. Well, the truth is that our compiler tools are not all that good. What we had fundamentally was lex and yacc, and that's a long way from a compiler. The other truth is that, in addition to figuring out where the pieces of the format statements are, there's quite a lot of work in an I/O library . But basically we just started this thing up and ran. Because it was the first UNIX FORTRAN compiler. It had quite a long life. So it was quite an embarrassment. Another example is it doesn't matter whether your stuff is good or bad, as long as you've filled the niche it'll be a long time before anybody else comes along and starts poking. When we got our Cray 3 or 4 years ago the first one was UNIX...on it. Somebody sat...was running perfect...they said, 'I'm getting these errors from FORTRAN. I don't understand them. Do you understand them? You run an I/O library, do you understand?' I said, 'No why would the I/O library have anything? They've got real FORTRAN.' But in fact they may have had real FORTRAN but they had my awful FORTRAN I/O library after all these years and I recognized the messages right away because it was still all my code. That's I think a story in favor of portability in writing in C, which is, by now, fairly well understood. After that it's fair to say I drifted a lot off and on. I did little things of one sort or another. And medium sized things, when I was interested. But it was stuff I thought of myself. I said this would be interesting to do and on my recollection, is that weeks or months would pass while I would be sort of trying things out that weren't working out. And then something I'd do would work out. That would be nice. Get me a raise. So it was very...structured.

MSM: Have you had any continuing themes that you've been pursuing?

Weinberger: Well you sort of end up working on stuff that you've turned out to be good at in the past. No, for a while there was. But no, I don't think so. The answer is there's stuff that I had done that I've sort of stopped doing. There'd be sequences of things, network file systems, servers, and that's still something I think about. But I'm less and less comfortable about doing kernel work. It's gotten more complicated and secondly you have to keep a lot in your head at once and I'm getting interrupted more now. It's hard to debug. So I don't do that much anymore. The research kernel has gotten a lot less modular, despite serious efforts to make it more modular, which of course have just...it's like releasing less carbon dioxide. It's not less carbon dioxide it's just not as much more. So there have been improvements in places but the general tent has not been very satisfactory. It's gotten much more complicated. So I don't know. The stuff I work on, there's always some, some...it's right around the system interface. I'm not sure there's too much more to it than that. My idea of an application program is a compiler. It'd be nice to move up a little from that. But I think I'd write some actual useful code. That's all I can think of that's been constant.

MSM: The prompt is as I was talking with Ken and listening to him talk and thinking of this Turing Award lecture, and so on...this continuing theme of self-replicating code, referencing systems which seem to reflect itself here, and reflect itself there, and the theme he came back to, and I was wondering if you have a theme like that you find yourself coming back to?

Weinberger: No. I'm not sure I would have characterized Ken that way either. There are things he really does keep coming back...file systems, and so forth. That's always been...that's how UNIX started, right, the point was...and he kept rewriting them and now he's just rewritten another one. Another batch. I can't think of...I'm not sure...I mean, that may be...I don't know.

MSM: What happened to the mathematician?

Weinberger: Well, what happened to the mathematician, the mathematician is still sort of there but it's hard to keep up. Keeping up with a single field of mathematics is essentially full time. And so it decays. What it is now is I have a really good education for computer scientists. And it's quite useful. It was interesting. Hopcroft came by a couple of years ago...I think it was Hopcroft. And when he was just starting in robotics and explained all this stuff that people ought to be learning in computer science...'this is the wave of the future' and it was all this stuff I had learned in the first year of graduate school at Berkeley in mathematics, right? It may have been new to him but it was just classical mathematics - period. So a lot of that stuff's good for a long time. What the mathematicians talk about in shifts. I can't read the fancy physics books because that's the kind of mathematics I...slowly it all shifts...(tape cuts)...I wrote math papers for a few years after I got here. The last one was probably 5 years out or something. But it's just...you have to be a scholar to write a research paper in mathematics. You have to be up on the field. It's just too hard.

MSM: Now you say you joined Development and you pointed back and it was behind the building.

Weinberger: Yes. There was a building back there.

MSM: That doesn't exist anymore?

Weinberger: Well that particular Development organization isn't there anymore. But yeah, maybe, yeah they moved somewhere else, but yeah, they're still around. Doing quite different things as you would expect after 15 years.

MSM: Were they where the analytic computing group was? When I first visited Bell Labs it was a fellow named Charlie Stenard.

Weinberger: Yes I think so. That's right. I was in Building 5. It was a weird building up there. Yes it was. I knew Jim Downs. He was a peculiar person in many ways. Frequently I couldn't figure out what he was talking about. But he had very enlightened personnel policies. If his people wanted to try something out, he would support them. Which is nice because frequently they're fairly hard to replace. It was nice.

MSM: How easy was it to make the shift? You said...again I'm interested in certain managerial structures. While you over here you found something?

Weinberger: No, there's more to it than that. I had tried to get a job here several years before. They come around and since I was a mathematician, Stan Brown had brought me in and they were working on ALTRAN in those days and I gave a talk on computer algebra. And I talked to Steve Johnson, all those people, and Sam Morgan wasn't hiring...no more mathematicians. Sam had in retrospect had this job of rebuilding this place or keeping it alive after the Multics thing. And there was a whole collection years right around there where they essentially hired nobody. As recently as the early '80's the place was 20 people. Well 20 was low, but 25. So he had already said no to me once. But I was doing this stuff with Al and Brian who, in retrospect, clearly were very hot properties. And they obviously thought this was a good deal. So we talked about it informally and then started trying to do it. And I guess they talked Sam into it. I don't know anything about it. It was, I think, probably a non- trivial effort on their part or on Doug's part, who was the department head...on somebody's part...probably did a lot of work which I didn't notice at all. Just dropping in on Al was the...yeah, I just came over, and I probably made an appointment and came over and explained my thing. It developed into this other stuff.

MSM: He was talking with Sam next week but you say he wasn't hiring any more mathematicians, and are there splits?....

Weinberger: No, I didn't mean it was just mathematicians. My feeling is that Sam was not much interested in taking chances...in people it was clear would succeed...given his druthers. And he may also have had feelings about the project that people were likely to work on. In my case there was no telling at that point about whether or not I was going to be good at anything else.

MSM: So in '76, '77, there was still fallout?

Weinberger: No, the first time I had tried to come over was probably '73 or '74. '73 probably. There was still fallout. This is in retrospect, I don't know what the actual situation with Sam was...Sam will have a much clearer idea of what the actual situation was than I do.

MSM: I have a feeling I'm going to get a sort of...you know the story of probably apocryphal ...Sir Walter Raleigh, while in the tower, decided to sit down and write a history of the world. Just get his story down. So he was up there writing this story and there was a scuffle in the courtyard down below, so he went down at mealtime and tried to find out what it was about and talked to a lot of people. Got so many different accounts he went upstairs and ripped up his history.

Weinberger: Well, but all of us are...all of us just remember what we remember. I...

MSM: But also there's a question of what people were seeing from different vantage points.

Weinberger: Yes. I understand. Even if we remembered exactly you'd get different stories. Sure. I wouldn't be surprised if you got a lot of stuff out of Sam. I expect the environment was much more complicated than it looked to young beginning technical people...political environment.

MSM: Well, it also says something about the way....

Weinberger: Oh yes. Sure.

MSM: Shield people from what they don't need to know.... Did you find when you came it was positive?

Weinberger: Oh yes. Sure. I found it quite interesting. As with all these things there are some people you work well with, there are some people you don't work well with...but you talk to. Some people you hardly ever talk to. I think I was here two years before I understood anything Ken said. Because if you ask Ken a question, he sort of gives you a one line answer to the question he thinks you ought to have asked approximately. I don't know what he thinks he's doing. But that's certainly what it seemed to be like he was doing. And you have to know a lot to understand a one line answer to these things. And after a while the answers become extremely informative. But it really took a long time before I just understood anything Ken was saying. That was pretty funny.

MSM: Did you pick a mentor in the group?

Weinberger: No. My guess is if I did that I'd have been more organized probably. More would have gotten done or it all would have been more structured. But I was used to as a mathematician used to working alone. Although there were a fair number of joint publications, it was.... And the style here, not universally, but to a large extent, is even when people are working on the same things they work on different pieces of it. Partly that's because of the little funny schedules. If I'm working on something with, say Dennis, I get in at 7:30 in the morning and work till about just after Dennis shows up and then I go home. Then Dennis comes in and works. You've just got to have some way of not stomping all over it. The most remarkable example of that is Ken and Dennis doing UNIX, where apparently there was only one time they even considered writing the same code. When they wrote it, it was line for line the same code.

MSM: Yeah, I heard about that.

Weinberger: I believe that story.

MSM: It was, character for character, a match of assembly code.

Weinberger: Well, it was the right way to do it, I guess. So, there's a lot that sort of...I think that's part of it too. People talk about what they're doing. But they sit and write code not always...until recently and somewhere else. I have not seen people sit at the terminal and one person type while both of them were writing the program. You just don't see much of that around here. And it's a perfectly reasonable way to work, especially in complicated code. And occasionally here it happens a little bit. But it could happen much more systematically. That's just one of the things that doesn't happen here. Here it only happens for little pieces of a program where you're having some particular trouble, as opposed to, essentially, the whole program.

MSM: This is a part of its history. Where do you think UNIX is going to go?

Weinberger: That's actually quite easy up to a point. I think it's going to be completely dominant, in spirit at least. In part of the spirit. And you can see that in MS DOS or...where all this stuff....

MSM: All those years you knew DOS....

Weinberger: Well, unfortunately, not quite because it's such a botch. But yeah, that's right. All the stuff that was in original MS DOS and of the stuff they've added to DOS, a huge fraction of it, you know, 80% of it, is UNIX-like stuff. And the...open...all this open...all this standard stuff...standard to conform, and it's in POSEX and all that sort of stuff is UNIX stuff. And if you're building an innovative computer, unless you're extremely weird, it's just inconceivable to spend a lot of time building all the aspects of an operating system. So you take UNIX in one of its variants and put it on. So at that level, it's like FORTRAN. We're going to have a lot of the features of the UNIX interface forever.

MSM: I'm going to interrupt you for a second. Because there is another model entirely. You were talking about it when I came in, by the coffee machine....

Weinberger: Right. That's the Apple model in some sense. And we're going to see combinations of those. That's for the user interfaces. But the underlying system stuff, what that runs on top of, is going to be UNIX. Because, roughly speaking, that part of it they got right. And this other part of it, the UNIX people got right, and you're just going to have them both. It's a very...now...that is when you sit down and turn the thing on, right, we've got Windows, right, mice, and menus and all that stuff.

MSM: Also got command lines.

Weinberger: That's right. We've also got command lines. But you can chop way back on that. I can write an interface to this, with a modest amount of work, where one got most of your days work done. And the last command you typed, where you wouldn't type very many commands, it's not very hard, actually, to decide how much of that you want to do. The AT&T open look interface has a lot more of that. All this stuff that I find so easy just to type comes on these elaborate collections of menus. If you've never typed...if you've typed hardly anything. But the Macintosh interface and the Xerox interface did actually have a lot of typing. You didn't type commands but the stupid systems always want to talk to you. They always want another wretched file name and you never get to say "star dot c 2 dot". Do this a million times on all the dot c files which is something that UNIX is really quite good at. You get to type a lot of stuff over and over again. I think there will be some balance which is probably isn't close to it being achieved. Because interfaces need to be smarter.

MSM: Because when I got my next coffee cup...for looking at the demonstration...they had introduced the machine. They talked about this was going to be UNIX but with a friendly interface. And I said to the guy 'well, when I think of UNIX and I think of friendly, I think of pipes and macros. Now, are you telling me I can pile up icons in a pipeline' and he said 'no, we don't have to do that ,but you can open a command window'. I said 'I can do that in DOS.' It was part of making myself friendly.

Weinberger: The hell with them. They're all so self-satisfied. I don't like vendors.

MSM: Ron knows. He came in with his lowest common denominator thinking they were showing the next interface. But again I stopped him. I said 'wait a minute...you're hooking messages of the objects. Where did the objects come from? You're telling me that all the applications for this have been written in Objective C?' He said yes. I turned to our graphics person and he said 'now, that's raising the lowest common denominator.'

Weinberger: It certainly is. And Objective C's the wrong solution also.

MSM: Yes. But you've got faculty members who are scared by BASIC, you're not going to get them like to Objective C and you're not going to start them maintaining university status. Objective C codes....

Weinberger: No I think that's right.

MSM: Not the scholars working.

Weinberger: No I think that's exactly right. I don't know what to do about that stuff but that's not it. So the rest of the UNIX story and I think, to some extent, all these other stories is that the commercial products, by the standards we're used to, are pretty crappy. They're, for all the reasons that commercial products deviate from esthetic ideals of one sort or another, right...they've got to get them out. You've got to get them out on time. You've got to build them. They're not allowed this 'well, I don't know how to do it', 'well, so let's not do it' attitude that we can indulge in. They've got to do it. They have no choice. It you don't know how to do it, well, you do it in a bad way. Then the bad way has some feature and some customer uses the feature and you can never get rid of the loathsome thing. It's all awful. And the commercial systems show every sign of that. They have the standards we use. They're appalling. And they make UNIX more and more like other commercial operating systems, because in fact the same effects are in all of them and they get bigger and harder to maintain and grottier and the manuals become outrageous, badly written, and all that sort of stuff. My only feeling about that...I have two feelings about that. One is it's inevitable. It could be a little better or little worse, but it's inevitable. And if it's gonna...I'd rather complain about what they've done with our work than have to put up with somebody else's work. So, it's relatively easy to complain about this and that but my view is that it's much better than it would be if...without it. Much better. The piece of the promise that does work...as you go out and buy equipment from lots of people, and you run it and the environment is fairly similar and fairly familiar and in fact it's so familiar and so similar, you complain a lot about the differences, instead of having to fight your way through a whole collection of new things. So I think permanent is too long, but I think it's here for a long time. I think we're going to be real sick and tired of it after a while. Just sick and tired.

MSM: It's a program, it's a file system, it's a programming environment. Did you hear about it as a software development environment?

Weinberger: No but I think that's what it is basically.

MSM: You think it's already industrial strength?

Weinberger: Well I don't know what industrial strength means, of course.

MSM: All you have to do is take the software cycle. Can one do requirements now as a specification, formal specification, tools, etc.?

Weinberger: One can do all those things. If they're being done, I assume they're done on UNIX systems. I think many of those things are operating system independent. The...it's true that the standard system doesn't come with some of the tools that some people want. I'm skeptical about a certain amount of that stuff. The real world suffers from a lot of, sort of, wretched, grotty problems. Everybody says 'no we don't want to mix languages.' There's always a little something weird. Not much but a little something weird so it has to be capable. And old code...you don't get to start over. And so a lot of the systems that ought to work, a lot of the things people write about as if they ought to work, they work real well if you write in one language and start over each time. Or at least they have a chance of working well if you write them one liners. But anybody can write software if you start over each time. It's this living with the past that's so hard. I'm moderately skeptical about a lot of this stuff. It's clear some people do software projects better than other people, but I'm not sure formal requirements is a piece of it. The people who seem to do the best are the people who are doing pretty much what they did the last time.

MSM: And starting from scratch?

Weinberger: No, not necessarily starting from scratch, but sometimes starting from scratch. As long as you don't get too ambitious and step on second systems and stuff like that. If software development environments means things, you know, like structured language, sensitive editors and stuff, incremental...incremental somethings and all that sort of stuff then no, we don't have a lot of that stuff. But I would much rather have general purpose editors and very fast compilers...and not have to worry about all this incredible crap that you otherwise have to build to keep your life straight. I think for instance C++, which is going to end up being a big step in that direction. I think C++ will be very popular, probably partly for the wrong reasons. Partly there are things I wish it didn't do, and so on and so forth. But I think this is tendency, okay. As machines are getting faster and faster and faster, the research community is usually big on...techniques for utilizing machines which have rates of growth that are much faster than the cycles are becoming available. Just impossible horrible things. C++ is less efficient than C if you use it in a natural way. But it's not so much less efficient that it's not going to pay off. This is where...instead of where all the...Xerox PARC is another example of this. They have these ALTOS which are slow and creaky and wonderful. Just, nobody's seen anything like it. They moved to...through a state of thing to DERADOS, which were damn fast machines and the damn machines were no faster than their other machines. The reason was that their software had been very greedy. They were going to do everything the right way. And it was incredibly expensive. All these cycles pissed away on the internal esthetics of the program, you know, layering and abstractions and all that stuff which everybody believes in but which can cost. And if you go to functional programming languages, you know, all that sort of stuff dynamic this and small talk that and all that sort of stuff, that stuff just eats the cycles like crazy. You end up with systems that don't work any better than the last systems except that they have lots more software in them and slightly fancier interfaces. And I think C++ is going to be a good compromise. Sure, it's going to be less efficient than C. You could probably make it the equivalent C++ program, written using all the features, half the speed of the C program. Well, that's a factor we can afford. Especially since not everybody's going to pay it. The 10% and 30%'s we can easily afford those if it really means the code is reusable where you can get the programs written faster. So I think it's going to be a big win.

MSM: That's interesting because, again at the next demonstration, one of the stunning figures was what percent...at the time you hadn't loaded how many megabytes on board those operating systems just to get those graphics. And I thought back to the original MAC which was so damn slow because it was all interface.

Weinberger: Yes, that's right. Well, is it worth it? Well, people differ. But if you keep it under control, and it's not clear in advance, whether you're keeping it under control. I think Ax is an example. There's this unbelievable pile of Ax crap. On the other hand if you don't use it all but only use some of it, Ax is reasonably fast. Much to my surprise. Of course they've re- written it several times and made it's standards very complicated so it can be fast. But they succeeded. There's always this question of do you take the functions you want and then learn how to make them fast or do you just try to make it fast from the start? And sometimes one, and sometimes the other seems to be the right answer. It's hard to be general about that. That's why software engineering is in such a terrible state. Civil engineering would be in a terrible state if all the properties...the physical properties and materials we used were changing at an exponential rate. How the hell would you ever learn to do engineering?

MSM: Yes, if you think you have trouble with computer science curriculums, the newest I triple E computer has suggestions for a software engineering curriculum. Any new curriculum....

Weinberger: Yeah right. I can't imagine what that can teach.

MSM: Essentially courses based on the cycle....

Weinberger: The only way you can get people to do that is you insist they go out and do it in groups and watch what happens. At least then they'd have some practical experience. Because the rules of thumb are just pointless.