编程人生(Coders at Work)

我对他的观点还是持保留态度，毕竟现在软件的规模和复杂程度远不是那个时候能比的。 那个时候软件代码可以装入一个人的脑子，但是现在稍微上点规模的项目，没有人能了解全部。

The funny thing is, thinking back, I don’t think all these modern gizmos actually make you any more productive. Hierarchical file systems—how do they make you more productive? Most of software development goes on in your head anyway. I think having worked with that simpler system imposes a kind of disciplined way of thinking. If you haven’t got a directory system and you have to put all the files in one directory, you have to be fairly disciplined. If you haven’t got a revision control system, you have to be fairly disciplined. Given that you apply that discipline to what you’re doing it doesn’t seem to me to be any better to have hierarchical file systems and revision control. They don’t solve the fundamental problem of solving your problem. They probably make it easier for groups of people to work together. For individuals I don’t see any difference.

Also, I think today we’re kind of overburdened by choice. I mean, I just had Fortran. I don’t think we even had shell scripts. We just had batch files so you could run things, a compiler, and Fortran. And assembler possibly, if you really needed it. So there wasn’t this agony of choice. Being a young programmer today must be awful—you can choose 20 different programming languages, dozens of framework and operating systemsand you’re paralyzed by choice. There was no paralysis of choice then. You just start doing it because the decision as to which language and things is just made—there’s no thinking about what you should do, you just go and do it.

不设边界，打开黑盒子

I can’t say beginner programmers should open up all these abstractions. But what I am saying is you should certainly consider the possibility of opening them. Not completely reject the idea. It’s worthwhile seeing if the direct route is quicker than the packaged route. In general I think if you buy software, or if you use other people’s software, you have to reckon with an extremely long time to tailor it—it doesn’t do exactly what you want, it does something subtly different. And that difference can take a very long time to solve.

现代软件开发没有强调组件之间的互通性：数据格式，协议，传输方式等等。如果解决了互通性， 软件开发的复杂程度可能会降低不少。比如使用RPC就可以很好地解决monolithic app的解耦和重构问题。

Programmers have been conned into using all these different programming languages and they’ve been conned into not using easy ways to connect programs together. The Unix pipe mechanism—A pipe B pipe C—is trivially easy to connect things together. Is that how programmers connect things together? No. They use APIs and they link them into the same memory space, which is appallingly difficult and isn’t cross-language. If the language is in the same family it’s OK—if they’re imperative languages, that’s fine. But suppose one is Prolog and the other is C. They have a completely different view of the world, how you handle memory. So you can’t just link them together like that. You can’t reuse things. There must be big commercial interests for whom it is very desirable that stuff won’t work together. It creates thousands of jobs for consultants. And thousands of tools to solve problems that shouldn’t exist. Problems that were solved years ago.

黑盒并不意味着内部简单。messaging passing over APIs（如果编译在一个项目里面， 你还需要了解这个APIs的很多不愿意暴露的细节). simple interface wins!!

What’s going on inside the black boxes can be exceedingly complicated. But gluing things together from these complicated components does not itself have to be complicated. The use of grep is not complicated in the slightest. And what I don’t see in system architectures is this clear distinction between the gluing things together and the complexity of the things inside the boxes.

When we connect things together through programming language APIs we’re not getting this black box abstraction. We’re putting them in the same memory space. If grep is a module that exposes routines in its API and you give it a char* pointer to this and you’ve got to malloc that and did you deep copy this string—can I create a parallel process that’s doing this? Then it becomes appallingly complicated to understand. I don’t understand why people connect things together in such complicated ways. They should connect things together in simple ways.

写代码的时候保持清醒是多么的重要，不然出来的几乎都是垃圾

And what I’ve learned is, programming when you’re tired, you write crap and you throw it all away the next day. And 20 years ago I would program although I was getting a strong feeling that this isn’t right—there’s something wrong with this code. I have noticed over the years, the really good code I would write was when I’m in complete flow—just totally unaware of time: not even really thinking about the program, just sitting there in a relaxed state just typing this stuff and watching it come out on the screen as I type it in. That code’s going to be OK. The stuff where you can’t concentrate and something’s saying, “No, no, no, this is wrong, wrong, wrong”—I was ignoring that years ago. And I’d throw it all away. Now I can’t program anymore if it says, “No.” I just know from experience, stop— don’t write code. Stop with the problem. Do something else.

