アークが特にオブジェクト指向でない理由

2001年1月

現在、オブジェクト指向プログラミングに対する一種の熱狂がありますが、私が知っている最も賢いプログラマーの中には、それにあまり興奮していない人もいます。

私自身の感覚では、オブジェクト指向プログラミングは場合によっては有用な技術ですが、あなたが書くすべてのプログラムに浸透させる必要はありません。新しい型を定義できるべきですが、すべてのプログラムを新しい型の定義として表現する必要はありません。

人々がオブジェクト指向プログラミングを好む理由は5つあり、そのうちの3つ半は悪い理由です：

オブジェクト指向プログラミングは、レキシカルクロージャやマクロのない静的型付け言語を持っている場合に興奮します。ある程度、これらの制限を回避する方法を提供します。（グリーンスプンの第十規則を参照。）

オブジェクト指向プログラミングは大企業で人気があります。なぜなら、それは彼らがソフトウェアを書く方法に適しているからです。大企業では、ソフトウェアは大規模（かつ頻繁に変わる）チームの平凡なプログラマーによって書かれる傾向があります。オブジェクト指向プログラミングは、これらのプログラマーに対して、誰か一人があまりにも多くの損害を与えないようにする規律を課します。その代償は、結果として得られるコードがプロトコルで膨れ上がり、重複に満ちていることです。これは大企業にとってあまり高い代償ではありません。なぜなら、彼らのソフトウェアはどうせ膨れ上がり、重複に満ちている可能性が高いからです。

オブジェクト指向プログラミングは、多くの見た目上の作業を生み出します。ファンフォールドの時代には、ページに5行または10行のコードしか書かず、その前に20行の詳細にフォーマットされたコメントを付けるタイプのプログラマーがいました。オブジェクト指向プログラミングは、これらの人々にとってはクラックのようなものです：それは、すべての足場をソースコードに組み込むことを可能にします。リスプハッカーがシンボルをリストにプッシュすることで処理するようなものが、クラスとメソッドの全ファイルになります。したがって、あなたが多くの作業をしていると自分自身や他の誰かを納得させたい場合には良いツールです。

言語自体がオブジェクト指向プログラムである場合、ユーザーによって拡張できます。まあ、そうかもしれません。あるいは、オブジェクト指向プログラミングのサブコンセプトをアラカルトで提供することで、さらに良いことができるかもしれません。たとえば、オーバーロードはクラスに本質的に結びついているわけではありません。見てみましょう。

オブジェクト指向の抽象は、シミュレーションやCADシステムのような特定の種類のプログラムのドメインにうまくマッピングされます。

私は個人的にオブジェクト指向の抽象を必要としたことはありません。Common Lispには非常に強力なオブジェクトシステムがありますが、私は一度もそれを使ったことがありません。私は多くのこと（例えば、クロージャで満たされたハッシュテーブルを作成すること）を行ってきましたが、それはより弱い言語で行うためにはオブジェクト指向の技術が必要だったでしょうが、私はCLOSを使う必要がありませんでした。

もしかしたら私はただ愚かで、限られたアプリケーションのサブセットで作業してきたのかもしれません。自分のプログラミング経験に基づいて言語を設計することには危険があります。しかし、良いアイデアだと思われるものを必要としたことがないのに入れることは、より危険に思えます。