2004年05月01日
川俣晶の縁側ボツ原稿の墓場 total 4497 count

オータムマガジン用ボツ原稿 「C#対Javaの議論の不可能性とは何か?」

Written By: 川俣 晶連絡先

 オータムマガジン用に書きかけられたものの、結局書き上げて公開する気が途中で失せたボツ原稿です。

 これは、あくまでボツ原稿を見たいという奇特な人のために公開されるものであって、それに該当しない人は読まないようにお願いします。また、ボツ原稿ですので、ノークレーム、ノーリターンでお願いします (笑)。

C#対Javaの議論の不可能性とは何か? §

 前振り

 この議論がうまくできない理由はいくつかあます。

  • Javaあるいはオブジェクト指向のポジションの定説と実態の乖離
  • C#擁護者ですら、実は多くの文脈をミスリードしていること
  • C#が立脚する思想に明瞭な名前や教典が不在であること

 これらについて書いてみます。

Javaあるいはオブジェクト指向のポジションの定説と実態の乖離 §

 たとえば、ガベージコレクションによるメモリ管理の自動化というのがJavaの新しい機能であり、特徴であるとされます。多くの人が、これを当然のこととして受け入れていて、議論の前提とします。実は、C#の擁護者ですら、そのように思い込んでいる事例が多く見られます。

 しかし、マイクロソフトのプログラム言語であるVisual Basicなど、メモリ管理が自動化されているプログラム言語は昔からいくつもあります。つまり、Visual Basicを使っている時に、プログラマがうっかり確保したメモリを解放するコードを書き忘れてメモリリークするような事態は、通常は発生しません。Visual Basicではオブジェクトの寿命を参照カウント方式で管理しており、参照が無くなればオブジェクトは消えて無くなります。

 それから、ガベージコレクションの方はもっと歴史が古く、初期の8bitパソコン用のマイクロソフト製BASICインタプリタでも、文字列領域を管理するためにガベージコレクションの機能が備わっていました。

 つまり、このような視点から見た場合、Javaが実現したことは、既存のマイクロソフト製品で使われていたガベージコレクションとメモリの自動管理というアイデアを統合し、それをもっと新しいアルゴリズムでスマートに実現して見せたに過ぎません。つまり、これは、革新と言うよりは、改良に過ぎません。

 では、どうしてJavaにおいてガベージコレクションによるメモリ管理の自動化が画期的な新しい機能として理解されるのでしょうか。その理由は、痛いほどにメモリ管理が自動化されていなかったC++と対比されて受け止められたためかもしれません。しかし、この世に存在するプログラム言語がC++だけであるはずもありません。では、どうして、メモリ管理の自動化ならうちの方が先だと他のプログラム言語の信奉者が叫ばなかったのでしょうか。おそらく、その理由は、メモリ管理の自動化があまりにも当たり前すぎる当然の機能だったからではないかと思います。

 少なくとも、使われなくなったメモリの回収を即時に行わず、ガベージコレクションまで遅延するというアイデアはJavaの特徴と言っても良いと思いますが、Javaが元祖であるとまで言うのは、たぶん言い過ぎです。(GUIはMacintoshの特徴であると言えるが、Macintoshが元祖と言ったら言い過ぎであるのと同じような意味で)

 これは1つの例ですが、実際に、議論にあたって前提となる常識、定説、公理が実態と乖離しているものは珍しくなく、これが議論の不可能性を生じさせます。議論の対象となっている問題に対して、意見を訂正させることは不可能ではありませんが、前提を訂正させることは著しく難しいと言わざるを得ません。また、滅多にあり得ない事態のような気がしますが、前提の訂正を受け入れてしまうと議論そのものが不成立に終わることになるような気がします。この場合も、やはり議論の不可能性に通じます。

C#擁護者ですら、実は多くの文脈をミスリードしていること §

 実はC#擁護者でありながら、全くJava擁護者と同じようなパラダイムの中にいる人を見受けることがあります。極端な例を挙げれば、完全にJava擁護者と同じ趣旨の考え方を披露した上で、「でも、マイクロソフトの製品なら普及するから、これを使っていかなくちゃ」というように締めくくります。これは2重の意味で間違った態度と言えますね。まず、マイクロソフト製品が必ず普及しないことは歴史が証明していますが、それに対する勉強不足。そして、C#を見ずにマイクロソフトしか見ていない視線の錯誤があります、