命名上可以通过一些技巧减少错误。比如 `person` 和 `listOfPerson` 而不是 `persons` (这样容易看错)

One that’s tricky is slight spelling errors in variable names. So I choose variable names that are very dissimilar, deliberately, so that error won’t occur. If you’ve got a long variable like personName and you’ve got personNames with an “s” on the end, that’s a list of person names, that will be something that my eye will tend to read what I thought it should have been. And so I’d have personName and then listOfPeople. And I do that deliberately because I know that my eye will see what I thought I’d written. But punctuation, I do see that—I do see the commas and the brackets as being wrong. And of course Emacs colors everything and auto-indents and the brackets are different colors. So this is really easy.

Erlang对内存进行了抽象。所以要对内存进行比较细致操作的话，最好使用C模块扩展或者是使用Erlang DSL生成C代码。 另外OCaml原来这么强大啊！

Seibel: Has there ever been anything that you’ve found difficult to work into the Erlang model?

Armstrong: Yeah. We abstract away from memory, completely. If you were turning a JPEG image into a bitmap data, which depends on the placement of the data in a very exact sense, that doesn’t work very well. Algorithms that depend on destructively upgrading state—they don’t work well.

Seibel: So if you were writing a big image processing work-flow system, then would you write the actual image transformations in some other language?

Armstrong: I’d write them in C or assembler or something. Or I might actually write them in a dialect of Erlang and then cross-compile the Erlang to C. Make a dialect—this kind of domain-specific language kind of idea. Or I might write Erlang programs which generate C programs rather than writing the C programs by hand. But the target language would be C or assembler or something. Whether I wrote them by hand or generated them would be the interesting question. I’m tending toward automatically generating C rather than writing it by hand because it’s just easier. But I’d use an Erlang structure. I’ve got some stuff that does my family images and things. So I use ImageMagik with some shell scripts. But I control it all from Erlang. So I just write wrappers around it and call os:command and then the ImageMagik command. So it’s quite nice to wrap up things in. Wouldn’t want to do the actual image processing in Erlang. It’d be foolish to write that in Erlang. C’s just going to be a lot better.

Seibel: Plus, ImageMagik is already written.

Armstrong: That doesn’t worry me in the slightest. I think if I was doing it in OCaml then I would go down and do it because OCaml can do that kind of efficiency. But Erlang can’t. So if I was an OCaml programmer: “OK, what do I have to do? Reimplement ImageMagik? Right, off we go.”

如果你不理解什么东西，那么就去实现它。在这个实现过程中，你可以学习到很多东西。

Seibel: Is there anything that you have done specifically to improve your skill as a programmer?

Armstrong: No, I don’t think so. I learned new programming languages but not with the goal of becoming a better programmer. With the goal of being a better language designer, maybe.

I like to figure out how things work. And a good test of that is to implement it yourself. To me programming isn’t about typing code into a machine. Programming is about understanding. I like understanding things. So why would I implement a JPEG thing like we talked about earlier? It’s because I’d like to understand wavelet transforms. So the programming is a vehicle to understand wavelet transformations. Or why do I try to do an interface to X Windows? Because I wanted to understand how the X protocol worked.

It’s a motivating force to implement something; I really recommend it. If you want to understand C, write a C compiler. If you want to understand Lisp, write a Lisp compiler or a Lisp interpreter. I’ve had people say, “Oh, wow, it’s really difficult writing a compiler.” It’s not. It’s quite easy. There are a lot of little things you have to learn about, none of which is difficult. You have to know about data structures. You need to know about hash tables, you need to know about parsing. You need to know about code generation. You need to know about interpretation techniques. Each one of these is not particularly difficult. I think if you’re a beginner you think it’s big and complicated so you don’t do it. Things you don’t do are difficult and things you’ve done are easy. So you don’t even try. And I think that’s a mistake

通常Bug会出现在你上次修改位置的附近。另外"print"调试法居然被他装饰得近乎不容置疑的"真理"=D

