: Coders at Work: Reflections on the craft of programming

Ken Thompson

Ken Thompson

Ken Thompson is the original bearded Unix hacker. He has spent a career working on whatever he finds interesting, which has, at various times, included analog computing, systems programming, regular expressions, and computer chess.

Hired as a researcher at Bell Labs to work on the MULTICS project, after Bell Labs pulled out of MULTICS, Thompson went on, with Dennis Ritchie, to invent Unix, an endeavor for which he fully expected to be fired. He also invented the B programming language, the precursor to Dennis Ritchies C.

Later he got interested in computer chess, building Belle, the first special-purpose chess computer and the strongest computerized chess player of its time. He also helped expand chess endgame tablebases to cover all four- and five-piece endgames.

When working on Bell Labs Plan 9 operating system, he devised the now ubiquitous UTF-8 Unicode encoding.

In 1983, Thompson and Ritchie received the Turing Award for their development of generic operating systems theory and specifically for the implementation of the Unix operating system. He was also awarded the National Medal of Technology and the Institute of Electrical and Electronics Engineers Tsutomu Kanai Award, both for his work on Unix.

In this interview he talked about his early love of electronics, a rather unorthodox academic career that had him teaching courses while he was still a student, and why modern programming scares him.

Seibel: How did you learn to program?

Thompson: I was always fascinated with logic and even in grade school Id work on arithmetic problems in binary, stuff like that. Just because I was fascinated.

Seibel: Did you turn them in that way?

Thompson: No, no. But I worked out the algorithms for adding in different bases, what carry means, and what each column means and things like that. Then I had a little calculator, a decimal calculator. It was like a decimal abacus. Instead of one and two it had a slide from zero to nine. It had a subtract one from a previous column down and an add one from the previous column up. So youd put a stylus in, like a four, and run it up and hook over if you want to carry. And I built some binary stuff based on that and how that generalized to n-ary.

Seibel: Where did you even get that notion of binary arithmetic?

Thompson: In the class at the time I actually started doing this, they introduced binary.

Seibel: Were you a victim of the new math?

Thompson: No, no. I was victim of bad math. I moved every year or so and I was in some really, really horrible schools and then some good schools. So I would have to do two years of work in one year and then Id be off a year. I was just loafing through math, so I had a horrible math primary education. And this one class they just described binary arithmetic. I took that and extended it to any base and played with that. So thats kind of where I got started.

Seibel: And that was in grade school?

Thompson: Yeah, seventh grade. Then around senior year in high school, somewhere around in that time, I was into electronics a lot, building radios and amplifiers and oscillators and theremins. And I got hooked on analog computing. It was really marvelous. Electronics was my passion during all that time. I went into double E at Berkeley, and there I saw real digital computers for the first time in my junior year.

Seibel: And so what year would that have been?

Thompson: I went to junior semester early, so it was three semesters in. I started school in September 60, so it would be the fall or spring of 62. They had an analog computer which I had a great time with. And they had a G15, a drum computer. They had one lab class on it and then it was open. Anybody could play with it, but no one did, so it was free. And I used it essentially exclusively. I wrote programs on it, on my own, to scale an analog computeranalog computing is almost all scaling.

Seibel: Scaling in the sense of?

Thompson: Time scaling and amplitude scaling. Basically what you do is you build it to do a function. You put some input in and then you get a function of that input out and you concatenate these things with feedback. And at every point in this process you cant go too high or youll clip.

Likewise theres time scalingyou halve the frequency at different places or double the frequency in different places. And when you do that, a bunch of the linear scaling changes also. So if you have a simple job that doesnt need scaling, analog is really great. But as soon as you need scaling it becomes very, very complex. And so I wrote digital computer programs to scale the analog computer setups. Without computing the actual wave forms, you compute the amplitude and frequency of the wave form at every point. And then it tells you when youre out of range for whatever operation youre doing at that time.

Seibel: And the programs on the digital computer were written in assembly or Fortran?

Thompson: They were assembly mostly. There was an interpreted language that turned out to be too slow. Thats why I was forced to go to assembly and actually learn what the computer was.

Seibel: So load in your program, hit the run button, and away you go. Was it using punch cards?

Thompson: No, no. It was a Flexowriter, which is like a Teletype and paper tape. And youd store it on paper tape and talk to it on the Flexowriter.

Seibel: Did they actually teach you assembly in that lab?

Thompson: Nah.

Seibel: What was your next exposure to programming?

Thompson: This G15 had an interpreter called Intercom 501. And the double-E class would program it in Intercom. There was a graduate student that I was friends with that wrote an interpreter for Intercom on the big IBM machine, the big campuswide computing facility. I got a listing of that and on vacation, Christmas or something, I read it and just dissected it. I didnt know the language it was written in. which happened to be NELIAC. And it was just a marvelously written program. And I learned programming, NELIAC, Intercom, and how to interpret somethingeverythingfrom that. I just sat and I read it for probably the entire vacation, a week. And then came back and asked him questions about it, nagging little bugs kinds of things. After that I knew how to program and I was pretty good at it. Then I got jobs programming.

I was basically working my way through school, work-study and then odd jobs. I was a research assistanta grunt for a graduate student to get programming done for his thesis. And I was a TA. I did programming for the computer center. Part of the computer-center stuff was to sit in a little booth and have people come in and say, I only changed one thing. Well, lets look at that one thing and see what happened to you.

Seibel: Did that hone your debugging skills or was it all just incredibly stupid stuff?

Thompson: It honed that type of debuggingyou understood common errors really well after that. Somebody who had spent days working on their program would come in and youd say, Right there!

Seibel: And your degree was in double E? Did they offer a computer science degree at that point?

Thompson: No, all over the United States at the time computer science was trying to come out, and it was coming out in two ways. It was coming out theoretically through math, or practically through double E. In Berkeley, computer science at that point was almost exclusively inside of electrical engineering. Math was trying, but they just werent politically astute enough to compete with these old grizzled guys.

Seibel: Berkeley obviously ended up being known for things like the Berkeley Systems Labbuilding thingsas opposed to being renowned for contributions to theory.

Thompson: Yes, absolutely. This is the genesis of either a theoretical computer-science department, like Cornell, or the Berkeley kind of computer science. It really gives the flavor to the place. So I spent one year in graduate school there, not because I had any ambitions for anything. Its just because I had nothing else to do and I was having a good time.

Seibel: Immediately after college?

Thompson: Yeah. To be honest, I was working at the university and I didnt even apply for graduate school. One of the professors essentially applied for me and told me I was in graduate school.

Seibel: Still in double E?