C#が立脚する思想に明瞭な名前や教典が不在であること §

 昔、C++の普及が始まった頃に、CのエキスパートがC++を見て、様々な問題を指摘して、こんなものは駄目だと一蹴するような状況がよく見られました。

 C++は、Cに対してほぼ上位互換の言語仕様を持つプログラム言語です。それゆえに、ベターなCとして使うことが可能であり、実際にそのようなことが行われた事例もあります。しかし、C++の本来の目的はオブジェクト指向プログラミングを行うことにあります。オブジェクト指向プログラミングは、構造化プログラミング言語であるCとは異なる使い方を要求される全く別個のパラダイムです。

 そこで、オブジェクト指向プログラミングを行う立場でC++を推進した人達は、構造化プログラミング言語であるCのエキスパート達から攻撃を受ける立場に立たされることになりました。もちろん、話が噛み合うはずもありません。議論は成立しないのです。構造化プログラミング言語であるCのエキスパート達にとっての常識、前提、世界観、価値観などは、オブジェクト指向プログラミングのそれらとは一致しないのです。それゆえに、個々の論点を立てて議論を行うということすら困難でありすぎます。もし、行おうとしても、オブジェクト指向プログラミングとは何かを1から教えるオブジェクト指向プログラミング入門講座になるだけです。そして、手取り足取り基礎から教えられるような事態を、エキスパート達は受け入れることはできないでしょう。それは、一種の議論の不可能性であると言えます。

 このような事態に対して対処するために、「オブジェクト指向プログラミングを勉強してから出直して来い」と言う方法がありました。

 このような言い方は、問題の所在が個々の論点ではなく、1つの大きな体系にあることを示し、かつ、それに「オブジェクト指向プログラミング」というラベルを貼ることで明確化する機能を持ちます。この時点で、この台詞を聞く側は「オブジェクト指向プログラミング」を知りませんので、具体的に何が問題になっているかは分かりません。しかし、「オブジェクト指向プログラミング」と名付けられた問題があることは認識されます。これによって、CとC++の間のパラダイムの相違の混迷を整理する糸口にすることができたかもしれません。

 C#について語るJavaプログラマを前にして私が連想するのは、以上のような状況です。つまり、パラダイムが違うにもかかわらず、自分の知っているパラダイムで全てを解釈しようとする態度に対して、議論の不可能性に直面して困り果ててしまうという状況です。

 そう、オブジェクト指向を知らないCのエキスパートが明らかにずれたC++批判を行うのを聞くような気持ちで、JavaのエキスパートのC#への批判を聞く、という類似性を、私個人としては確かに感じることがあるのです。

 しかし、その後の対処方法は同じではありません。

 CとC++の時には、「あなたが知らないパラダイムはオブジェクト指向プログラミングと呼ばれるものです」と名前を告げて容易に語り得るものでした。しかし、JavaとC#の場合には、このように容易に語り得る名前がありません。これを読めば分かるという思想書のような教典もありません。そのため、同じような構図であると感じられながら、JavaとC#の議論の不可能性を解消する方法が見いだせません。

 では、名前が無いことは、C#の欠陥なのでしょうか。最も悩ましいことは、この問いの答えに含まれます。おそらく、名前がないことはC#が立脚するパラダイムが必然的に内包する特徴の一部であって、それこそが進歩であると。そのように感じることができるのです。ですから、名前を付けて議論の不可能性を解決するという方法を取ることはできません。

 では、これに関する結論はどういうことになるのかというと、議論が不可能である状態が自然なあるべき状態である以上、そのままで良いと思います。身も蓋もない結論ですが、パラダイムの相違が議論の不可能性を生むことは、よくあることですから、それは自然な結論です。

名前を安易に付けることの問題とは何か §

 最近、オブジェクト指向は、安易にオブジェクト指向という便利な言葉を生み出してしまったことに大きな問題があると感じるようになりました。

 結局のところ、オブジェクト指向という便利な言葉が存在することによって、オブジェクト指向を理解したと錯覚した人達と、失敗の理由を自分がオブジェクト指向を理解していないからとしてしまう人達を大量に生み出しているような印象を受けます。

 (以下、続きが書かれることはありませんでした)