# Ken Thompson

Kenneth Lane Thompson (born 4 February 1943) is a computer scientist and winner of the 1983 Turing Award, together with Dennis Ritchie. He is notable for his work on the Unix operating system.

## Quotes

* You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code.
** "Reflections on Trusting Trust", 1983 Turing Award Lecture, Communications of the ACM 27 (8), August 1984, pp. 761-763.
* The press, television, and movies make heroes of vandals by calling them whiz kids. ... There is obviously a cultural gap. The act of breaking into a computer system has to have the same social stigma as breaking into a neighbor's house. It should not matter that the neighbor's door is unlocked.
** "Reflections on Trusting Trust", 1983 Turing Award Lecture, Communications of the ACM 27 (8), August 1984, pp. 761-763.
* "I've seen [visual] editors like that, but I don't feel a need for them. I don't want to see the state of the file when I'm editing."
** Thompson on the superiority of ed to editors such as today's vi or emacs, as summarized by Peter Salus in A Quarter Century of UNIX (Addison-Wesley, 1994).
* Ken Thompson was once asked what he would do differently if he were redesigning the UNIX system. His reply: "I'd spell creat with an e."
** Kernighan, Brian W.; Pike, Rob (1984). The UNIX programming environment. Prentice-Hall. ISBN 0139376992. OCLC 10269821. , p. 204.
* grep was a private command of mine for quite a while before i made it public.
* When in doubt, use brute force.
* Unix was built for me. I didn't build it as an operating system for other people, I built it to do games, and to do my stuff. I was always into games, games was my thing. I used to play pinball machines, and I would pick the lock in the back of pinball machines. Then I'd study the diagrams that I had. That's where I learned a lot of this kind of logic.

### Plan 9 fortune file (1992)

    Quotations from the fortune command included with the Plan 9 operating system (1992)
* We have persistent objects, they're called files.
* If you want to go somewhere, goto is the best way to get there.
* The X server has to be the biggest program I've ever seen that doesn't do anything for you.
** Thompson later followed up: "I now realize that X was just miles ahead in its programming style."
* Hi, this is Ken. What's the root password?
* 'Gigabit' seems to mean 600 megabits. It's a VAX gigabit.
* There's going to be no serious problem after this.
* It does everything Unix does only less reliably.
** (In response to the question, "Can you sum up plan 9 in layman's terms?")

### "Unix and Beyond: An Interview with Ken Thompson," 1999

"Unix and Beyond: An Interview with Ken Thompson", Computer 32 (5), May 1999, pp. 58-64
* I am a very bottom-up thinker. If you give me the right kind of Tinker Toys, I can imagine the building. I can sit there and see primitives and recognize their power to build structures a half mile high, if only I had just one more to make it functionally complete. I can see those kinds of things.
* I think the major good idea in Unix was its clean and simple interface: open, close, read, and write.
* Unix was a very small, understandable OS, so people could change it at their will. It would run itself—you could type "go" and in a few minutes it would recompile itself. You had total control over the whole system. So it was very beneficial to a lot of people, especially at universities, because it was very hard to teach computing from an IBM end-user point of view. Unix was small, and you could go through it line by line and understand exactly how it worked. That was the origin of the so-called Unix culture.
* In Plan 9 and Inferno, the key ideas are the protocol for communicating between components and the simplification and extension of particular concepts. In Plan 9, the key abstraction is the file system—anything you can read and write and select by names in a hierarchy—and the protocol exports that abstraction to remote channels to enable distribution. Inferno works similarly, but it has a layer of language interaction above it through the Limbo language interface—which is like Java, but cleaner I think.
* I view Linux as something that's not Microsoft — a backlash against Microsoft, no more and no less. I don't think it will be very successful in the long run. I've looked at the source and there are pieces that are good and pieces that are not. A whole bunch of random people have contributed to this source, and the quality varies drastically. My experience and some of my friends' experience is that Linux is quite unreliable. Microsoft is really unreliable but Linux is worse. In a non-PC environment, it just won't hold up. If you're using it on a single box, that's one thing. But if you want to use Linux in firewalls, gateways, embedded systems, and so on, it has a long way to go.
* Anything new will have to come along with the type of revolution that came along with Unix. Nothing was going to topple IBM until something came along that made them irrelevant. I'm sure they have the mainframe market locked up, but that's just irrelevant. And the same thing with Microsoft: until something comes along that makes them irrelevant, the entry fee is too difficult and they won't be displaced.