Thompson: Right. My senior year and my graduate year were just immense fun. I didnt do anything that I didnt want to do. There were no requirements, no nothing. To graduate I took a summer course in American history or something, some requirement, to get a degree. But outside of that, my senior year and my graduate year I taught about half of the courses I took.

The basic theory of computing was just coming out then. Shell sort came out and no one could figure out why it was faster than n-squared sort. And so everyone was doing tests on it and trying to figure outits pretty easy to see it sorts, but nobody knows why its fast. And they were taking the asymptote and figuring out why it was n to the 1.3 or something like that. And thats just not a natural number. And from thatshell sort and the intellectual attraction to shell sort and why it was fastcame all this speed order of computing. And the first n log ns and divide and conquer and all that struck. It was an amazing, exciting era.

I had friends, a bunch of these very junior professorsa math professor I was real close to, and a double-E professor I was close to, and the graduate student that I worked for, and others. They would invent a class for me, and then I would teach the class.

Seibel: Were you officially taking the class or were you actually on the books as teaching it?

Thompson: No, no, I wasnt on the books as teaching it. They were all double-E 199, which meant individual research or group research or something. And they would invent a class and give it a title and then turn it over to me. And thered be three or four students there.

Seibel: Of which, officially, you were one.

Thompson: Yes.

Seibel: Did you like teaching?

Thompson: To an extent. Ive gone back and taught twice. Taken a year off and taught one year at Berkeley in 7576 and one year in Sydney in 88. Its fun. I really, really enjoy it. I was doing research in the labs and I went to Berkeley to teach and to learn the classes I was teaching from the bottom up since I never had a computer-science education. A normal visiting teacher teaches one class. I taught five classes. Some classes I taught twice and I thought they were the best because the first year I was learning and the second time I taught it I knew where it was going and I could present it organized and be two steps ahead of the students. The third class was just boring. I taught one class three times and it was just wrong. So I could never be a teacher because you end up teaching your class over and over and over. I could never do that. But I love the teaching: the hard work of a first class, the fun of the second class. Then the misery of the third.

Seibel: What was the first interesting program you wrote?

Thompson: The first long computational program I wrote was solving the pentaminos problem. Do you know it?

Seibel: The tile game, right?

Thompson: Its a tile game. And I ran it on an IBM 1620 that was in the physics department. I knew where all the underground computers were in the place, and I had them all running at night doing my jobs. Plus, at the main computer center I probably had 20 accounts under different rocks. There are 12 pentaminos. These are different tile pieces made out of 5 squares. And there are 12 different such shapes.

Seibel: Sort of like Tetris tiles.

Thompson: Yes. But every piece has five squares. If you put them all together on the board there are two configurations that areI dont knowappealing. One is the most square, which is ten-by-six, and then the second is eight-by-eight with a two-by-two hole in the middle. And I solved all configurations of those two boards of how you place the pieces for those boards. And I did it generically by laying out a pattern of the boards and then laying out pattern pieces, and then it would fit the pieces in the patterns. It didnt know it was pentaminos.

Seibel: This was basically brute-force search?

Thompson: Brute force.

Seibel: And so this was also in assembly probably?

Thompson: I have to think. Yeah, it was probably assembly. I cant remember.

Seibel: You must have learned Fortran somewhere along the line.

Thompson: Yeah, well, I had to teach Fortran in the computer center and debug the Fortran programs. I never programmed in it. I wrote a Fortran compiler for Unix early, and B was an attempted Fortran compiler that got away from me.

Seibel: I thought B was your translation of BCPL.

Thompson: It sort of was. It started off asI didnt know what it was. Semantically, it turned out to be BCPL. As I started it, it was going to be Fortran. And at that point I got my first description of BCPL. And I liked the clean semantics. And thats when I abandoned Fortran and it turned into essentially C syntax and BCPL semantics.

Seibel: Is there any really big differences in how you think about programming or how you practice programming from when you learned to now? Do you feel like your programming has matured in some way or you got better at it or you learned things that make you look back and say, Oh, man, I didnt know what I was doing back then.?

Thompson: No, not really. Sometimes I look back at stuff I did and say, Wow. I was much better then. The period from when I spent that week reading that program to maybe when I was 30, 35 years old, I knew, in a deep sense, every line of code I ever wrote. Id write a program during the day, and at night Id sit there and walk through it line by line and find bugs. Id go back the next day and, sure enough, it would be wrong.

Seibel: Do you think when you were 35 you could still remember the stuff you had written a decade before?

Thompson: Yes. Then I started being selective about what Id remember.

Seibel: Is there anything you would have done differently about learning to program? Do you have any regrets about the sort of path you took or do you wish you had done anything earlier?

Thompson: Oh, sure, sure. In high school I wish Id taken typing. I suffer from poor typing yet today, but who knew. I didnt plan anything or do anything. I have no discipline. I did what I wanted to do next, period, all the time. If I had some foresight or planning or something, there are things, like typing, I would have done when I had the chance. I would have taken some deeper math because certainly Ive run across things where I have to get help for math. So yeah, there are little things like that. But if I went back and had to do it over Im sure that I just wouldnt have it in me to do anything differently. Basically I planned nothing and I just took the next step. And if I had to do it over again, Id just have taken the next step again.

Seibel: After school you got hired directly into the Bell Labs; how did that happen? It doesnt sound like you were a classical academic researcher at that point in your career.

Thompson: I just drifted. It was hard to describe. I certainly wasnt in school in any real sense. In the formal sense, yes, I was. One of my professors, who is actually a very good friend, sicced the Bell Labs recruiter on me. But I wasnt looking for a job. In fact, I had absolutely no ambitions; nothing. And he made me appointments to see him in his little recruiting booth, and I either slept through them or told him I wasnt interested. And he kept after me. At some point he called me and said that he wanted to come over and see me. So he came over to my apartment. And said that he wanted me to come out and interview at Bell Labs. I told him no. And he said, Its a free trip. You can do what you want to out there. And I say, Well, up front Ill just tell you that Im not interested in a job. Ill be glad to go for a free trip cause I have friends on the East Coast. Ill go visit them. And he says, Fine. So that was the interview that I got into. And I went and spent my two days at Bell Labs and then rented a car and went up and down the East Coast visiting my high-school friends that were spread out all over everywhere.

Seibel: Obviously there was something that the folks at Bell Labs saw in you and said, We should get this guy into our lab.

Thompson: I dont know their side of it. My side of it is that these are people that I was reading the papers of in the classes I was taking/teaching. And I knew them by name and reputation. And they were still doing fun things. To me, work was work and these guys werent working. They were having a good time. Just like school.

Seibel: And so what kind of things did you do when you first arrived there?

