オブジェクト指向プログラミングを神格化するような記事が流れてきたので，僕が知っている問題点について書いてみたいと思います．僕がまだ学生だったころは，オブジェクト指向の評価もまだそれほど定まっていなくて，オブジェクト指向の次はどんなパラダイムが出てくるかとか普通に学生レベルで議論していたものですが，ここまで強大になってしまうとそれを打ち負かそうなんて気にはならないのでしょうか．僕にはオブジェクト指向が普遍的な真理という感じは全然しなくて，ここまで使われてる理由は，現実的なテクノロジーで大きなシステムを作らなければならない必要性のほうを優先した結果であると認識しています．オブジェクト指向がその後の25年ほどもずっと安定してその地位を保てるほど素晴らしいものとは思えないのです．
以下で上げる問題点は，個別に解決している研究はあったりしますし，僕も論文を書いたりしましたけど，実際の言語に導入されていなければあまり意味がないので，問題点として指摘させていただきました．論文じゃないので，軽い気持ちで読んでいただければと思います．
１）メッセージの流れが見えない
オブジェクト指向においてメッセージのやり取りほど重要なものはないのに，そのやり取りの様子がプログラム上で表現できていません．メッセージの送信は，繰り返しや条件分岐などの制御文によって作られた関数呼び出しの副作用として間接的に表現されます．一方受信の方はもっと見えなくて，例えばその時のオブジェクトの内部状態によって受信できるメッセージの種類が変わるはずなのに，そういった制御や抽象化ができません．最初に初期化のメッセージを受信した後，処理のメッセージをいくつか受信して，終了のメッセージを受信する，といったプロトコル的な記述もできません．
２）オブジェクトのつながり具合が手続きでしか表現できない
次に大事なのがオブジェクトのつながり具合です．たとえばＭＶＣという３つのオブジェクトの集まりで一つの部品を作るような場合があります．プログラムは，Ｍ，Ｖ，Ｃそれぞれが同じ相手とつながっていることが前提でつくられます（たとえば，Ｍが知っているＶと，Ｃが知っているＶは同じものである，といったことです）．しかし，このつながり具合が正しいかどうかを保証する方法がありません．木構造をオブジェクトで作るとき，自分の子供は全員自分を親として見ているか．こういったつながりを手続きで頑張って作るので，間違えが入る可能性があります．間違えをできるだけ入らないようにするために，オブジェクトの外側からは内側を触れないようにカプセル化しますが，そういう制約はオブジェクト指向自身が自由度が高すぎる，逆に言うと何も保証しない貧弱であるから必要なのです．
３）ユーザレベルでの部品化再利用に全然なっていない
僕が素晴らしいプログラムの部品化再利用の例だと思っているのがＵＮＩＸのパイプラインです．これが通じる人はどれくらいいるのかな．コマンドの出力が次のコマンドの入力になるようにパイプでつないで表現するものです．パイプが人間にとってすごく使いやすい理由は，そこを流れるデータが人間に見える形式だったからです．見えるから次のコマンドにどんな処理をさせればよいか考えやすくなります．何か動きがおかしければ，途中に流れている文字列を見ればわかります．典型的な入力データをエディタで作ってもよいですし，途中の処理が特殊すぎてわざわざプログラムで処理しなくてもよいような場合，人間がエディタ上で手作業で編集してもよいわけです．テキストデータという共通のデータ形式の上で人間とコンピュータが協調して問題を解いていたという感覚がありました．
こんな素晴らしい仕掛けが使われた時代はそんなにコンピュータが速かったわけではありません．それでもバイナリーではなくテキストの10進表記で数を表すという，実に無駄な方法が人間の利便性を優先して使われていたということに敬意を表します．
1次元にコマンドを並べて処理を順に行うような単純な処理だけですむ時代は終わりました．パイプに代わるもっと複雑なコマンドの組み合わせ方を発明しなければなりません．パイプは一方向の情報の流れでしたが，情報は双方向の流れを許すべきです．
僕はUNIXにX-Windowというウインドウシステムが入ってきたとき，次世代のパイプが発明されるのかとワクワクしてましたが，結局まだ誰もそれを発明できていません（僕が知らないだけであるのかもしれません）．部品化はオブジェクト指向にとってかわられ，プログラムの中は閉ざされ，人間は遠ざけられました．
北大の田中先生のIntelligentPadにその可能性を感じましたが，結局はオブジェクトの合成という非常に難しい問題がその前に立ちはだかりました．
そうこうしているうちに，WWWの大爆発が起こって全部吹っ飛びました．
４）知識表現が手続き側に偏っている
プログラミングという処理っぽい呼び方ではなく，もう少し広い意味を込めて知識表現と呼ぶことにします．プログラムはもちろん知識表現の一部です．たとえば，EXCELの表も知識表現ですし，構造をもったデータは知識表現です．オブジェクト指向の何が悲しいかというと，構造をもったデータを直接作り出すことはできないということです．手続きを使って変換するしかありません．たとえばLISPではコンピュータが処理するデータ構造を人間が直接入力することができます．そういう人間とコンピュータの仲の良い関係がオブジェクト指向では消えてしまってます．
５）オブジェクト指向は人間をだましている
オブジェクト指向で作られた典型的なグラフィカルなプログラムを考えましょう．オブジェクトには内部状態があります．その内部状態を更新させることが唯一の計算です．その内部状態を人間にみせるためのプログラムと，人間が見ているもの（画面）に対するマウスやタッチの操作を解釈して内部状態を更新するためのプログラムがあります．これは上の例ででてきたＭＶＣということなんですが．だましているといったのは，Ｍは内部に存在しますけれども，Ｖがどう作られたかで見え方が違ってきます．同じ見え方でもＭの中身が違っていたり，同じ中身でも見え方が違っていたり，ということが平気で起きます．真逆はLISPです．LISPはコンピュータが見ているメモリーの構造と人間が見ているＳ式とが1対1の関係になるので，つまり人間とコンピュータが同じものを見ているという安心感があります．オブジェクト指向はコンピュータと人間が同じものを見ている感がしません．コンピュータがすごく頑張って人間にすごいものを見せている（もしくはだましている）という感じです．
こうなっちゃった理由は，コンピュータに課せられた役割が，これまでプログラムを作る人と使う人とが一体となっていた時代から，作る人と使う人とが明確に分かれた時代に変わってきたということなのかもしれません．UNIXのテキストは人間にわかりやすいといっても，ビットマップのテキストよりは見栄えがしないわけで，作る人と使う人が一緒なら我慢もできましょうが．逆に，使うだけの人にとっては，上手にだましてもらったほうがいいわけですし，よりかっこよくだました方がお金が儲かるという事情もあったのでしょう．
６）オブジェクト指向は貧乏
オブジェクト指向が活躍した時代はメモリーが非常に少なくどう節約するかが重要でした．なのでよく使われていた例は，列というものがあって，その列をどのように扱いたいかによって実行の効率が変わるので，使用法に適した実装を選んで効率をよくすることができる．しかしアルゴリズムはそのデータ構造の影響を受けないように計算方法だけ書けばよい．そんなことが言われていた時代でした．つまり，一度書いたアルゴリズムはいろんなデータ構造に対して，効率の良い実行ができるというものです．
しかし今は，メモリーもふんだんにあって実行速度の差もそれほど重要ではなくなってきたので，そんな実装方法に依存しないアルゴリズムという貧乏なことを言わなくてもよくなりました．万能なデータ構造を一つ決めて，アルゴリズムは全部その構造に対して作ってしまえばよいのです．LISPみたいなものです．ただし，LISPの時代から何が変わったかというと，扱うデータが木構造のように単純ではなく，グラフ構造になったこと．一つのスレッドではなくマルチスレッドでかつ分散になったこと．オブジェクトが複雑に参照しあっているようなグラフ構造をLISPのS式のようなシンプルで汎用性のある記法で記述しなければならないということです．なのでS式的な今風の拡張が求められています．
７）関係を記述できない
メッセージは単項演算なので，複数のオブジェクト間の関係を表現するのが苦手です．ある一つのオブジェクトに，起きろ，歩け，といった命令をするだけなら簡単です．それに対して，二つのオブジェクトが関係する命令，たとえば二人に対して，ぶつかれ，ならべ，という命令が苦手です．通常のオブジェクト指向では，関係するオブジェクトのどれか一つを特別に選んで，それに対するメッセージとして表現します．他のオブジェクトはそのメッセージの引数として渡されます．２）で言ったようなつながり具合を表現したければ，メッセージの受信側に選ばれたオブジェクトが責任をもって引数で渡されたほかのオブジェクトどうしをつながなければなりません．
Prologは関係を表現できます．というか関係しか表現できません．たとえば，Ａ＋Ｂ＝Ｃという式があったとします．普通の言語ではＡ＋Ｂの計算をして，Ｃのメモリーにその値を書き込むという解釈をします．ＡとＢの値が決まっていてＣは未定義だったり，Ｃの新しい値としてこういう計算をしました．それに対して，ここで表現した式は計算の方法ではなくあくまでも式というか変数同士の数学的な関係を表していると解釈できます，たとえばこの式があったとき，Prologでは「Ｂが２０，Ｃが５０のときＡは何でしょう」という聞き方にもこたえることができるのです．
計算の方向まであとで決められるくらいの自由度はともかく，オブジェクト指向がメッセージのやりとりにこだわっていると，関係を表現するのがすごく大変ということはわかっていただけたでしょうか．
オブジェクト指向の問題点のうち，ごく一部はビスケットの設計方針に影響を与えています．たとえば，コンピュータが裏で人間のために頑張るというのではなく，コンピュータと人間が同じものを見ている感というのを大事にしている部分などですが．人間とコンピュータの関係がどうあってほしいかといった思いも込められています．
以下で上げる問題点は，個別に解決している研究はあったりしますし，僕も論文を書いたりしましたけど，実際の言語に導入されていなければあまり意味がないので，問題点として指摘させていただきました．論文じゃないので，軽い気持ちで読んでいただければと思います．
１）メッセージの流れが見えない
オブジェクト指向においてメッセージのやり取りほど重要なものはないのに，そのやり取りの様子がプログラム上で表現できていません．メッセージの送信は，繰り返しや条件分岐などの制御文によって作られた関数呼び出しの副作用として間接的に表現されます．一方受信の方はもっと見えなくて，例えばその時のオブジェクトの内部状態によって受信できるメッセージの種類が変わるはずなのに，そういった制御や抽象化ができません．最初に初期化のメッセージを受信した後，処理のメッセージをいくつか受信して，終了のメッセージを受信する，といったプロトコル的な記述もできません．
２）オブジェクトのつながり具合が手続きでしか表現できない
次に大事なのがオブジェクトのつながり具合です．たとえばＭＶＣという３つのオブジェクトの集まりで一つの部品を作るような場合があります．プログラムは，Ｍ，Ｖ，Ｃそれぞれが同じ相手とつながっていることが前提でつくられます（たとえば，Ｍが知っているＶと，Ｃが知っているＶは同じものである，といったことです）．しかし，このつながり具合が正しいかどうかを保証する方法がありません．木構造をオブジェクトで作るとき，自分の子供は全員自分を親として見ているか．こういったつながりを手続きで頑張って作るので，間違えが入る可能性があります．間違えをできるだけ入らないようにするために，オブジェクトの外側からは内側を触れないようにカプセル化しますが，そういう制約はオブジェクト指向自身が自由度が高すぎる，逆に言うと何も保証しない貧弱であるから必要なのです．
３）ユーザレベルでの部品化再利用に全然なっていない
僕が素晴らしいプログラムの部品化再利用の例だと思っているのがＵＮＩＸのパイプラインです．これが通じる人はどれくらいいるのかな．コマンドの出力が次のコマンドの入力になるようにパイプでつないで表現するものです．パイプが人間にとってすごく使いやすい理由は，そこを流れるデータが人間に見える形式だったからです．見えるから次のコマンドにどんな処理をさせればよいか考えやすくなります．何か動きがおかしければ，途中に流れている文字列を見ればわかります．典型的な入力データをエディタで作ってもよいですし，途中の処理が特殊すぎてわざわざプログラムで処理しなくてもよいような場合，人間がエディタ上で手作業で編集してもよいわけです．テキストデータという共通のデータ形式の上で人間とコンピュータが協調して問題を解いていたという感覚がありました．
こんな素晴らしい仕掛けが使われた時代はそんなにコンピュータが速かったわけではありません．それでもバイナリーではなくテキストの10進表記で数を表すという，実に無駄な方法が人間の利便性を優先して使われていたということに敬意を表します．
1次元にコマンドを並べて処理を順に行うような単純な処理だけですむ時代は終わりました．パイプに代わるもっと複雑なコマンドの組み合わせ方を発明しなければなりません．パイプは一方向の情報の流れでしたが，情報は双方向の流れを許すべきです．
僕はUNIXにX-Windowというウインドウシステムが入ってきたとき，次世代のパイプが発明されるのかとワクワクしてましたが，結局まだ誰もそれを発明できていません（僕が知らないだけであるのかもしれません）．部品化はオブジェクト指向にとってかわられ，プログラムの中は閉ざされ，人間は遠ざけられました．
北大の田中先生のIntelligentPadにその可能性を感じましたが，結局はオブジェクトの合成という非常に難しい問題がその前に立ちはだかりました．
そうこうしているうちに，WWWの大爆発が起こって全部吹っ飛びました．
４）知識表現が手続き側に偏っている
プログラミングという処理っぽい呼び方ではなく，もう少し広い意味を込めて知識表現と呼ぶことにします．プログラムはもちろん知識表現の一部です．たとえば，EXCELの表も知識表現ですし，構造をもったデータは知識表現です．オブジェクト指向の何が悲しいかというと，構造をもったデータを直接作り出すことはできないということです．手続きを使って変換するしかありません．たとえばLISPではコンピュータが処理するデータ構造を人間が直接入力することができます．そういう人間とコンピュータの仲の良い関係がオブジェクト指向では消えてしまってます．
５）オブジェクト指向は人間をだましている
オブジェクト指向で作られた典型的なグラフィカルなプログラムを考えましょう．オブジェクトには内部状態があります．その内部状態を更新させることが唯一の計算です．その内部状態を人間にみせるためのプログラムと，人間が見ているもの（画面）に対するマウスやタッチの操作を解釈して内部状態を更新するためのプログラムがあります．これは上の例ででてきたＭＶＣということなんですが．だましているといったのは，Ｍは内部に存在しますけれども，Ｖがどう作られたかで見え方が違ってきます．同じ見え方でもＭの中身が違っていたり，同じ中身でも見え方が違っていたり，ということが平気で起きます．真逆はLISPです．LISPはコンピュータが見ているメモリーの構造と人間が見ているＳ式とが1対1の関係になるので，つまり人間とコンピュータが同じものを見ているという安心感があります．オブジェクト指向はコンピュータと人間が同じものを見ている感がしません．コンピュータがすごく頑張って人間にすごいものを見せている（もしくはだましている）という感じです．
こうなっちゃった理由は，コンピュータに課せられた役割が，これまでプログラムを作る人と使う人とが一体となっていた時代から，作る人と使う人とが明確に分かれた時代に変わってきたということなのかもしれません．UNIXのテキストは人間にわかりやすいといっても，ビットマップのテキストよりは見栄えがしないわけで，作る人と使う人が一緒なら我慢もできましょうが．逆に，使うだけの人にとっては，上手にだましてもらったほうがいいわけですし，よりかっこよくだました方がお金が儲かるという事情もあったのでしょう．
６）オブジェクト指向は貧乏
オブジェクト指向が活躍した時代はメモリーが非常に少なくどう節約するかが重要でした．なのでよく使われていた例は，列というものがあって，その列をどのように扱いたいかによって実行の効率が変わるので，使用法に適した実装を選んで効率をよくすることができる．しかしアルゴリズムはそのデータ構造の影響を受けないように計算方法だけ書けばよい．そんなことが言われていた時代でした．つまり，一度書いたアルゴリズムはいろんなデータ構造に対して，効率の良い実行ができるというものです．
しかし今は，メモリーもふんだんにあって実行速度の差もそれほど重要ではなくなってきたので，そんな実装方法に依存しないアルゴリズムという貧乏なことを言わなくてもよくなりました．万能なデータ構造を一つ決めて，アルゴリズムは全部その構造に対して作ってしまえばよいのです．LISPみたいなものです．ただし，LISPの時代から何が変わったかというと，扱うデータが木構造のように単純ではなく，グラフ構造になったこと．一つのスレッドではなくマルチスレッドでかつ分散になったこと．オブジェクトが複雑に参照しあっているようなグラフ構造をLISPのS式のようなシンプルで汎用性のある記法で記述しなければならないということです．なのでS式的な今風の拡張が求められています．
７）関係を記述できない
メッセージは単項演算なので，複数のオブジェクト間の関係を表現するのが苦手です．ある一つのオブジェクトに，起きろ，歩け，といった命令をするだけなら簡単です．それに対して，二つのオブジェクトが関係する命令，たとえば二人に対して，ぶつかれ，ならべ，という命令が苦手です．通常のオブジェクト指向では，関係するオブジェクトのどれか一つを特別に選んで，それに対するメッセージとして表現します．他のオブジェクトはそのメッセージの引数として渡されます．２）で言ったようなつながり具合を表現したければ，メッセージの受信側に選ばれたオブジェクトが責任をもって引数で渡されたほかのオブジェクトどうしをつながなければなりません．
Prologは関係を表現できます．というか関係しか表現できません．たとえば，Ａ＋Ｂ＝Ｃという式があったとします．普通の言語ではＡ＋Ｂの計算をして，Ｃのメモリーにその値を書き込むという解釈をします．ＡとＢの値が決まっていてＣは未定義だったり，Ｃの新しい値としてこういう計算をしました．それに対して，ここで表現した式は計算の方法ではなくあくまでも式というか変数同士の数学的な関係を表していると解釈できます，たとえばこの式があったとき，Prologでは「Ｂが２０，Ｃが５０のときＡは何でしょう」という聞き方にもこたえることができるのです．
計算の方向まであとで決められるくらいの自由度はともかく，オブジェクト指向がメッセージのやりとりにこだわっていると，関係を表現するのがすごく大変ということはわかっていただけたでしょうか．
オブジェクト指向の問題点のうち，ごく一部はビスケットの設計方針に影響を与えています．たとえば，コンピュータが裏で人間のために頑張るというのではなく，コンピュータと人間が同じものを見ている感というのを大事にしている部分などですが．人間とコンピュータの関係がどうあってほしいかといった思いも込められています．