Programmers From The United States

"If you write a lot of programs, and you're used to squeezing them all the time, you find that it's easy to write a program that's simple. A lot of it is having a clear sense of what you want to say — writing the proof by choosing what to prove, and being clear about that. In programming, a lot of simplicity comes from knowing what matters and what doesn't matter."

"There is an art to knowing where things should be checked and making sure that the program fails fast if you make a mistake. That kind of choosing is part of the art of simplification."

"So today, let's write a program simply. But let's also realize that tomorrow, we're going to make it more complex, because tomorrow it's going to do more. So we'll take that simplicity and we'll lose some of it. But tomorrow, hopefully tomorrow's program is as simple as possible for tomorrow's needs. Hopefully we'll preserve simplicity as the program grows."

"Let's not worry about what somebody reading the code tomorrow is going to think. Let's not worry about whether it's efficient. Let's not even worry about whether it will work. Let's just write the simplest thing that could possibly work."

"You are always taught to do as much as you can. Always put checks in. Always look for exceptions. Always handle the most general case. Always give the user the best advice. Always print a meaningful error message. Always this. Always that. You have so many things in the background that you're supposed to do, there's no room left to think. I say, forget all that and ask yourself, "What's the simplest thing that could possibly work?" I think the advice got turned into a command: "Do the simplest thing that could possibly work." That's a little more confusing, because there isn't this notion that as soon as you've done it, we'll evaluate it."

"There's been an awful lot of discussion about what is or isn't simple, and people have gotten a pretty sophisticated notion of simplicity, but I'm not sure it has helped."

"I don't claim to be a methodologist, but I act like one only because I do methodology to protect myself from crazy methodologists."

"When a manager asks for hard data, that's usually just his way of saying no."

"There is a programming smell here… which is kind of like the smell in your refrigerator, you know. There's a sign that there's something wrong, but you can't quite put your finger on it. But you know if you leave it there, its only going to get worse."

"What I'm really doing is I'm trying to preserve the right for a programmer to think while he's typing. If you feel that it’s not going well, you can stop and say 'What did I get wrong? Let me correct it."

"My hope is that wiki becomes a totem for a way of interacting with people. Tradition in the work world has been more top down, while wiki, standing for the Internet, is becoming a model for a new way of work. Largely driven by reduced communication costs, it changes what needs to be done and how it’s going to get done. I hope that the wiki nature, if not the wiki code, makes some contribution."

"A wiki is a work sustained by a community."

"The blogosphere is a community that might produce a work. Whereas a wiki is a work that might produce a community. It’s all just people communicating."

"One’s words are a gift to the community. For the wiki nature to take whole, you have to let go of your words. You have to be okay with that. This goes into the name, called refactoring. To collaborate on a work, one must trust. The reason the cooperation happens is we are people and it is deep in our nature to do things together."

"Cooperation has a transactional nature, we agree it is a mutual good. Collaboration is deeper, we don’t know what the transaction is, or if there is one, but if I give of myself to this collaboration, some good will come out of it. You have to trust somebody to collaborate."

"With wiki, you have to trust people more than you have any reason to trust them. In 1995, it was a safer environment, don’t know if I could have launched wiki today."

"Putting a new feature into a program is important, but refactoring so new features can be added in the future is equally important. The ability to do things in the future is something that I consider suppleness, like clay your hands that accepts your expression. Programs and documents get brittle very quickly. Wiki imagines a more dynamic environment where we accept change..."

"Anonymity relieves refactoring friction. Have learned that people want to sign things. But try to write in a way where you don’t have to know who said it. But when someone who is not in a giving mood uses anonymity (spammers), that abuse can drive us away from anonymity. But I hope we can drive the ill-intended out without having to give up the openness."

"The web has been an experiment in anonymity. Conscious design of low level protocols. Lots of identity infrastructure has been created to make it an online shopping mall, which makes it unpleasant for all of us because the machinery isn’t that great."

"People can and do trust works produced by people they don’t know. The real world is still trying to figure out how Wikipedia works. A fantastic resource. Open source is produced by people that you can’t track down, but you can trust it in very deep ways. People can trust works by people they don’t know in this low communication cost environment."

"Top down hierarchies make communication work when it is expensive, I hope that wiki can be a flagship in this move in the industry to produce computer support for this kind of work and evolve organizational forms."

"Wiki helped define the category of social software."

"Global collaboration is something that Wiki mastered in a small way and here we can master it in a big way."

"People who understand their collective goals and values are pretty good at self-organizing -- as long as they are allowed to."

"Accept that you've got a common goal that we're all working towards and that we're working towards the same goal. In other words, align and self-organize."

"Before wikis, computer writing was all about the words. The computer could help you type them, spell them, hyphenate them, size them, shape them, and align them. But when it came to developing your thought, well, you were on your own."

"Now, with wikis, you have a place to write. A wiki is a place to write in the same way that a party is a place to talk. There are thoughts all around you. Some are interesting, some less so. At a party or on a wiki, a word or two will be your trigger. Ideas start flowing. Talking or writing, you're among friends, the stage is set, you say your piece, it fits in, your words trigger the next thought: conversation."

"A wiki is like a party that doesn't have to stop. It's a party that doesn't get crowded because new rooms appear when needed. It's a timeless party where you can try each conversation over and over until you get it right."

"He's very good at his strengths. When he gets an idea in his head, he works it over until he has it solved or knows it can't be solved. I've rarely seen him give up on problems."

"One thing about school - I always had this attitude that I was in school to learn, and attempted to do whatever was involved in that process, while school had this attitude that I was there to earn grades, which I couldn't care less about. Unsurprisingly, my grades weren't very good."

"I hated school, and dropped out of college. I got picked on a lot in school, and had a lot of trouble making friends."

"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."

"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."

"[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."

"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."

"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."

"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."

"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."

"If you want to go somewhere, goto is the best way to get there."

"We have persistent objects, they're called files."

"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."

"When in doubt, use brute force."

"grep was a private command of mine for quite a while before i made it public."

"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.""

"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."

"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."

"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."

"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 think the open software movement (and Linux in particular) is laudable."

"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."