Thompson: Bell Labs was in the MULTICS project and I was hired in to work on MULTICS. And I did. I played with the machines, booted up MULTICS, and did my little piece of it. At some point, Bell Labs decided that MULTICS wasnt for them, and they backed out of the project.

But they had these MULTICS machines which were special-purpose machines that were just sitting around idle until someone could cart them away. So for approximately a year I had this machine that was monstrous. There are maybe two or three of us that used it. So I started doing operating-system stuff, trying to get a little operating system up and running.

It was insanely hard because it was a real complex computer. But I got it up where it would sit there and say hello on 50 Teletypes around the building. And then it went out the door. So I shopped around then and found some other unused machines and essentially built Unix on these very, very small PDP machines.

Seibel: Did you have the time to do that because your bosses knew that thats what you were doing and said this is a good research project, or was it just because you were in between jobs?

Thompson: No, I was sort of incorrigible, to be honest. I suspected that I would eventually get fired, but it didnt bother me. We were supposed to be doing basic research but there was some basic research we should be doing and some basic research we shouldnt be doing. And just coming out of the ashes of MULTICS, operating systems was one of those basic research things we shouldnt be doing. Because we tried it, it didnt work, it was a huge failure, it was expensive; lets drop it. So I kind of expected that for what I was doing I was going to eventually get fired. I didnt.

Seibel: How do you design software? Do you scribble on graph paper or fire up a UML tool or just start coding?

Thompson: Depends on how big it is. Most of the time, it sits in the back of my mindnothing on paperfor a period of time and Ill concentrate on the hard parts. The easy parts just fade awayjust write em down; theyll come right out of your fingertips when youre ready. But the hard parts Ill sit and let it germinate for a period of time, a month maybe. At some point pieces will start dropping out at the bottom and I can see the pyramid build up out of the pieces. When the pyramid gets high enough in my mind, then Ill start at the bottom.

Seibel: But youre not just building leavesyou know the structure theyre going to fit into.

Thompson: Suppose someone is describing something to me from postulates like, Heres a computer and here are the op codes. I can visualize the structure of programs and how things are efficient or inefficient based on those op codes, by seeing the bottom and imagining the hierarchy. And I can see the same thing with programs. If someone shows me library routines or basic bottom-level things, I can see how you can build that into different programs and whats missingthe kinds of programs that would still be hard to write. So I can envision that pyramid, and the problem is to try and decompose it and get the bottom pieces.

Modern programming scares me in many respects, where they will just build layer after layer after layer that does nothing except translate. It confuses me to read a program which you must read top-down. It says do something. And you go find something. And you read it and it says, do something else and you go find something and it says, do something else and it goes back to the top maybe. And nothing gets done. Its just relegating the problem to a deeper and deeper level. I cant keep it in my mindI cant understand it.

Seibel: So why not still read bottom-up? The leaves are there, somewhere.

Thompson: Well, you dont know what are leaves and what arent. If its well described you can read the English and get it and then you dont have to read the code. But if youre actually just given a bunch of code and told, Read it and try and make it better or try and make it do something else, then typically I read it top-down.

Seibel: Do you ever write down anything before you start writing code?

Thompson: I usually write down data structures before I write down code. I dont write down algorithmsno flowcharts, or stuff like that. But the stuff you have to refer to on almost every line of codedata structures.

Seibel: If youre writing a C program, does that mean C code that would define those data structures?

Thompson: No, little boxes with arrows and stuff.

Seibel: So youve got this big picture, the pyramid. How much do you stick to that plan once you start coding?

Thompson: I dont stick to code. If I find a different partitioning halfway through, Ill just hack and go over it. A lot of people I know, when they write a line of code, its concrete from then on for the rest of life, unless theres a bug. Especially if they write a routine with an API and scribble the API somewhere on an envelope or an API listthen thats it. Itll never change, no matter how bad it is. And Ive always been totally willing to hack things apart if I find a different way that fits better or a different partitioning. Ive never been a lover of existing code. Code by itself almost rots and its gotta be rewritten. Even when nothing has changed, for some reason it rots.

Seibel: How do you decide when code needs to be thrown away?

Thompson: When its hard to work on. I do it much quicker than most people do. Ill throw away code as soon I want to add something to it and I get the feeling that what I have to do to add it is too hard. Ill throw it away and start over and come up with a different partitioning that makes it easy to do whatever I wanted to do. Im really quick on the trigger for throwing stuff out.

Seibel: Is that true working with other peoples code as well?

Thompson: It depends on whether I have control. If I have control, sure, it doesnt matter. If I dont have control, its someone elses code, then Ill suffer. Or not do it.

Seibel: In the case where youve inherited someones code theres a danger in rewriting it that maybe you missed some subtlety to the way it works or overlooked some bit of functionality that it had. Have you ever been bitten by that?

Thompson: Well, you get bitten, but thats just part of debugging. If theres something you forgot or didnt do, when you realize it you do it. Thats just part of debugging. Its not complete when you first write something. You extend it.

Seibel: Once youve built a system, do you go back and document it in any way?

Thompson: It depends on what its for. If its for me, no I wont. Ill put in a usage line if I forget the arguments. And Ill put in a comment at the header about what the whole thing does. But very, very brief. If its part of a system or a library or something thats meant to be published, then Ill take the time to document it. But otherwise, no.

Documenting is an art as fine as programming. Its rare I find documentation at the level I like. Usually its much, much finer-grained than need be. It contains a bunch of irrelevancies and dangling references that assume knowledge not there. Documenting is very, very hard; its time-consuming. To do it right, youve got to do it like programming. Youve got to deconstruct it, put it together in nice ways, rewrite it when its wrong. People dont do that.

Also, I prefer bottom-up documentation and thats usually not the way its written. If some program relies on other programs or files or data structures, I like to see clear a reference to those where I can go off and read those and they dont refer back.

Seibel: So youd like to understand code the way you would like to write it, which is from the bottom up?

Thompson: Yeah. Its the way I can put a handle on it in my mind and remember. Otherwise I read it and I may understand it right after I read it but then its gone. If I understand the structure of it, then its part of me and Ill understand it.

Seibel: In your Turing Award talk you mentioned that if Dan Bobrow had been forced to use a PDP-11 instead of the more powerful PDP-10 he might have been receiving the award that day instead of you and Dennis Ritchie.

Thompson: I was just trying to say it was serendipitous.

Seibel: Do you think you benefited to being constrained by the less powerful machine?

Thompson: There was certainly a benefit that it was small and efficient. But I think that was the kind of code we wrote anyway. But it was more the fact that it was right at the cusp of a revolution of minicomputers. The 10 was the big mainframe run by the computer center. Computing going autonomous instead of centralized was, I think, the really serendipitous part of it. And that rode in on the PDP-11.

