なぜArcは特にオブジェクト指向ではないのか
現在、オブジェクト指向プログラミングに対する一種の熱狂があるが、私が知る最も賢いプログラマーの一部は、それについて最も興奮していない。
私自身の感じ方は、オブジェクト指向プログラミングは場合によって有用な技術だが、あなたが書くすべてのプログラムに浸透させる必要があるものではないということだ。新しい型を定義できるべきだが、すべてのプログラムを新しい型の定義として表現する必要はない。
私は、人々がオブジェクト指向プログラミングを好む理由は五つあり、そのうち三つ半は悪い理由だと思う:
-
オブジェクト指向プログラミングは、字句的クロージャやマクロのない静的に型付けされた言語を持っている場合に刺激的だ。ある程度、それはこれらの制限を回避する方法を提供する。(グリーンスパンの第十法則を参照。)
-
オブジェクト指向プログラミングは大企業で人気がある。なぜなら、彼らがソフトウェアを書く方法に合っているからだ。大企業では、ソフトウェアは大規模な(そして頻繁に変わる)平凡なプログラマーのチームによって書かれる傾向がある。オブジェクト指向プログラミングは、これらのプログラマーに、誰もが過度の損害を与えることを防ぐ規律を課す。代償は、結果として得られるコードがプロトコルで膨れ上がり、重複でいっぱいになることだ。これは大企業にとっては高すぎる代償ではない。なぜなら、彼らのソフトウェアはおそらく膨れ上がり、重複でいっぱいになるだろうからだ。
-
オブジェクト指向プログラミングは、多くの作業のように見えるものを生成する。ファンフォールドの時代には、ページに5行か10行のコードしか置かず、その前に20行の精巧にフォーマットされたコメントを置くタイプのプログラマーがいた。オブジェクト指向プログラミングは、これらの人々にとってクラックのようなものだ:それはあなたがすべてこの足場をソースコードに組み込むことを可能にする。Lispハッカーがリストにシンボルをプッシュすることで処理するかもしれない何かが、クラスとメソッドのファイル全体になる。だから、自分自身や他の誰かに、あなたが多くの作業をしていると説得したい場合には良いツールだ。
-
もし言語自体がオブジェクト指向プログラムであれば、ユーザーによって拡張できる。まあ、多分。または、オブジェクト指向プログラミングのサブコンセプトをアラカルトで提供することで、さらに良いことができるかもしれない。例えば、オーバーロードは本質的にクラスに結びついていない。私たちは見るだろう。
-
オブジェクト指向の抽象化は、シミュレーションやCADシステムのような特定の種類のプログラムの領域にきれいにマッピングされる。
私は個人的には、オブジェクト指向の抽象化を必要としたことはない。Common Lispには非常に強力なオブジェクトシステムがあり、私は一度も使ったことがない。私は(例えば、クロージャでいっぱいのハッシュテーブルを作るなど)多くのことをしてきたが、それらはより弱い言語ではオブジェクト指向の技術を必要とするだろうが、私はCLOSを使わなければならなかったことは一度もない。
多分私はただ愚かか、あるいはアプリケーションの限られたサブセットで働いてきただけかもしれない。自分のプログラミングの経験に基づいて言語を設計するには危険がある。しかし、良い考えだと思われているからといって、自分が必要としたことのないものを入れることは、さらに危険のように思える。