### "Ken Thompson clarifies matters", 1999

"Ken Thompson clarifies matters", Linux Today. May 7, 1999.
* I think the open software movement (and Linux in particular) is laudable.
* I do believe that in a race, it is naive to think Linux has a hope of making a dent against Microsoft starting from way behind with a fraction of the resources and amateur labor. (I feel the same about Unix.)
* I must say the Linux community is a lot nicer than the Unix community. A negative comment on Unix would warrant death threats. With Linux, it is like stirring up a nest of butterflies.

### "Coders At Work", 2009

* I would try out the [C++] language [at AT&T] as it was being developed and make comments on it. It was part of the work atmosphere there. And you'd write something and then the next day it wouldn't 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 didn't use it because it wouldn't 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.
** Ken Thompson; cited in Seibel, Peter (2009). Coders At Work. p. 475.
* [C++] certainly has its good points. But by and large I think it's a bad language. It does a lot of things half well and it’s just a garbage heap of ideas that are mutually exclusive. Everybody I know, whether it’s personal or corporate, selects a subset and these subsets are different. So it’s not a good language to transport an algorithm—to say, "I wrote it; here, take it." It’s way too big, way too complex. And it’s 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 wasn't cleanly designed—it was just the union of everything that came along. And I think it suffered drastically from that.
** Ken Thompson; cited in Seibel, Peter (2009). Coders At Work. p. 475.
* I used to [look at the Linux source code], for Plan 9. They were always ahead of us—they just had massively more resources to deal with hardware. So when we'd run across a piece of hardware, I'd 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 can't really tell whether the quality has gotten better or not [since 1999]. But certainly the reliability has gotten better.
** Ken Thompson; cited in Seibel, Peter (2009). Coders At Work. p. 479.

### "Interview with Ken Thompson", 2011

* When the three of us [Thompson, Rob Pike, and Robert Griesemer] got started, it was pure research. The three of us got together and decided that we hated C++. [laughter] ... [Returning to Go,] we started off with the idea that all three of us had to be talked into every feature in the language, so there was no extraneous garbage put into the language for any reason.
** Ken Thompson, talking about the origins of the Go programming language
** Dr. Dobb's: Interview with Ken Thompson (18 May 2011). Retrieved on 7 February 2014.

## Quotes about Kenneth Thompson

* Ken has always been a problem solver and a tool builder. He is equally excited by games, puzzles, and technology creation, and I don't think he really distinguishes among them.
** Dennis Ritchie (June 2001). "Ken, Unix and Games". ICGA Journal 24 (2).
* Ritchie and Thompson made an amazing team; and they played Unix and C like a fine instrument. They sometimes divided up work almost on a subroutine-by-subroutine basis with such rapport that it almost seemed like the work of a single person. In fact, as Dennis has recounted, they once got their signals crossed and both wrote the same subroutine. The two versions did not merely compute the same result, they did it with identical source code! Their output was prodigious. Once I counted how much production code they had written in the preceding year − 100,000 lines! Prodigious didn’t mean slapdash. Ken and Dennis have unerring design sense. They write code that works, code that can be read, code that can evolve.
** Doug McIlroy (2011). Remarks for Japan Prize award ceremony for Dennis Ritchie, May 19, 2011, Murray Hill, NJ

## External links

* Ken Thompson (WayBack Machine archive of dead link)
* ACM Classic: Reflections on Trusting Trust
* ↑ The history of grep, the 40 years old Unix command. Benjamin Rualthanzauva (5 February 2014).
* ↑ c2 Wiki - Brute Force.
* ↑ The Thompson and Ritchie Story. National Inventors Hall of Fame - NIHF (February 18, 2019).