Seibel: Didnt Unix also benefit from being written in C while OSs like TENEX and ITS were written in assembly and couldnt jump to different hardware as easily as Unix?

Thompson: There were good system-programming languages that things were written in to some extent.

Seibel: Such as?

Thompson: NELIAC was a system-programming version of Algol 58.

Seibel: Was Bliss also from that era?

Thompson: Bliss I think was after. And their emphasis was trying to compile well. I think it was pretty clear from the beginning that you shouldnt kill yourself compiling well. You should do well but not really good. And the reason is that in the time it takes you to go from well to really good, Moores law has already surpassed you. You can pick up 10 percent but while youre picking up that 10 percent, computers have gotten twice as fast and maybe with some other stuff that matters more for optimization, like caches. I think its largely a waste of time to do really well. Its really hard; you generate as many bugs as you fix. You should stop, not take that extra 100 percent of time to do 10 percent of the work.

Seibel: Youve presumably heard of the essay, Worse Is Better by Richard Gabriel.

Thompson: No.

Seibel: He contrasted what he called the MIT style, where correctness trumps everything else, and the New Jersey (i.e., Bell Labs) style, where simplicity of implementation is highly valued. His theory was that the New Jersey style, which he also called Worse Is Better made it possible to get stuff out and running and from there it will get improved.

Thompson: I think MIT has always had an inferiority complex over Unix. I gave a Unix talk at MIT and I was introduced by Michael Dertouzos, I think. He expounded on why Unix wasnt written at MIT and why it should have been. Why they had the opportunity, they had the people, they had everything, and why it wasnt done there. And it dawned on me that there was a rivalry in their minds. Not in my mind at that point. We did Unix and they did MULTICS, which was this monster. This was just clearly the second-system syndrome.

Seibel: Where MULTICS was the second system after the MITs Compatible Time-Sharing System?

Thompson: Yes. So overdesigned and overbuilt and over everything. It was close to unusable. They still claim its a monstrous success, but it just clearly wasnt.

Seibel: My understanding was that a lot of the MIT hackers viewed MULTICS that same way. They preferred ITS and the Lisp-based systems that they built. It seems there was a real fork post-MULTICS. Unix came out, as you well know, and at MIT these Lisp guys went off and did their things on PDP-10s and built Lisp-based systems which, eventually I guess, begat the Lisp machines.

Thompson: Yeah, yeah. I knew all those guys. I thought it was a crazy job. I didnt think that Lisp was a unique enough language to warrant a machine. And I think I was proved right. All along I said, Youre crazy. The PDP-11s a great Lisp machine. The PDP-10s a great Lisp machine. Theres no need to build a Lisp machine thats not faster. There was just no reason to ever build a Lisp machine. It was kind of stupid.

Seibel: Are there any features of MULTICS that you did like but that never made it into Unix?

Thompson: The things that I liked enough to actually take were the hierarchical file system and the shella separate process that you can replace with some other process. Before that all systems had some sort of executivethat was the typical word for itwhich was a built-in processing language. Per-process execution. Every time you type to the shell and it creates a new process and runs whatever you typed and when that dies you come back so that youre at arms length from the thing youre running.

Seibel: So those are all things you did take; theres nothing you left behind that you now regret?

Thompson: No.

Seibel: From what Ive read about the history of Unix, it sounds like you used the design process that you described earlier. You thought about it for a while and then your wife and kid went away for a month and you said, Oh, greatnow I can write the code.

Thompson: Yeah. A group of us sat down and talked about a file system. There were about three or four of us. The only person whos not well known is a guy named Rudd Canady. In those days at Bell Labs the amenities were greatyou could call a telephone number and get a transcription. You know, leave a message and say you want it written up and itll appear the next day in your inbox as sheets of paper. And Canady, after we talked about the file system on the blackboard for a little while, picked up the phone, called a number, and read the blackboard into the phone.

It came back and it was about as close to a design document as we got except that it had homonyms that you wouldnt believe. So I went off and implemented this file system, strictly on a PDP-7. At some point I decided that I had to test it. So I wrote some load-generating stuff. But I was having trouble writing programs to drive the file system. You want something interactive.

Seibel: And you just wanted to play around with writing a file system? At that point you werent planning to write an OS?

Thompson: No, it was just a file system.

Seibel: So you basically wrote an OS so youd have a better environment to test your file system.

Thompson: Yes. Halfway through there that I realized it was a real timesharing system. I was writing the shell to drive the file system. And then I was writing a couple other programs that drove the file system. And right about there I said, All I need is an editor and Ive got an operating system.

Seibel: Whats the worst bug youve ever had to track down?

Thompson: Basically bugs where memory gets corrupted. It never happens anymore. I dont know why. But in the early days we were always working with experimental hardware of various sorts, and thered be some hardware bug.

Seibel: So memory would get corrupted by the hardware screwing up, not by a runaway pointer?

Thompson: It could be pointer. It could be hardware. Or a combination. The one Im actually thinking of, the worst example, was the on PDP-11. It didnt have multiply but you could buy a multiply unit and plug it in, but it was an I/O peripheral. You would store a numerator and a denominator and say go. Youd busy-loop and then pull out the answer, the quotient and the remainder. And this thing was built for a non-memory-managed PDP-11 and we got the first experimental hardware for a memory-managed PDP-11 and this multiply unit didnt fit with the memory management well.

So youd store into this thing and then youd busy-test. And during certain aspects of the busy test it would send a physical address down instead of a virtual address and some piece of memory would get clobbered with a numerator of what you were trying to divide by. And itd be ages before youd find it, and itd be different places. Thats by far the hardest one Id ever had to find.

Seibel: How did you track it down?

Thompson: There was a program that I wrote that was going after a world record for the number of digits of e. Previous world records were limited not by computationby cycles per secondbut by I/O. I came up with a new algorithm where it was computation-bound and I/O became trivial. It was monstrously heavy on multiply and divide. And we noticed that the machine just crumbled whenever I put on my program. And therefore we got the connection.

Seibel: So that gave you the clue that there was a problem with the multiplier; did you ultimately track it down to some root cause?

Thompson: At some point we got it to where you store in the multiplier in the multiply unit, and you pull it back and it wasnt there. We reported that to DEC and DEC couldnt find it, and they didnt want to deal with it. Their normal people didnt want to deal with this hybrid machine. In those days you actually got the circuit diagrams of the machines, and we actually found the bug in the circuit diagrams. Then we just called DEC and said, Connect that wire and that wire.

