これは、Paul Graham：Why Arc Isn't Especially Object-Oriented を、原著者の許可を得て翻訳・公開するものです。
<版権表示>
本和訳テキストの複製、変更、再配布は、この版権表示を残す限り、自由に行って結構です。
(「この版権表示」には上の文も含まれます。すなわち、再配布を禁止してはいけません)。
Copyright 2002 by Paul Graham
原文: http://www.paulgraham.com/noop.html
日本語訳：Shiro Kawai (shiro ＠ acm.org)
<版権表示終り>
Paul Graham氏のエッセイをまとめた『ハッカーと画家』の
邦訳版が出版されました。
出版社の案内ページ
Amazon.co.jp
サポートページ
2005/01/23 翻訳公開[訳註1]
ちかごろは、オブジェクト指向プログラミングというものに対して 一種の熱狂があるようだ。だが、私の知る 最も賢いプログラマ の多くは、オブジェクト指向に対してあまり熱心ではない。
私自身の感覚としては、オブジェクト指向プログラミングは時には 有用なテクニックであるが、書かれる全てのプログラムがそれでなくちゃいけない なんていうものじゃない。新しい型を自分で定義できることは必要だけれど、 全てのプログラムを新しい型の定義として書かなくちゃならないってことはないだろう。
私の思うところでは、人々がオブジェクト指向プログラミングを好むのには 5つの理由があり、そのうち3.5個の理由は悪いものだ。
レキシカルクロージャやマクロがない、静的型付け言語を使って来た人に とっては、オブジェクト指向プログラミングは素晴らしいものに見えるだろう。 そういう制限をある程度まで回避する手段を与えるからだ。 (グリーンスパンの第10法則[訳註2]を見よ)。
オブジェクト指向プログラミングは大企業で人気がある。 彼らのソフトウェアの書き方に適合するからだ。 大企業ではソフトウェアは、しばしば人員が変更される、 中庸のプログラマからなる大きなチームで作られる。 オブジェクト指向プログラミングはチームのプログラマに一定の規範を要求し、 したがって誰かがへまをやってもそれが深刻な被害を起こさないようにする。 だがその見返りとして、結果のコードはプロトコルでふくれあがり、あちこちに 重複があるものとなる[訳註3]。 大企業にとっては、しかし、これはそれほど問題にはならないかもしれない。 彼らが書くソフトウェアはいずれにせよ脹れあがって重複だらけになるだろうから。
オブジェクト指向プログラミングは、なんだかうまく動きそうなコードを 大量に作り出すことができる。プリンタに連続印字紙を使っていた時代には、 1ページあたり20行のすてきにフォーマットされたコメントに続いて 5行か10行のコードしか書かないプログラマがいたものだ。 オブジェクト指向プログラミングはそういう人々にとって絶好の機会だった。 ソースコードに実にいろいろな足場を組み込むことができるからだ。 Lispハッカーがリストにシンボルをプッシュして済ますようなことさえも、 数々のクラスとメソッドからなる一つのファイルになってしまう。 従って、オブジェクト指向プログラミングは、あなたが自分自身や誰か他の人に対して、 たくさん仕事をしているように見せるには非常に良い手段だ。
言語そのものがオブジェクト指向プログラムであれば、 ユーザ自身がそれを拡張することができる。まあ、多分ね。 でもそれは、オブジェクト指向プログラミングを構成する個々の概念を ばらばらに提供したほうがうまくいくかもしれない。 例えば、オーバーロードはクラスと本質的に結び付いているわけじゃない。 まあ、将来どうなるか見てみよう。
オブジェクト指向抽象化は特定の種類のプログラムの扱う領域に非常に うまくあてはめることが出来る。例えばシミュレーションやCADシステムだ。
個人的には、オブジェクト指向抽象化が必要だと思ったことは一度もない。 Common Lispは恐ろしいほど強力なオブジェクトシステムを持っているが、 私は一度もそれを使ったことがないんだ。ハッシュテーブルにクロージャを詰め込む とか、弱い言語だったらオブジェクト指向テクニックが必要だっただろうと 思えることはたくさんやってきたけれど、CLOSを使う必要に迫られたことは無かった。
私が単にばかなのかもしれないし、限定されたアプリケーションしか作って こなかったからかもしれない。個人の経験だけに基づいて言語を設計するのには 危険が伴う。だが、だからといって、世間で良いと思われているからというだけで 自分では必要としたことのないものを入れるのは、もっと危険ではないだろうか。
これはPaulが2002年に書いた文章である。翻訳自体は2004年に済んでいたのだが、 Jonathan Reesのコメントと一緒に 公開したいと思っているうち公開が遅くなった。
Greenspun's Tenth Rule of Programming: 「十分に複雑なCまたはFortranの プログラムは全て、後付けで、正式な仕様がなく、バグがてんこもりの、 遅い、CommonLispの半分の実装を含んでいる」。 参考。
full of duplication: コピペによるコードの重複を言っているだけではないので注意。 「技術野郎の復讐」等で触れているように、 例えば「パターン」を繰り返し人間が書いてやらなければならない、ということは 重複なのである。マクロなら一回で済むのだから。