Seibel: What are the techniques that you use there? Print statements?

Armstrong: Print statements. The great gods of programming said, “Thou shalt put printf statements in your program at the point where you think it’s gone wrong, recompile, and run it.”

Then there’s—I don’t know if I read it somewhere or if I invented it myself—Joe’s Law of Debugging, which is that all errors will be plus/minus three statements of the place you last changed the program. When I worked at the Swedish Space Corporation my boss was a hardware guy. We were up at Esrange, the rocket-launching site and satellite-tracking station in the north. And one time he was banging his head, debugging some bug in the hardware, plugging in oscilloscopes, and changing things. And I said, “Oh, can I help?” And he said, “No Joe, you can’t help here—this is hardware.” And I said, “Yeah, but it must be like software—the bug will be pretty near to the last change you made to the hardware.” And he went, “I changed a capacitor. You’re a genius!” He’d replaced one capacitor with a bigger capacitor and he unsoldered it and put the original one back and it worked. It’s the same everywhere. You fix your car and it goes wrong—it’s the last thing you did. You changed something—you just have to remember what it was. It’s true with everything.

英语和写作的重要性。

Seibel: Are there other skills that are not directly related to programming that you feel have improved your programming or that are valuable to have as a programmer?

Armstrong: Writing is. There’s some computer scientist that said, “Oh, if you’re no good at English you’ll never be a very good programmer.”

Seibel: I think Dijkstra had something about that.

Armstrong: I’ve occasionally been asked to advise people at universities on choice of syllabus subjects for computer science courses, being as how I work for industry—what does industry want? And I say, “Well, turn ’em out being able to write and argue cogently.” Most graduates who come out, and they’ve got degrees in computer science, writing’s not their strong point.

不积跬步无以至千里。不断学习新东西也有强大的复利效果。

And Hamming said, “I always spend a day a week learning new stuff. That means I spend 20 percent more of my time than my colleagues learning new stuff. Now 20 percent at compound interest means that after four and a half years I will know twice as much as them. And because of compound interest, this 20 percent extra, one day a week, after five years I will know three times as much,” or whatever the figures are. And I think that’s very true. Because I do research I don’t spend 20 percent of my time thinking about new stuff, I spend 40 percent of my time thinking about new stuff. And I’ve done it for 30 years. So I’ve noticed that I know a lot of stuff. When I get pulled in as a troubleshooter, boom, do it that way, do it that way. You were asking earlier what should one do to become a better programmer? Spend 20 percent of your time learning stuff—because it’s compounded. Read Hamming’s paper. It’s good. Very good.

idea重要还是语言本身重要？smalltalk消亡了，但是影响力巨大。

Seibel: You care a lot about the idea of Erlang’s way of doing concurrency. Do you care more about that idea—the message-passing shared-nothing concurrency—or Erlang the language?

Armstrong: The idea—absolutely. People keep on asking me, “What will happen to Erlang? Will it be a popular language?” I don’t know. I think it’s already been influential. It might end up like Smalltalk. I think Smalltalk’s very, very influential and loved by an enthusiastic band of people but never really very widely adopted. And I think Erlang might be like that. It might need Microsoft to take some of its ideas and put some curly braces here and there and shove it out in the Common Language Runtime to hit a mass market.

大型项目里面一个人没有办法做完所有事情，但是你可以构思这件事情应该如何完成。

Seibel: And do you remember any particular aha! moments where you noticed the difference between working on something by yourself and working on a team?

Norvig: I don’t know if it was so much moments, but just this realization that you can’t do everything yourself. I think a lot of programming is being able to keep as much as you can inside your head, but that only goes so far, at least in my head. Then you have to rely on other people to have the right abstractions so that you can use what they have. I started thinking about it in terms of, “How is this likely done?” rather than, “I know how this was done because I did it.” If I were to have done this, how would I have done it? I hope that it’s like that, and if it’s not, figure out why not, and then figure out how to use it.

打开那个黑盒子(black box).

Seibel: And do you think that changes the kind of people who can be successful at programming now?