Seibel: So, thankfully, hardware mostly doesnt flake out on us that way these days.

Thompson: Yeah. Thats why I think theyre rare. Plus things are isolated from each other moreif you go bizarrely wild youll get a fault. Also you did it in assembly languageits really easy to have the wrong thing in some register through some subroutine call. When you have a high-level language where the arguments all have to match up, these things become more and more rare.

In the early days, in assembly language, youd find them a lot. If it was software, as opposed to a combination of software/hardware, usually it would happen in one spotthe same spot would be corrupted. Thered be some correlation of the bug with something. And you could sit there and put a monitor in the operating system. And every so often, or very often, youd check and see if the error occurred, and stop as quick as you can, and see whats going on elsewhere, and chase them down that way. So you could attack them.

This one you couldnt attack. It wasnt until I wrote this intensive multiply/divide program that it saw the frequency of the error went way, way up. Instead of crashing once every couple of days youd crash once every couple of minutes. And then as soon as you got something that would crash the machine you had a fighting chance to find it.

Seibel: So some folks today would say, Well, certainly assembly has all these opportunities to really corrupt memory through software bugs, but C is also more prone to that than some other languages. You can get pointers off into la-la land and you can walk past the ends of arrays. You dont find that at all problematic?

Thompson: No, you get around that with idioms in the language. Some people write fragile code and some people write very structurally sound code, and this is a condition of people. I think in almost any language you can write fragile code. My definition of fragile code is, suppose you want to add a featuregood code, theres one place where you add that feature and it fits; fragile code, youve got to touch ten places.

Seibel: So when theres a security breach that turns out to be due to a buffer overflow, what do you say to the criticism that C and C++ are partly responsiblethat if people would use a language that checked array bounds or had garbage collection, theyd avoid a lot of these kinds of problems?

Thompson: Bugs are bugs. You write code with bugs because you do. If its a safe language in the sense of run-time-safe, the operating system crashes instead of doing a buffer overflow in a way thats exploitable. The ping of death was the IP stack in the operating system. It seems to me that thered be more pings of death. There wouldnt be pings of take over the machine becoming superuser. Thered be pings of death.

Seibel: But there is a difference between a denial-of-service attack and an exploit where you get root and can then do whatever you want with the box.

Thompson: But there are two ways to get rootone is to overflow a buffer and the other is to talk the program into doing something it shouldnt do. And most of them are the latter, not overflowing a buffer. You can become root without overflowing any buffers. So your arguments just not on. All youve got to do is talk su into giving you a shellthe paths are all there without any run-time errors.

Seibel: OK. Leaving aside whether it results in a crash or an exploit or whatever elsethere is a class of bugs that happen in C, and C++ for the same reason, that wouldnt happen in, say, Java. So for certain kinds of applications, is the advantage that you get from allowing that class of bugs really worth the pain that it causes?

Thompson: I think that class is actually a minority of the problems. Certainly every time Ive written one of these non-compare subroutine calls, strcpy and stuff like that, I know that Im writing a bug. And I somehow take the economic decision of whether the bug is worth the extra arguments. Usually now I routinely write it out. But theres a semantic problem that if you truncate a string and you use the truncated string are you getting into another problem. The bug is still thereit just hasnt overflown the buffer.

Seibel: When youre debugging, what tools do you use?

Thompson: Mostly I just print values. When Im developing a program I do a tremendous amount of printing. And by the time I take out, or comment out, the prints it really is pretty solid. I rarely have to go back.

Seibel: And what kinds of things do you print out?

Thompson: Whatever I need; whatever is dragging along. Invariants. But mostly I just print while Im developing it. Thats how I debug it. I dont write programs from scratch. I take a program and modify it. Even a big program, Ill say main, left, right, print, hello. And well, hello isnt what I wanted out from this program. Whats the first thing I want out, and Ill write that and debug that part. Ill run a program 20 times an hour that Im developing, building up to it.

Seibel: You print out invariants; do you also use asserts that check invariants?

Thompson: Rarely. I convince myself its correct and then either comment out the prints or throw them away.

Seibel: So why is it easier for you to print that an invariant is true rather than just using assert to check it automatically?

Thompson: Because when you print you actually see what it is as opposed to it being a particular value, and you print a bunch of stuff that arent invariants. Its just the way that I do it. Im not proposing it as a paradigm. Its just what Ive always done.

Seibel: When we talked about how you design software, you described a bottom-up process. Do you build those bottom-up pieces in isolation?

Thompson: Sometimes I do.

Seibel: And do you write test scaffolds for testing your low-level functions?

Thompson: Yeah, very often I do that. It really depends on the program Im working on. If the program is a translator from A to B, Ill have a whole bunch of As lying around and the corresponding Bs. And Ill regress it by running in all the As and comparing it to all the Bs. A compiler or a translator or a regular-expression search. Something like that. But there are other kinds of programs that arent like that. Ive never been into testing much, and those kinds of programs Im kind of at a loss. Ill throw in some checks, but very often they dont last in the program or around the program because theyre too hard to maintain with the program. Mostly just regression tests.

Seibel: By things that are harder to test, you mean things like device drivers or networking protocols?

Thompson: Well, theyre run all the time when youre actually running an operating system.

Seibel: So you figure youll shake the bugs out that way?

Thompson: Oh, absolutely. I mean, whats better as a test of an operating system than people beating on it?

Seibel: Another phase of programming is optimization. Some people optimize things from the very beginning. Others like to write it one way and then worry about optimizing it later. Whats your approach?

Thompson: Ill do it as simply as possible the first time and very often that suffices for all time. To build a very complex algorithm for something thats never run is just stupid. Its just a waste of time. Its a bug generator. And it makes it impossible to maintain because youve got to have 50 pages of math to tell the next guy what youre actually doing.

Ninety-nine percent of the time something simple and brute-force will work fine. If you really are building a tool that is used a lot and it has some sort of minor quadratic behavior sometimes you have to go in and beat on it. But typically not. The simpler the better.

Seibel: Some people just like bumming code down to a jewel-like perfection, for its own sake.

Thompson: Well, I do too, but part of that is sacrificing the algorithm for the code. I mean, typically a complex algorithm requires complex code. And Id much rather have a simple algorithm and simple code than some big horror. And if theres one thing that characterizes my code, its that its simple, choppy, and little. Nothing fancy. Anybody can read it.

Seibel: Are there still tasks which, for performance reasons, people still have to get down to hand-tuned assembly code?

