Paul Graham 主頁欄目翻譯：Programming FAQ

你用什麼編輯器？

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 的陣列來表示它。