Rubyを使い始めて４か月目に入りました。Rubyを勉強していくうちに2003年に行われたRubyの生みの親であるまつもとゆきひろ氏のインタビュー記事があり、日本語訳が見当たらなかったので、勉強がてら和訳してみました。
以下、長いですが、引用です。
Rubyの哲学
要約
まつもとゆきひろ（Rubyの生みの親）はRubyの設計哲学についてBill Vennersと対談した。設計の不完全性、直行性の危険性、コンピューターの努力における人間の重要性について話した。
まつもとゆきひろ（ネット上ではMatzと呼ばれている）はRubyの生みの親だ。Rubyは、日々プログラミングをするのにもフルスケールのアプリケーションを作るのにも両方に適したオブジェクト指向の言語だ。MatzのRuby開発は1993年にまで遡る。書くのが楽しく、生産性を向上させる言語が欲しかったからだ。最初は日本で人気になったが、Rubyは世界中のプログラマーのハートをつかんだ。
2003年9月24日、Bill VennersはデンマークのAarhusで開かれたJAOO会議でMatzと対談した。この対談で、MatzはRubyの設計哲学、Rubyの特徴、より良いプログラマーになることについて論じた。この記事ではMatzは設計の不完全性、直行性の危険性、ある程度の道しるべを与えながらも自由を与えること、驚き最小限の原則、コンピューターの努力における人間の重要性について述べる。
完璧な言語なんてない
Bill: Dave Thomas（プログラミングRuby
Matz: 言語設計者は完璧な言語を設計したいと思う。言語設計者はできるなら、「私の言語は完璧だ。なんでもできる」と言いたい。だが、完璧な言語を設計するのはただただ不可能だ。なぜなら言語を見るのに二つの側面があるからだ。一つはその言語で何を成すことができるか。もう一つは、その言語を使ってどう感じるか、つまり、プログラミングの最中に人間がどう感じるかだ。
チューニング完全理論のために、チューニング完全言語でできることはすべて、理論上は他のチューニング完全言語でもできる。しかし、コストが異なる。アセンブリ言語でもすべてできる。だが、もはやだれもアセンブリ言語でプログラミングをしたいとは思わない。何が出来るかという観点で考えれば言語は異なる。ただ、違いは限られている。例えば、PythonとRubyはプログラマーにとってほとんど同じ力を提供してくれる。
私は「何」の側面ではなく、「どのように」の側面を強調したい。つまり、プログラミングするときにどう感じるかだ。それがRubyの他の言語との主な違いだ。私はフィーリング、特にRubyを使って私がどう感じるかを強調したい。私はRubyをすべての人にとって完璧にするために頑張りたくはない。私が感じることとあなたが感じることは違う。すべての人にとって完璧な言語なんてない。私はRubyを私にとって完璧にしたい。おそらくそれはあなたにとっては完璧ではないだろう。Guido van Rossumにとって完璧な言語はPythonであるように。
直行性VS調和性
Bill: Dave Thomasはもし私が直行性のある特徴を加えるようにあなたにお願いするなら、あなたはそれをしないだろうとも言った。あなたがしたいのは調和のとれたことである。調和とは何を意味するのか？
Matz: 私は、一貫性と直行性は設計の道具にすぎず、設計の最優先の目的ではないと思っている。
Bill: ではこの文脈で直行性とは何を意味する？
Matz: 直行性の一例はちょっとした特徴やシンタックスを結び付けれるようにすることだ。例えば、C++は関数に対し、デフォルトパラメータ値とパラメーターに基づいた関数名のオーバーロードすることの両方ができる。両方とも一つの言語の持つ良い特徴だが、それらは直行性があるので、同時に適用することはできない。コンパイラはそれらを同時に適用する術を知っている。もしそれが少し曖昧なら、コンパイラはエラーを起こすだろう。しかし、コードを見ると私は私の頭でそのルールを適用する必要がある。つまり、私はコンパイラがどう動作するかを推測する必要がある。もしその推測が正しいなら私は十分に賢い。そういうときは問題はない。しかし、私があまり賢くなければ、そして私は実際に賢くないが、それは混乱の元となる。その結果は普通の人間にとっては予想のしないことだ。これがどのように直行性が良くないかを示す一例だ。
Bill: つまり、直行性は書き手がそれらを理解して作用させたとき、うまく動作すると。けれど、プログラマーにとっては、それを見たときに理解するのは難しい。コンパイルされるから。そして、私はこれらの二つの事象がどう一緒に動くか判断しなければならないから。
Matz: 直行性という特徴は、結び付けられた時とても複雑になる。
Bill: では、代替のものは何か？さらなる調和か。
Matz: 言語に組み込むために、それら二つのうち一つをピックアップする。あなたは考えているすべてをする必要はない。それらのうち一つを選べば良い。両方とも良かったとしても。
自由と安らぎ
Bill: Pythonコミュニティの設計哲学の一つは、一つだけ提供すること。ものごとをするのに一つだけやり方を提供すること。もしあなたが、同じことをするのに５０の異なる方法を提供したら、書き手には便利さを提供することになる。みんな好きな方法で書くことができる。トレードオフは読み手だ。例えば、私がある人のコードを読むとき、その人はある一つの方法で書く。次に別人のコードを読むとき、その人は別の方法で書く。だから読み手として、私はタスクを完了させるために結局すべての方法に精通する必要がある。私の好きな方法だけじゃなくて。それが設計のトレードオフだ。Pythonコミュニティは一つの方法を好むようだ。たった一つの。しかし、Rubyは同じことをするのに複数の方法を提供しているように見える。
Matz: RubyはPerlの哲学を継承している。それは同じことをするのに複数個提供するということだ。わたしは、Larry Wallからその哲学を受け継いだ。Larry Wallは私のヒーローだ。私は、Rubyユーザーに自由になってほしい。私は彼らに選択の自由を与えたい。人間はみな違う。人間はみな様々な基準を持っている。しかし、多くの代替方法の中にはより良い方法がある。私は快適にすることによってその方法を奨励したい。だから、それが私が挑戦してきたことだ。おそらくPythonのコードはRubyより読みやすいだろう。みんな同じスタイルで書く。だからたぶん読みやすい。しかし、人と人との違いはとても大きい。たとえPythonを使っているとしても、一つのやり方だけを提供することはほとんど助けにはならない。私はそう思う。私は可能ならばたくさんの方法を提供したい。けれども、良い方法を推奨するユーザーや道しるべを提示してくれるユーザがより良い方法を選んでくれるだろう。
Rubyの楽しみ
Bill: あなたは、Ruby導入記事で、「私にとって、人生の目的の一部は喜びを持つことだ。プログラマーはプログラミングという創造に集中することができると、よく楽しみを感じる。だから、Rubyはプログラマーを幸せにするために設計されている」と書いた。Rubyはどのようにプログラマを幸せにできますか？
Matz: あなたは人生を幸せにしたいよね。もしあなたが仕事を素早くできたら、あなたの仕事は楽しい。良いと思わないかい？それが人生の目的の一つだ。あなたの人生はより良くなる。
私はコンピュータを使うことで日々の生活で直面する問題を解決したい。だから私はプログラムを書く。Rubyを使うことで、その言語の摩訶不思議な規則ではなく、私がすることに集中したい。"print hello world"と言うためにpublic void なんちゃらという呪文から始めるのではなく、私は単に"print this!"と言いたい。私は周囲の摩訶不思議なキーワードはいらない。私はタスクに集中したいだけなのだ。それが基本的な考え方だ。だから私はRubyコードを簡潔にすることに挑戦してきた。
Bill: 簡潔なコードが書けることは、プログラマーを幸せにする方法の一つだ。
Matz: そうだ。結果、彼らは解決しなければならない課題そのものに集中できる。プログラマはときどき紙に疑似コードを書くことがある。もしその疑似コードが直接パソコンで動いたらすごいと思わないかい？Rubyはそうできるようになることを目指している。Pythonがそう言われるように。
Bill: そう、Pythonは実行可能な疑似コードだとみんな言っている。Rubyで他にプログラマを幸せにすることは何だい？
Matz: プログラマとしての日々の生活の中で、私たちはたくさんのテキスト文字列を処理する。だから私はテキスト処理に一生懸命取り組もうとしている。つまり、Stringクラスと正規表現だ。正規表現は言語にビルトインされていて、使用に適したチューニングが施されている。私たちは何度もOSを呼び寄せる必要もある。RubyはUnix上のあらゆるシステムコールやWindows APIのほとんどを呼ぶことができる。これで、OSの力や機能を言語環境の解釈に割ける。だからあなたは日々のシステム管理やテキスト処理プログラミングができる。それが少なくとも私の人生の中の主な領域だ。だから私はそれを良くするために一生懸命活動する。
Bill: だから基本的に、自分の仕事を早くそして楽しく終わらせるのに役立つことで、Rubyは私の生活を楽しませてくれると？
Matz: 私にとってはね。あなたにとってそうかどうかは分からない。そうであることを望むけど。
ヒューマンファクター
Bill: インタビューの中で、あなたは次のように述べた。「ヒューマンファクターを過小評価してはいけない。たとえパソコンの前にいたとしても、パソコンは機械だ。私たちは人間のために人間と一緒に働く。」これはどういうことを意味する？
Matz: メールを書いているときを想像してほしい。そのときあなたはパソコンの前にいる。パソコンを操作している。マウスをクリックしたり、キーボードを打ったりしてね。だけれども、メールのメッセージはインターネットの先の人間に届く。だからあなたはパソコンの前で働いていると言ってもそのパソコンの後ろには人がいる。私たちがしていることのほとんどは人間のためにやっていることだ。例えば税金計算によって政府は私の財布からお金を引き出す。政府は人間で構成される。
私たちの仕事のほとんどは結局人間に関係している。だからプログラミングによって、私たちは、パソコンに人間のために働くよう求めたり、コンピュータが実行できるレベルのとても明確な方法で私たちの考えを表現することができる。
一つ目のケースとしては、人間のために働くコンピュータを作ることだ。ターゲットはコンピュータの向こうの人間だ。もう一つのケースは、コンピュータによって理解され、実行される程度に考えを明確に表現することで、私たちは自分の脳から意図を表現し、結果的にコンピュータに実行される。両方のケースでの対象はやはり人間だ。
Bill: そのように考えるのは何が重要なのか。あなたはヒューマンファクターを過小評価するなと言った。なぜか。
Matz: コンピュータは、コンピュータとコミュニケーションをとろうと努力しなければいけないかどうかやコミュニケーションがとりやすいかどうかは気にしない。コンピュータは私がファイル内のバイト列の命令番号を入力し、実行させるためにそれを送信しなければいけないかなんて気にしない。あるいは、とても高級な言語が命令を生成したかなんて気にしない。コンピュータは気にしないのだ。私たち人間は私達がする努力を気にする。人々、特にコンピュータエンジニアは、機械に焦点を当てる。「これをすることで、そのマシンはもっと早くなる。これをすることでそのマシンはもっと効率よく動く。これをすることで、そのマシンは･･･」と考える。彼らは機械にフォーカスする。しかし実際には私たちは人間に、そして、人間がどのようにプログラミングをするかや、どのようにアプリケーションを操作するかに焦点を当てる必要がある。私たちが支配者で、機械が奴隷なのだ。
Bill: しばらくの間はね。
Matz: しばらくの間、そう、ターミネータ世代のうちは。
驚き最小の原則
Bill: インタビューの中で、あなたはこう述べた。「私は自分の驚きを最小限にするためにRubyを設計した。私は、世界中の人々がRubyが驚きを減らし、プログラミングの喜びを高めたと教えてくれた時とても驚いた。今や私はプログラマーの心は世界中で似ていると確信している。」
なぜ驚き最小の原則なのか。
Matz: 実際には、私はRubyが驚き最小の原則に従うと主張してはいなかった。何人かの人がRubyの設計がその哲学に従っていて、そう言いだした。実際は私はそれを持ち出してはいない。
私はプログラミング中の自分のフラストレーションを最小にしたかった。だから私はプログラミングにおける努力を最小にしたい。それがRubyを設計する上での私の主な目標だ。私はプログラミングでもっと楽しみたい。Rubyをリリースしてから、世界中のたくさんの人がRubyを知るようになって、私が感じるように彼らも感じると言った。彼らは驚き最小の原則というフレーズを思いついた。しかし実際にはしばしば誤解される。
Bill: どう誤解される？
Matz: 人々はみな個々人のバックグラウンドを持っている。ある人はPythonからきたかもしれないし、またほかのある人はPerlからきたかもしれない。そして言語のさまざまな側面に驚くだろう。そして私の所に来てこう言うのだ。「私はRubyのこの特徴に驚いた。だからRubyは驚き最小の原則に反する」と。ちょっと待ってほしい。驚き最小の原則はあなただけのものじゃない。驚き最小の原則は私の驚き最小の原則を意味する。そしてそれはあなたがRubyをしっかりと勉強してからわかる。例えば、私はRubyの設計を開始する前、C++のプログラマだった。私は２～３年間、C++だけでプログラミングをしてきた。そしてC++のプログラミングを２年間やってもまだ私は驚いていた。