Thompson: Its rare. Its extremely rare unless you can really get an order of magnitude and you cant. If you can really work hard and get some little piece of a big program to run twice as fast, then you could have gotten the whole program to run twice as fast if you had just waited a year or two. If youre writing a compilercertainly 99 percent of the code you produce is going to be run once or twice. But some of its going to be in an operating system thats run 24 hours a day. And some of its going to be in the inner, inner loop of that operating system. So maybe 0.1 percent of the optimization you put into a compiler here is going to have any effect on your users. But it can have profound effect, so there maybe you want to do it.

Seibel: But that would be a result of generating better code in the compiler rather than writing the compiler itself in assembly.

Thompson: Oh, yes, yes.

Seibel: And presumably part of the reason writing programs directly in assembly is less important these days is because compilers have gotten better.

Thompson: No. I think its mostly because the machines have gotten a lot better. Compilers stink. You look at the code coming out of GCC and its awful. Its really not good. And its slow; oh, man. I mean, the compiler itself is over 20 passes. Its just monstrously slow, but computers have gotten 1,000 times faster since GCC came out. So it may seem like its getting faster because its not getting slower as much as computers are getting faster underneath it.

Seibel: On a somewhat related note, what about garbage collection? With Java, GC has finally made it into the mainstream. As Dennis Ritchie once said, C is actively hostile to garbage collection. Is it good that folks are moving toward garbage-collected languagesis it a technology that deserves to finally be in mainstream use?

Thompson: I dont know. Im schizophrenic on the subject. If youre writing an operating system or a C compiler or something thats used by lots and lots of people, I think garbage collection is a mistake, almost. Its a cheat for you where you can do it by hand and do it bettermuch better. What youre doing is your sloughing your task, your job, making it slower for your users. So I think its a mistake in an operating system. It almost just doesnt fit in an operating system. But if you are writing a hack program to do a job, get an answer and then throw the program away, its beautiful. It takes a layer of stuff you dont want to think about, at a cost you can afford, because computers are so fast, and its nothing but a win-win-win position. So Im really schizophrenic on this subject.

Part of the problem is there are different garbage-collection algorithms and they have different propertiesmassively different properties. So youre writing some really general-purpose thing like an operating systemif youre going to write it in a language that garbage-collects underneath, you dont even have the choice of the algorithm for the operating systems. Suppose that you just cant stand big real-time gaps and you have a garbage collector that runs up to some threshold and then does mark and sweep. Youre screwed before you start.

So if youre doing some general-purpose task that you dont know who your real users are, you just cant do that. Plus, garbage collection fights cache coherency massively. And theres no garbage-collection algorithm that is right for all machines. There are machines where you can speed it up by a factor of five or more by messing around with the cache. They should be tied to the machine much more than they are. Usually they treat them as separate algorithms that have nothing to do with machines, but the cache coherency is very important for garbage-collection algorithms.

Seibel: Do you think of yourself as a scientist, an engineer, an artist, a craftsman, or something else?

Thompson: I dont know. I hate to use the word scientist because I think its elitist. And implies a PhD. Theres no certificate that says scientist on it when you complete the scientist course, so I dont like the term or use it. Engineer, I do have a degree that says engineer on it, so I can use the word engineer. And when I fill out an occupation I either put engineer or programmer because I can justify those. But mostly I just dont worry about it.

Seibel: Well, leaving aside what you call yourself, who do you feel the most affinity with? Is it a physicist, a guy who builds bridges, a painter, or a carpenter?

Thompson: Kind of the lower things. I believe a craftsman but with a certain amount of artistry to keep it alive.

Seibel: How do you identify talented programmers?

Thompson: Its just enthusiasm. You ask them whats the most interesting program they worked on. And then you get them to describe it and its algorithms and whats going on. If they cant withstand my questioning on their program, then theyre not good. If I can attack them or find problems with their algorithms and their solutions and they cant defend it, being much more personally involved than I am, then no. At the same time you can get a sense of enthusiasm. Its not something you ask directly, but in the conversation youll come with this enthusiasm-ometer, and that is tremendously helpful for me. Thats how I interview. Ive been told that its devastating to be on the receiving side of that.

Seibel: I would imagine. Its sort of like an oral exam. Do you suppose youve ever run into people who just didnt have the personality that can deal with that, independent of their programming ability?

Thompson: No, I dont think its independent of programming. It would be if I started asking them classical computer-science kind of questions, but thats not what Im asking them. Im asking them to describe something theyve done that theyve spent blood on. Ive never met anybody who really did spend blood on something who wasnt eager to describe what theyve done and how they did it and why. I let them pick the subject. I dont pick the subject, so Im the amateur and theyre the professional in this subject. If they cant stand an amateur asking them questions about their profession, then they dont belong.

Seibel: What are you doing here at Google?

Thompson: Infrastructure. Operating-systems kind of stuff. Glue between the pieces. I have a charter for anything I want. The challenge is to get a bunch of unreliable machines to work like a reliable multiprocessor machine. I guess thats the closest thing.

Seibel: Isnt the point of Googles famous MapReduce machinery that its shared-nothing message-passing rather than a shared memory?

Thompson: Well, its a process that has well-known semantics and no feedback loops. If you have a reliable structure to do that, you can fit a lot of problems into that structure.

Seibel: And are you working on things within that kind of framework?

Thompson: No, its just trying to keep the burden of reliability off the individual programmers. Its a real tough challenge. All the software here has layers and layers and layers of what happens if this doesnt work, what happens if that doesnt work. What happens if I dont workwho kills me and who starts up, who does what. I would guess way more than 50 percent of the code is the what-if kind.

Seibel: So your goal is to have that half of the code go away?

Thompson: Well, it would be hidden somewhere. It would apply in a systematic way to the other code. Hopefully. Its a hard job.

Seibel: Do you like working here at Google?

Thompson: Parts of it I like, very much. But parts of it are just ponderous because theres money involved in bugs and theres money involved in lots of the stuff. The size is unimaginable. Like day one you kind of get something crippling along and day two youve got two million users. You just cant imagine such a thing.

Seibel: And youre actually on the production side. As opposed to being in Google Labs, which might be more akin to your past at Bell Labs.

Thompson: But Im not actually production either. Im in projects that will become production. But I dont babysit them after theyve gone. Probably my job descriptionwhether I follow it or not, thats a different questionwould be just to find something to make life better. Or have some new idea of new stuff that replaces old stuff. Try to make it better. Whatever it is thats wrong, that takes time, that causes bugs. If theres anything in the structure of Google, anything that you can put your finger on that could be done better, try to do it better.

Seibel: I know Google has a policy where every new employee has to get checked out on languages before theyre allowed to check code in. Which means you had to get checked out on C.

Thompson: Yeah, I havent been.

Seibel: You havent been! Youre not allowed to check in code?

