Paul Graham 主页栏目翻译：Programming FAQ

 

翻译前序：

最近一年越来越多的尝试阅读英文书籍，很少读中文版的主要原因是，读着别人翻译的文字总是习惯性的觉得拗口。一直想知道将英文文章翻译成中文是一种什么样的感觉，今晚试着翻完了 Paul Graham 主页上的 PROGRAMMING FAQ [1]。最大的体会是，翻译真心是个苦差事，因为你不仅需要理解原文还要想方设法组织好语言用词。所以说，中文版书籍翻译的差不要紧，咱可以不读，但是还是应该尊重译者的劳动成果少点骂声的。

[1] http://paulgraham.com/pfaq.html

瞎翻，轻拍 -_-!!!

-------------------------------------------------------------------------------------------

What editor do you use?

你用什么编辑器？

vi.

How can I learn to program?

我怎样学习编程？

Find a friend who knows how to program. Get them to set you up with a system where you can edit and run programs. Use whatever language they suggest for a beginner (probably it will be Python or Ruby). Then get the O'Reilly book and start working through it.

结识会编程的朋友，让他们给你搭建一个可以编写并运行程序的系统。使用他们建议初学者学习的编程语言（这种语言可能是 Python 或者 Ruby）。然后找 O’Reilly 出版的那本关于该语言的入门书籍通读一遍。

As you learn the mechanics of writing and running a program, start thinking about specific programs you want to write. That will motivate you to learn more.
在你学习编写和程序运行机制的时候，开始思考某个你想编写的程序，那会激发你学习更多的东西。

Don't start with a problem that's too big. A good way to begin is to take an existing program and modify it to do something new.
不要从大的问题编起。一种好的起步方式是，修改一个已有的程序让它去做新的事情。

Initially your programs will be ugly, but don't worry about that. Everyone's are. Just keep going, and they'll get better.
开始的时候，你的程序可能不太好看，但是不用担心这个。每个人（在一开始写的程序）都会那样。只要你坚持写，你的程序会越来越好。

As you learn, you'll find it useful to look at programs other people have written. But you'll learn more from this once you've tried programming yourself.
学习编程的时候，读一下别人写的程序对你会很有帮助。但是，一旦你尝试自己编程你会从别人代码中学到更多东西。

Finally, find friends who like to write programs. They can answer your technical questions; you'll get new ideas from talking to them; and they'll be the audience for your first efforts. 
最后，结识喜欢编程的朋友。他们会解答你的技术疑问，你也会从与他们的交流中收获新的想法，而且，他们也将是你最初成果的见证者。

Why do you advise plunging right into a programming project instead of carefully planning it first?
你为什么建议直接参与编程项目，而不是先仔细规划一下？

If you're trying to solve a simple, predefined problem like doing a depth-first search, thinking everything out beforehand doesn't hurt. But few real problems are like that. In real-world applications, you don't usually know at first precisely what problem you're trying to solve. So if you spend a lot of time planning in advance, what you'll end up with is a minutely detailed plan for solving the wrong problem.

如果你尝试解决的是一个简单的、预先定义好的问题，比如，深度优先搜索，事先把解决问题的思路理清楚不会有任何坏处。但是，实际中碰到的问题往往没那么简单。在实际应用中，通常情况下你是不会事先清楚地知道你要尝试解决的问题是什么、所以，如果你花费太长时间用于提前规划，最终设计出来的详细规划所解决的只是一个错误的问题。

With complex, ill-defined problems, you're better off writing a prototype as fast as you can, seeing what turns out to be wrong with it, and then changing your definition of the problem accordingly.

对于复杂的、不好定义的问题，最好的做法是尽快编写出一个原型，观察哪个模块会出问题，然后相应的修改你对问题的定义。

Often the reason programmers are pushed into planning is not that the problem requires it, but that project managers require it. Maybe programmers should give managers an explicit choice: do you want me to solve the problem in the way that will make you feel good, or the way that will yield the best solution?

很多时候，程序员被迫做规划的原因不是由问题本身驱使的，而是项目经理要求这么做的。或许程序员们应该给经理们一个选择：你是想让我用你喜欢的方式解决问题呢，还是用能最终解决问题的方式？

Why do you keep going on about Lisp?
你为什么总在谈论 Lisp？

There are a number of topics I go on about: that small companies do things better than big ones; that cubicles suck; that you have to understand design to be a good hacker; that planning is overrated. Those don't seem so conspicuous, because many readers either have no prior opinion, or already agree.
其实我谈论的话题很多，比如：小公司做出来的东西比大公司的好；办公室的隔板很操蛋；要想成为一名好的黑客，你需要理解设计是什么；规划（的意义）被高估了。这些话题似乎不那么会引起读者的注意，因为很多读者要么事先对此没有概念，要么已经认同了。

It doesn't cost anything to realize that cubicles suck. Few people have a vested interest in one style of office over another. But everyone has a vested interest in the languages they already know, because (a) it is a lot of work to learn a new language, and (b) programming languages dictate how you think about programs, so it is hard even to conceive of a language more powerful than whatever you're used to.

认识到办公室的隔板很操蛋这个事实并不会耗费任何代价。很少有人会对哪种风格的办公室布局更好感兴趣，但是每个人都会对他们熟悉的编程语言感兴趣，因为（a）学会一门新的语言需要费点功夫（b）编程语言反映你思考程序的方式。所以，让他们认同某门语言比他们自己熟悉的语言更加强大是很困难的。

Dissing someone else's language is considered rude, I know. But rude is not the same as false. And any language designer  has to face awkward questions like which languages are better, and why, just as proctologists have to do things that would be considered extremely rude if ordinary people did them.
我知道贬低别人使用的编程语言是很粗鲁的。但是，粗鲁的并不等同于错的。每一个编程语言的设计者都要面对诸如“哪种语言更好以及为什么” 这类“粗鲁的”问题，这就像直肠病专家（proctologists ）不得不做一些换了普通人做就会被认为很粗鲁的工作。

Isn't object-oriented programming naturally suited to some problems?

OO 难道不是天生适应于某些问题么？

Yes and no. A lot of what seem to be OO problems turn out not to be if you have random access to the concepts that together comprise object-orientedness.
Yes and no. 很多看上去是 OO 的问题也可以看做非 OO 问题，关键看你如何看待 OO 思想中的那些概念。

If I were writing a CAD program or a simulation, for example, I'd probably use OO abstractions (though I'd probably end up creating my own OO model with macros instead of using whatever came with the language).

举个例子，如果让我写一个 CAD 程序或者模拟器，或许我会考虑使用 OO 思想 （尽管我可能只是用宏来创建我自己的 OO 模型，而不是使用语言自带的 OO 特性）

But if I were trying to solve the problem one reader sent to me as a canonical example of an OO problem, I wouldn't.

但是，如果让我尝试解决一位读者发给我的所谓使用 OO 求解的典型问题，那我可能就不会使用 OO 。

Suppose you have n serial ports, each of which may speak one of k protocols, and this must be configurable at run-time.

假设你有 n 个连续端口，每个端口可能是 k 个协议中的一个，要求在运行时是可配置的。

I'd just use an n-by-k array of closures to represent this.

我可能只是使用一个 n * k 的数组来表示它。