Norvig: I think the people that are really successful are the same—at least that’s what I see around here. But, yeah, it is a little bit more of, “Can I quickly get an understanding of what I need,” and less of, “I need complete understanding.” I think some of it is bravado, this willingness to say, “I’m just going to go ahead and do it,” the fearlessness of saying, “I don’t understand everything that’s going on, but I went into the documentation and I learned these three things. I tried it and it worked, so I’m just going to go ahead.” That gets you to a certain point, but I think to really be a good programmer, you can’t just do that. You have to understand a little bit more, and say, “Is it safe, what I’m doing here? Or what are the failure cases? Sure, I tried it once and it worked, but is it always going to work? How do I write test cases to show that and to understand it a little better, and then once I’ve done that, can I extract what I’ve done and publish a new tool that other people can use because I’ve put these pieces together in a certain way.”

这点和Joe Armstrong一样。设计软件需要有文档。这个文档应该只有用来帮助你理清设计思路， 定制好宏观架构，而不要过于探究细节（除非这个细节非常重要）

Seibel: So back to designing software. What about when you’re working on bigger programs, where you’re not going to be able to just remember how all the code fits together? Then how do you design it?

Norvig: I think you want to have good documentation at the level of overall system design. What’s the thing supposed to do and how’s it going to do it? Documentation for every method is usually more tedious than it needs to be. Most of the time it just duplicates what you could read from the name of the function and the parameters. But the overall design of what’s going to do what, that’s really important to lay out first. It’s got to be something that everybody understands and it’s also got to be the right choice. One of the most important things for having a successful project is having people that have enough experience that they build the right thing. And barring that, if it’s something that you haven’t built before, that you don’t know how to do, then the next best thing you can do is to be flexible enough that if you build the wrong thing you can adjust.

理解项目的最好办法：阅读代码，修改代码

Seibel: One of the aspects of the modern style of programming, as you were saying, is that programmers have to absorb things quickly. How do you tackle the problem of understanding a big pile of code, none of which you’ve ever seen before?

Norvig: I think you do a mix of statically and dynamically. You start reading the code and trying to make sense of it and then you get some traces of what calls what, and where most of time is spent, and what’s the flow through it. Then try to do something. Say, “I’m going to make this trivial little change.” Or go to the issues database and say, “I’ll take this one.” In order to do that, I have to learn a little piece of it. There’s only a little piece, but you get that done and you move on to the next one.

和Joe Armstrong一样，对于Knuth的文学编程持保留态度。同时，他们都鼓励编写单元测试和文档。

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

Norvig: I never used his tools per se. I’ve certainly written macros and so on. And I’ve used the Java docs and things like that. In many ways, Lisp programming encourages you to make your own system as you go, and so it ends up being literate in that way. You find your own macros for your own application-specific programming, and part of that is the documentation, part of it’s the data, and part of it’s the code, so I’ve certainly done that. Then more recently, in whatever language I’m using, whether it’s Java, or Python, or whatever, I’ve certainly been careful to write test cases, and document around that.

You look at Knuth’s original Literate Programming, and he was really trying to say, “What’s the best order for writing a book,” assuming that someone’s going to read the whole book and he wants it to be in a logical order. People don’t do that anymore. They don’t want to read a book. They want an index so they can say, “What’s the least amount of this book that I have to read? I just want to find the three paragraphs that I need. Show me that and then I’ll move on.” I think that’s a real change.

Seibel: I wonder if there isn’t a way to write modern-style literate programming. Certainly Knuth’s tools give you an index and beautiful crossreferencing. I wonder if perhaps a modern approach to literate programming just would organize the book differently—both as a whole program and as a bunch of pieces that you can understand in bits?

Norvig: I don’t know. I think he was solving a problem that doesn’t exist anymore to a large degree. Part of it was because he wanted to put it in a linear order rather than in a web-like or a searchable order. I think part of it was the limitations. I think he was using Pascal originally. And there it’s pretty strict in terms of what had to be declared first and not necessarily in the order you want. Modern languages are more free in that order, so I think it’s less of an issue now.

现代软件和计算机系统之大之复杂，没有人能够完全理解它们。这和上个世纪70，80年代差别很大。

Seibel: What has changed the most in the way you think about programming now, vs. then? Other than learning that bubble sort is not the greatest sorting technique.