Thompson: Im not allowed to check in code, no.

Seibel: You just havent gotten around to it, or you have philosophical objections to the Google coding standard?

Thompson: I just havent done it. Ive so far found no need to.

Seibel: So youre doing your stuff in your own sandbox? Do you mostly do your stuff in C?

Thompson: I write mostly in C. I do all my test stuff and toy stuff in C while Google is C++, strictly C++. Its no big deal programming in C++, but I dont like it. I resist it.

Seibel: You were at AT&T with Bjarne Stroustrup. Were you involved at all in the development of C++?

Thompson: Im gonna get in trouble.

Seibel: Thats fine.

Thompson: I would try out the language as it was being developed and make comments on it. It was part of the work atmosphere there. And youd write something and then the next day it wouldnt work because the language changed. It was very unstable for a very long period of time. At some point I said, no, no more.

In an interview I said exactly that, that I didnt use it just because it wouldnt stay still for two days in a row. When Stroustrup read the interview he came screaming into my room about how I was undermining him and what I said mattered and I said it was a bad language. I never said it was a bad language. On and on and on. Since then I kind of avoid that kind of stuff.

Seibel: Can you say now whether you think its a good or bad language?

Thompson: It certainly has its good points. But by and large I think its a bad language. It does a lot of things half well and its just a garbage heap of ideas that are mutually exclusive. Everybody I know, whether its personal or corporate, selects a subset and these subsets are different. So its not a good language to transport an algorithmto say, I wrote it; here, take it. Its way too big, way too complex. And its obviously built by a committee.

Stroustrup campaigned for years and years and years, way beyond any sort of technical contributions he made to the language, to get it adopted and used. And he sort of ran all the standards committees with a whip and a chair. And he said no to no one. He put every feature in that language that ever existed. It wasnt cleanly designedit was just the union of everything that came along. And I think it suffered drastically from that.

Seibel: Do you think that was just because he likes all ideas or was it a way to get the language adopted, by giving everyone what they wanted?

Thompson: I think its more the latter than the former.

Seibel: It seems there are a lot of people who say, Gosh, C++ is terrible. Yet everyone uses it. For instance, its one of Googles four official languages. Why do folks continue to use it if its so bad?

Thompson: I dont know. I think its losing at Google. Now there are more people who dont like it than like it.

Seibel: And they switch to Java?

Thompson: I dont know. Theres almost no replacement for it. They complain, but they dont switch. Graduate students coming outthe people who are hired by Googleknow it. So its hard to do anything else. Thats the reason it keeps goingit saves a tremendous amount of education, reeducation. It gets people productive faster.

Seibel: Are there other languages that you enjoy, or have enjoyed, programming in?

Thompson: All of the funny languages at one point Ive taken a step in. Like for solving equations and stuff: Maple and Macsyma, things like that. For strings, SNOBOL. Anyway, Ive played with dozens and dozens of languages, if they do something thats interesting.

Seibel: And are there development tools that just make you happy to program?

Thompson: I love yacc. I just love yacc. It just does exactly what you want done. Its complement, Lex, is horrible. It does nothing you want done.

Seibel: Do you use it anyway or do you write your lexers by hand?

Thompson: I write my lexers by hand. Much easier.

Seibel: Have you ever done any literate programming, a la Donald Knuth?

Thompson: No. Its a great idea, but its almost impossible to do in practice.

Seibel: Why?

Thompson: Its two representations of the same program that are often out of phase and conflict with each other. And theres no way to resolve it. If something is written well in a programming language, then its readable. It suffices. The comments dont need to be that parallel. The comments are maybe for algorithms, or if you do something tricky itd probably be more in the form of a warning or something. Im not a big, gross comment kind of guy. Its legendary.

Seibel: When I interviewed him, Knuth said the key to technical writing is to say everything twice in complementary ways. So I think he sees that as a feature of literate programming, not a bug.

Thompson: Well if you have two ways, one of them is real: what the machine executes. One of them is not. Only if one is massively more brief way than the other is it worthwhile. If its the same volume, you read the one that works. If one is much more terse, much less precise, and you can get out of it what you need, then thats great. But very often you cant get out of it what you needyou really need the nitty-gritty and then you go to the other. Depending on what youre after, you read one or the other. But to try to have microscopic descriptions of an algorithm, one in the programming language and one in Englishmaybe Knuth can do it, but I cant.

Seibel: Have you ever read any of his literate programs?

Thompson: Just his stuff in the early papers. Nothing recent.

Seibel: And are there books that you think are particularly importantthat either were important to you or that you would recommend people to read?

Thompson: I dont read beginning programming books, so I have trouble recommending such things. If I have to learn a new language or something Ill try to find a book. I prefer much denser books that just give me the syntax and semantics rather than chatting me up and telling me whats good style and whats bad style.

When I taught, I would have to select a textbook for my course and would read all of the textbooks in the area and have to make a selection. So at two points in time, I knew the basic literature for those courses. But outside that I dont read.

Seibel: When you were inventing Unix you had your plan to do the four pieces that would actually give you an operating system. Then your wife and kids went away, leaving you free to hack for a month. I assume you put in some long hours in that month. Why do we do that? Is it necessary? Is it just because its fun?

Thompson: You do it when youre driven. I dont think I could have not done it. The other thing is when the wife and kid are around you have this synchronizing to a 24-hour cycle. When they go away, I dont have a 24-hour cycle. Theres nothing that keeps me and the sun together. And so I typically sleep on a 27- or 28-hour cycle, sleeping 6 hours. So I drift. When I get to sleep until I wake up Im in better shape to work than if I get to sleep and get up when the kid starts screaming.

Seibel: So thats when youre driven by a project and you wake up wanting to get to the computer to start writing more code. But people also work long hours because we have this idea that weve got to get this product out the door and the way to do it is for everyone to work 80, 100 hours a week.

Thompson: That generates burnout. Excitement programming, I never ever felt stress. Ive been in other situations too where deadlinesexternal deadlinesgenerate stress. Thats not fun; I dont like that.

Seibel: You burn out at the end, which is obviously bad, but in terms of getting things done in the short term, does it work?

Thompson: Usually youre in a position where such a thing is continual. That as soon as that deadline is over another one starts coming up over the horizon. If youre constantly under deadlines like that, then the next one youll have less enthusiasm and pretty soon you just cant live like that. I cant.

Seibel: Tied up with trying to meet deadlines is being able to estimate how long things are going to take. Can you estimate how long its going to take to write a given piece of code?

