ポール・グレアム「プログラミングのFAQ」を翻訳しました。原題は Programming FAQ で、原文はココです。英語とプログラミングに強いみなさま、アドバイスをよろしくお願いいたします。なお翻訳にあたり、id:ttamo様、id:Shinnya様のアドバイスをいただいております。ありがとうございます!!


プログラミングのFAQ
Programming FAQ


エディターには何を使っていますか?
What editor do you use?

viだ。
vi.


プログラムを学ぶには?
How can I learn to program?

プログラミングができる友達を見つけよう。その友達にプログラムを編集・実行可能なシステムをインストールしてもらう。言語は友達が入門用に勧めたものに(たぶんPythonかRuby)。次にオライリーの本を手に入れ、勉強しよう。
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.

プログラムの書き方と実行を掴めてきたら、自分が作りたいプログラムについて考えよう。学習意欲が増すだろう。
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?


どうしてLispをよく話題にするんですか?
Why do you keep going on about 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.

キュービクルが最低だってことは誰にでもわかる。オフィスのレイアウトで、あるスタイルに固執する人もほとんどいない。だが言語では、みんな自分の知っている言語にすごく固執する。というのも、(a) 新しい言語を学ぶのはたいへんだし、(b) プログラミング言語はプログラムというものの考え方に影響するため、自分が慣れている言語よりも強力な言語は、想像さえ難しくなるからだ。
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.

他の言語を非難するのは失礼だとわかってはいる。だが失礼=間違いではない。そして言語の設計者はみんな、「どの言語がなぜ良いか」といった厄介な問題に向き合う必要がある。まあ一般人がやったら非常に失礼なことでも、肛門科医はしなきゃいけないようなもんだ。
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.


オブジェクト指向プログラミングは、ある種の問題には向いていると思いませんか?
Isn't object-oriented programming naturally suited to some problems?

イエスでもノーでもある。オブジェクト指向らしさを構成しているいくつかの概念をバラバラに分けて考えると、オブジェクト指向向きに見える問題の多くは実はそうでもないと気付く。
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.

たとえば私は、CADプログラムかシミュレーションには、おそらくオブジェクト抽象化をするだろう。(だが結局のところ、言語に元からある機能ではなく、マクロを使って独自のオブジェクト・モデルを作ることになるだろう)
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).

しかし、ある読者がオブジェクト指向問題の典型例として寄こした次の問題は違う。
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.



連続したn個のポートがあり、それぞれがk個のプロトコルのうちの1つを使う可能性があり、しかもプロトコルは実行中に変わる可能性があるとする。




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.