Steele: I guess to me the biggest change is that nowadays you can’t possibly know everything that’s going on in the computer. There are things that are absolutely out of your control because it’s impossible to know everything about all the software. Back in the ’70s a computer had only 4,000 words of memory. It was possible to do a core dump and inspect every word to see if it was what you expected. It was reasonable to read the source listings of the operating system and see how that worked. And I did that—I studied the disk routines and the card-reader routines and wrote variants of my own. I felt as if I understood how the entire IBM 1130 worked. Or at least as much as I cared to know. You just can’t do that anymore.

这家伙居然是一页页看下来的TAOCP. 后面他提到他也会自己编写上面的代码。

Seibel: Were there books that were important to you when you were learning to program?

Steele: In the ’70s, absolutely: Knuth, The Art of Computer Programming.

Seibel: Did you read those cover-to-cover?

Steele: Pretty close to cover-to-cover, yes. I worked as many exercises as I felt I was capable of tackling. Some called for higher math or other things I didn’t understand, and I’d sort of gloss or skip over those. But the first two volumes and much of the third I read pretty carefully. The Aho, Hopcroft, and Ullman algorithms book—that’s where I learned how to do sorting for real, I think. I’d have to step across to my library to try to remember other ones. I’m a pack rat—I’ve saved all these books. But those are the ones that I would cite off the top of my head.And books about Lisp. The Triple-I Lisp book edited by Berkeley and Bobrow: kind of a scatter-shot collection of papers, but I learned a lot of interesting stuff from that. And then I started reading SIGPLAN Notices and Communications of the ACM. Back in those days CACM had real technical content and was well worth reading.

Lisp虽好但也不是所谓的"winner". 每种语言都有设计初衷，而这些初衷通常就是它强大的地方。

Seibel: One way to resolve that is the way Lisp does—make everything uniformly semiconcise. Where the uniformity has the advantage of allowing users of the language to easily add their own equally uniform, semiconcise, first-class syntactic extensions. Yet a lot of folks resist the s-expression syntax. The smug Lisp weenie view of the world is, “Some people just don’t get it; if they did they would see the brilliance of the solution.” Are you a smug enough Lisp weenie to think that if people really understood Lisp they would not be put off by the parentheses?

Steele: No. I don’t think I’ve got the standing to be smug. If anything, because I have learned so many languages I think I understand better than a lot of people the fact that different languages can offer different things. And there are good reasons to make choices among them rather than to hold up one language and say, “This is the winner.”

There are certain kinds of projects that I would not want to tackle with anything other than Lisp because I’m interested in the set of tools it provides me. For instance, ready-made input/output—if I’m willing to conform to Lisp’s syntax, then I’ve already got readers and printers built that are adequate for some kinds of jobs. This in turn allows you to do some kinds of rapid prototyping. On the other hand, if it’s important that I customize the I/O to an existing specific format, then Lisp might not be such a good tool. Or else I might have to build some kind of transducer in some language, Lisp or otherwise, to get it over to the Lisp world.

软件环境越来越复杂，没有人能够理解所有东西，造成现在的编程难度超过从前。 更好的(精心设计的,elaborated)程序设计语言可以缓解这种困难吗？

Seibel: Do you think languages are getting better? You keep designing them, so hopefully you think it’s a worthwhile pursuit. Is it easier to write software now because of advances that we’ve made?

Steele: Well, it’s much easier now to write the kinds of programs we were trying to write 30 years ago. But I think our ambitions have grown tremendously. So I think programming is probably a more difficult activity than it was 30 years ago.

Seibel: And what are the things that are making it more difficult?

Steele: I think we’ve got people now who are just as smart as the people we had 30 years ago and they are being pushed to the limits of their abilities as people were 30 years ago—I’ve chosen 30 years ago as an arbitrary baseline because that’s when I got out of school. But the difference is that— as I remarked earlier—it’s not possible to understand everything that’s going on anymore. Or even to think you can. So I think that the programmers of today are up against a more difficult environment—still exercising the same amounts of ingenuity but in an environment that’s harder to understand. So we try to make more elaborate languages to help them deal with the uncertainty of those environments.