Thompson: It depends on whether Im writing it for me or writing it for production. I can if Im writing for me. I can live with the quirks. I can not do the extra ten percent. I can avoid the gaping holes that I know are in there. Things like that. I can produce it and then clean it up at leisure and still use it. Maybe thats a different definition of finished. But if youre doing it for production then usually there are other people involved and coordinationI cant estimate that.

Seibel: In one 1999 interview you said you didnt think much of Linux, and got the Linux guys all up in arms. What do you think of it now about a decade later, and its taking over the world?

Thompson: Its much more reliabletheres no doubt about that. And Ive looked at the code occasionally. I dont look at it as much as I used to. I used to, for Plan 9. They were always ahead of usthey just had massively more resources to deal with hardware. So when wed run across a piece of hardware, Id look at the Linux drivers for it and write Plan 9 drivers for it. Now I have no reason to look at it. I run Linux. And I occasionally look at code, but rarely, so I cant really tell whether the quality has gotten better or not. But certainly the reliability has gotten better.

Seibel: Do you ever read code just for fun?

Thompson: In the past I used to; less so now. When I first came here I did it just to try and get the feel of the place. Youve got to. Theres so much unsaid that youve got to know.

Seibel: Would you pick a program and completely understand it, or were you just sort of looking for how do they do things around here?

Thompson: A little bit of both. Id certainly try to pick the big libraries at first. Id look at the main programs of some of the things. The programming style here at Google is so bizarre. They take a subroutine call, package it as an RPC, and store it somewhere static. Which means anybody can call it at any time for any reason. And then they call generic listening kind of code and somebody somewhere gets a message, goes off and finds that, and makes that subroutine call.

Seibel: So thats a mechanism for distributed computation.

Thompson: Yeah. Thats all this place does. Its very hard to read. So you go off and you start reading the binding code. And then this code. And then the general IPC. That gets you a handle into where you can actually start reading stuff and understanding stuff. Before that, you cant understand a thing.

Seibel: When you work on a team, whats the structure that you like?

Thompson: Just working with good, compatible people.

Seibel: When youre working with compatible people, do you favor strong code ownership: I wrote this piece of code; it is mine and Im responsible for it, or more shared ownership: We all own this code together and anyone can do what they see fit.?

Thompson: Ive always worked halfway in between. Theres somebody who owns it and if you have a problem with it, you mail them or tell them and their job is to fix it. And then at some point they disappear, they dont want it, they dont fix it, theyre not responsivethen you fix it. The catchphrase is, You touched it last. You own it. So its halfway between. You dont have a bunch of people going in and modifying the code willy-nilly. Its all filtered through an owner. But that owner can change pretty easily.

Seibel: These days there are folks who advocate pair programming, meaning two people working at one keyboard. Have you ever worked that way?

Thompson: Something small can be done like that. Very often Ill be typing and somebody else, who will obviously be faster at it than I, will sit down and theyll type and Ill talk. Ive done that on orders of minutes to hours, very few hours, to get one thing done that both of us could have done separately.

Seibel: And did you find that the result was better or it got done faster?

Thompson: The result isnt better. Probably debugging is fasteras youre typing, someone can catch a bug over your shoulder. So I think it will generate fewer bugs as you go. But I didnt find it as a philosophy as a way to goit just happens.

Seibel: Do you still enjoy programming?

Thompson: Yes. I like small programs. Small, meaning you can do it in a month. If youre trying to do some monster task that takes a year, I cant keep in it that long.

Seibel: Was that always the case, or have you lost the energy for longer projects?

Thompson: I dont know. It depends on the actual thing. Something big that takes years, like an operating system, you subdivide that and there are lots of fun pieces, so that counts as multiple small things as opposed to one big thing. But there are lots of things that are just one big thing, and those I think Ive always found difficult. I need gratification, feedback. And if you have to sit there and work and work and work for days, months and see nothing except a pile of code, then I have trouble doing that.

Seibel: Youve mostly worked in research and it seems youve had a lot of latitude to work on what you like, but did it change when it become a job? Did it take any of the fun out of it?

Thompson: No. Its always been fun, and mostly because I just selected what I wanted to do. And even when it was a job, back in college, there were tons and tons of jobs available. It seemed to me that there were tons of people who were doing something, whatever it is, and they needed some little programming task done on the side to aid them. So they were perfect for me. They were little tiny jobs that I could get into, get in and out in days and pick and choose which one I wanted to take.

I think my first one was a humanities professor cataloging Homers work. And he had The Iliad and The Odyssey on cards. He wanted word frequencies and countsessentially statistical analysis of these two works. And that was fun. It was text processing, which just wasnt done by computers in those days. So that was my first odd job.

Seibel: In a 1999 interview you talked about how you had told your son he should go into biology instead of computers because you thought computers were played out. That was almost ten years ago. How do you feel about that now?

Thompson: I feel the same. Nothing much new has happened in computers that you couldnt have predicted. The last significant thing, I think, was the Internet, and that was certainly in place in 99. Everything has expandedthe speed of individual computers is still expanding exponentially, but whats different?

Seibel: Reading the history of Unix, it seems like you guys basically invented an operating system because you wanted a way to play with this computer. So in order to do what today might be a very basic thing, such as write a game or something on a computer, well, you had to write a whole operating system. You needed to write compilers and build a lot of infrastructure to be able to do anything. Im sure all of that was fun for its own sake. But I wonder if maybe the complexity of modern programming that we talked about before, with all these layers that fit together, is that just the modern equivalent of, Well, first step is you have to build your own operating system? At least you dont have to do that anymore.

Thompson: But its worse than that. The operating system is not only given; its mandatory. If you interview somebody coming out of computer science right now, they dont understand the underlying computing at all. Its really, really scary how abstract they are from what a computer is or even the theory of computing. They just dont understand it.

Seibel: I was thinking about your advice to your son to go into biology instead of computing. Isnt there something about programmingthe intellectual fun of defining a process that can be enacted for you by these magical machinesthats the same whether youre operating very close to the hardware at a very abstract level?

Thompson: Its addictive. But you wouldnt want to tell your kid to go into crack. And I think its changed. It might just be my aging, but it seems like when youre just building another layer on top of another layer on top of another layer, you dont really get the benefit of writing, say, a DFA. I think by necessity algorithmsnew algorithms are just getting more complex over time. A new algorithm to do something is based on 50 other little algorithms. Back when I was a kid you were doing these little algorithms and they were fun. You could understand them without it being an accounting job where you divide it up into cases and this case is solved by this algorithm that you read about but you dont really know and on and on. So its different. I really believe its different and most of it is because the whole thing is layered over time and were dealing with layers. It might be that Im too much of a curmudgeon to understand layers.


: 1.310. /Cache: 3 / 1