如果bug小概率出现的话，那么我们应该去看代码中那些小概率执行路径。但是就像他之前说的， 现代软件越来越复杂，你几乎不可能跟踪到出现bug的代码上。

比如我们最近遇到的连接https网站，返回 `ssl I/O system call error` 这个错误。 虽然我们知道是握手期间交换和验证公钥出错，但是我们依然不能确定问题出在哪里：

1. 连接https网站的客户端是Android App，所以和Android系统相关，不同Android系统使用的openssl版本不同。
2. 我们使用的是AWS的ACM系统来配置证书，需要选择支持的SSL协议版本。如果这个协议版本过高，那么低版本的客户端通信也会失败。
3. 客户端所处的网络环境。之前遇到过俄罗斯用户解析DNS失败，我们在App里面写死一个IP地址，是否可能这个IP地址上单独配置的证书有问题。
4. 客户端Android系统上是否正确配置了AWS的根证书，这也是一个造成问题的可能性。
5. 客户端App并没有直接使用Java原生的OpenSSL库，而是使用okhttp3. 那Bug是否可能出现在okhttp3上呢？

Steele: So I guess there’s lessons there—the lesson I should have drawn is there may be more than one bug here and I should have looked harder the first time. But another lesson is that if a bug is thought to be rare, then looking at rarely executed paths may be fruitful. And a third thing is, having good documentation about what the algorithm is trying to do, namely a reference back to Knuth, was just great.

考虑到KT发明了Unix, 所以我把他和David Culter(NT作者)和Linus Torvalds(Linux作者)做个比较， 发现他们之间有一个共同点就是：他们的对硬件知识了解比较多，对那些高级语言一律不怎么感兴趣，把更多的 时间放在如何解决当前的问题上，非常喜欢简单的架构即使这个架构对性能有一定的影响，还有就是无一例外地 讨论C++。他们和其他大师差别就是他们极致的务实（relentless pragmatic），以致于你甚至会感觉他们有点无聊。

layers on layers on layers! hard to understand, hard to reason !

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. It’s just relegating the problem to a deeper and deeper level. I can’t keep it in my mind—I can’t understand it.

对待别人的代码，这个方法和心态真的不错。

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

Thompson: When it’s hard to work on. I do it much quicker than most people do. I’ll 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. I’ll throw it away and start over and come up with a different partitioning that makes it easy to do whatever I wanted to do. I’m really quick on the trigger for throwing stuff out.

Seibel: Is that true working with other people’s code as well?

Thompson: It depends on whether I have control. If I have control, sure, it doesn’t matter. If I don’t have control, it’s someone else’s code, then I’ll suffer. Or not do it.

对待文档的态度。如果是给自己看的，那么很简略；如果是给其他人使用或者是要发布的，那么要写好。 对待别人糟糕的代码，要不就不用，要不就自己调试；对外自己的代码，如果写的不好，就直接丢弃。

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

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

Documenting is an art as fine as programming. It’s rare I find documentation at the level I like. Usually it’s 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; it’s time-consuming. To do it right, you’ve got to do it like programming. You’ve got to deconstruct it, put it together in nice ways, rewrite it when it’s wrong. People don’t do that.

为什么不要过度优化？为什么不要尝试去榨干性能？我的理解是，除非这种榨干性能的方式是 非常generic & simple的。使用复杂的方式去榨干性能，一方面回造成软件复杂难以维护， 另一方面摩尔定律或者是更多的机器是性价比更高的方案。

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 shouldn’t 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, Moore’s law has already surpassed you. You can pick up 10 percent but while you’re 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 it’s largely a waste of time to do really well. It’s 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.

C++是一门委员会搞出来的语言，试图让每个成员都满意。这样也好，左右逢源，用的人就多了。 但是好的程序员只会谨慎地使用它的subset而不是全部。

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

Thompson: I’m gonna get in trouble.

Seibel: That’s 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 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 just 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 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 it’s a good or bad language?

Thompson: It 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.

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 it’s more the latter than the former.

对待工作的态度也是一如既往的简单。

Seibel: You’ve mostly worked in research and it seems you’ve 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. It’s 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.