C#の登場は、業界になにをもたらすのか？

プログラム言語のパラダイムシフト
「C#」という提案

川俣 晶
株式会社ピーデー
2000/8/24

■C#の登場〜Javaとの対立の構図

　2000年6月、マイクロソフト社は、情報通信の標準化団体であるECMAに対して、2つの新しいプロジェクトを提案した。1つは、C#（“シーシャープ”と発音する）と呼ばれる新しいプログラム言語であり、もう1つは、common language infrastructure（CLI)と呼ばれるプログラムの実行環境の標準である。

　これに先だって、非公式な情報として、マイクロソフト社は「COOL」と呼ばれるJava対抗言語を開発しているという情報が流れたことがある。ご存じの通り、マイクロソフト社は、WindowsというOSをデファクトスタンダードとすることで、パソコン業界に大きな影響力を行使している企業である。これに対して、サンマイクロシステムズ社の開発したJava言語は、一度書けばどのOS上でも動作するという機能を特徴とするもので、WindowsによるOSの独占を無意味にするテクノロジーであると言われている。従って、マイクロソフト社の利害を考えれば、当然、マイクロソフト社にとってJava言語は許容しがたいものである。これまで、マイクロソフト社は、自社にライセンスされたJava言語処理系に対して、Windowsに特化した特殊な機能拡張を施し、これがライセンス違反であると主張するサン・マイクロシステムズ社に裁判を起こされている。この流れから、Java言語に良く似た別の言語をマイクロソフト社が開発し、これによってJava言語の普及を妨げようとしている、という噂が、まことしやかに語られていた。これがCOOLと呼ばれる言語である。

標準化団体ECMAのページ

　C#は、このCOOLの製品版ではないかという観測が流れたが、マイクロソフト社は、C#がC++の1つの発展形であるとし、COOLではないと述べている。しかしながら、C#がJava言語の多くの特徴を取り込んでいるのは事実である。また、目的とする応用範囲も似通っており、C#がJava言語と比較されうる対象であることは間違いないだろう。

　もう1つ、ECMAに提案されたCLIはいったい何だろうか。実は、CLIと同じものを示しているらしいいくつかの名称があり、まず名前が明確ではない。Common Language Specification（CLS）、Common Language Runtime（CLR）といった言葉も聞かれる場合がある。これらは、同じか、あるいは互いに密接に連携する機能を示した用語だと思われるが、ここではCLIで統一して話を進める。CLIは、C#を始めとする現代的なプログラム言語の共通な実行環境である。つまり、さまざまなプログラム言語の実行ファイルを実行できる環境を提供するものだという。その実体は、中間言語とライブラリの集合体らしい。

　プログラムには、比較的人間にも分かりやすい書式で書かれたソースコードと、機械が解釈して実行できる機械語が存在する。プログラム言語の処理系（コンパイラ）が、ソースコードから機械語への翻訳を行うことで、実際に実行可能なファイルを得ることができる。しかし、しばしば、さまざまな理由で、ソースコードと機械語の中間的な表現である中間言語と呼ばれるものが使用される。中間言語は、現実に存在しないCPUの機械語として表現されることが多い。この実際に存在しないCPUを、仮想マシンと呼ぶ。

　中間言語を用いる理由は、筆者の知る限り、主に2つある。1つは、特定のCPUに依存しないプログラムを作成するためである。つまり、それぞれの現実のCPUの上で稼働する仮想CPUのシミュレーションソフトを使うことで、実際は異なる構造のCPUを持つマシン上で、まるで同じCPUが存在するかのように扱うのである。この典型的な例が、Java言語の実行環境である。Java言語のプログラムを実行するJavaVMのVMは、Virtual Machine、つまり仮想マシンのことである。もう1つは、プログラムサイズの圧縮である。現実のCPUよりも、よりメモリ効率の良い仮想マシンを使うようにすれば、よりプログラムのサイズを小さくすることができる。あまり知られてはいないが、初期のマイクロソフト製ビジネスアプリケーションソフトなどの中には、Pコードと呼ばれる特殊な仮想マシンのプログラムを含み、それによってメモリ容量を節約していた例がある。だが、メモリ容量が拡大している現在、このようなメリットを追求して仮想マシンを利用する例はあまり聞かない。

　このような知識を前提に考えると、CLIの目的は、「プログラム言語に依存しない実行環境」と言われているものの、「特定の環境に依存しない実行環境」としての側面も持っていることが推測される。これは、特定のOSに依存しないというJava言語の特徴と似通ったものと言える。つまり、CLIという視点から見た場合でも、やはり、Java言語との競合の可能性があり得る。

　このような構図で見る限りにおいて、「Java 対 C#＋CLI」のプログラム言語戦争勃発の熱い熱気が感じられるだろう。

　しかし……

■C++、C#、Javaに対する誤解

　パラダイムシフトとは、物事の大きな枠組み、考え方が変化することを意味する。従来の常識が通用しないような大きな変化のことを言う。C#＋CLIの出現は、パソコンとネットワーク業界全体に対する一種のパラダイムシフトをもたらしているように思える。

　筆者が痛感したのは、C#関連報道に、かなりとんでもないものがあるという事実だ。マイクロソフトがC#はC++の発展形であって、Java対抗言語ではないという主張に対して、あるWeb上の記事はこう論評している。

C#はインタプリタで実行されるからC++の高速性はない。だから、C++の発展形などではあり得ない。かといって、C#にはJava言語のようなどの環境でも実行できるという特徴もない……

　プログラム言語の選択を行う際、1990年代においては、高速性を要求されるならC++を使う。環境に依存しないプログラムが必要ならJava言語を使う……ということが常識として考えられてきた。その常識から考えれば妥当なことを言っているかのように思える。

　ところが、このような常識は、プログラム言語の性質や特徴とは、本質的に関係のないことだったのである。これらは、言語仕様ではなく、言語処理系の特徴と言える。つまり、C++という言語の仕様には、それが速いか遅いかという規定はまったく存在しない。ただ、Visual C++を始めとする多くのC++製品が、特定の環境に強く依存した機械語コードを生成することで、他のプログラム言語よりも高速なプログラムを作成できることが多い、というだけである。言語仕様を考える側は効率の善し悪しを意識しているのは事実だが、遅いC++処理系を作ったとしても仕様違反ではない。また、特定の環境に依存しないC++処理系を作ってはいけないという決まりもない。

　プログラム言語マニアの視点から見れば、Java言語の特徴は、非常によく洗練されたオブジェクト指向言語としての文法面にある。なぜC++言語よりJava言語の方が優れているのかと言えば、機能過多で分かりにくいC++よりも、思い切りダイエットして多くの機能を切り落としたJava言語の方が、ずっと分かりやすく、また、開発効率も高いためだ。つまり、まったく同じ機能を持ったプログラムを作成する場合、C++よりも、Java言語の方が、ずっと素早く、かつ、分かりやすく書けるということである。これこそが、Javaがプログラム言語として高い評価を得た真の理由である。

　しかし、このようなプログラム言語の特質に気付くことなく、Java言語イコールどのOSでも動くといった固定的なイメージで見ていた者達が相当数存在したようである。このような本質を見ない表面的な知識を常識として抱え込んでいても、1990年代は乗り切れた。だが、C#の出現が、この種の「たまたまそうだっただけで本質的には何の意味もない」常識の怪しさを露呈してしまったと言える。

　現実的に、Java言語が、C++の1つの発展形であることは間違いない。その証拠に、Java言語はC++言語から多くの構文を受け継いでいる。同じような意味で、C#もC++言語から多くを受け継いでいる。その意味で、C#がC++言語の1つの発展形であるとするのは、なんら問題はない。

　つまり、これからの時代、1990年代的な古い常識は捨てねばならない。1990年代にたまたまそうであったことと、年代は変わっても不変の真理であり続ける知識はきちんと区別しなければならない。そうしなければ、このパラダイムシフトは乗り切れないだろう。

■新しいプログラム言語はなぜ登場する？

　C#に対する根本的な疑問は、本当にC#は必要とされているのかということである。つまり、C++やJava言語が既にあるのに、新しい言語を作り出す必要が本当にあるのか、ということである。

　この問いに答えることは、じつは容易ではない。なぜかといえば、たいていのプログラム言語は、たいていのアプリケーションソフトを記述できるからだ。そのため、1つのプログラム言語だけを学び、それを使い続けているプログラマには、他の言語の必要性が理解できないことが多い。つまり、「そういう処理なら私が知っている言語でも記述できるよ。なのに、どうして他の言語を使う必要があるんだい？」ということだ。

　実は、多くの場合、その処理が記述できるか否かということは、新しいプログラム言語の必要性とは直接関係がない。たとえば、世界最初の高級言語と呼ばれるFortran言語というものがある。すでに時代遅れになって利用者は非常に少ない。しかし、現在作成されている大抵のプログラムは、理論的にはFortranでも記述可能なのである。にも関わらず、誰もFortranを使わない理由は簡単である。生産性が著しく低いのである。つまり、ある機能を持ったプログラムを作成する場合に、それに要するマンパワーと時間が大きいということだ。純粋に言語の文法だけに限れば、新しいプログラム言語は、プログラマの作業効率をよりアップさせるために生まれてくるものだと言っても過言ではない。つまり、それが、FortranがC言語に取って代わられ、更にC++に取って代わられ、Java言語に取って代われる理由なのである（言語マニアの方々は気になっているだろうが、もちろん、話を単純にするために、いくつかの側面に関しては意図的に目を瞑っている）。

　だが、Java言語がそれほど優秀であるならば、他の言語を持ち出して、それよりも生産性を高めることなど可能なのだろうか？ その答えは、イエスであると考える。筆者も、Java言語で実用ソフトを記述することを通じて、Java言語の光と、そして目立たない影を実感することができた。登場当初は素晴らしいと思えたJava言語も、時間と共に本当の意味での実用性に関する評価を下せるだけの充分な実績がたまりつつある。

　Java言語の本質は、一種のミニマリズムである。言語仕様からなくても構わないものをすべて取り除き、スリムで分かりやすくすることが、一種のJava言語らしさである。ところが、このミニマリズムは完全には徹底されていない。ある程度、実際に実行される状況での効率を意識して、文法をミニマムにしきれていない部分がある。たとえば、Java言語は情報をオブジェクトと呼ばれる情報単位に格納して扱うオブジェクト指向言語であるが、単純な数値（整数や実数）はオブジェクトになっていない。数値の処理は利用される頻度が多く、しかも単純であるため、仮想マシンが簡単に実行できるようになっている。しかし、処理方法にもよるが、オブジェクトにしてしまうと、余計な処理が必要とされたり、余計なメモリを消費したりする。つまり実行効率が落ちる。そのためか、Java言語は単純な数値をオブジェクトではないとしている。その結果として、オブジェクトに対して用意されたさまざまな機能に対して、数値はそのまま利用できないのである。たとえば、Java言語のクラスライブラリには、Vectorと呼ばれる任意の数のオブジェクトを格納できる便利な機能がある。ところが、これは対象がオブジェクトであるため、数値を入れることができない。その結果、ラッパオブジェクトという数値の入れ物となる専用オブジェクトに数値を入れてからでないと、Vectorに格納することができない。もちろん、ラッパオブジェクトの利用は、プログラムの本質とは関係の無いもので、Java言語の言語仕様以外にそれを使わねばならない根拠は何もない。

　詳細は省くが、他にもいくつか、Java言語には気になる点がある。つまり、より素早く、少ない労力でプログラムを作成するという目的を考えた場合、Java言語は最善とは言えない可能性が出てきている……これが2000年現在の我々のいる時代の状況と言えるのではないか。これは、マイクロソフト社とサンマイクロシステムズ社の市場支配権を巡って行われている争いとは別次元の問題と言える。

■本当に100％ Pure Javaはいいものか？

　Java言語の文法を離れて、実行環境のことを考えてみよう。言うまでもなく、実行面でのJava言語の特徴は、特定の環境に依存しない、ということである。当然のことながら、1回プログラムを書けば、どんな環境でも実行できるという理想は魅力的である。ソフトハウスであれば1回開発するだけですべての環境のユーザーが顧客になり得るし、互換性のないコンピュータが絡み合っているシステムの面倒を見ている管理者ならソフトの評価を1回で済ませることが可能になるわけだ。

　確かに理想はその通りだと思う。また、筆者は、昔から不必要に環境依存したプログラムは書くべきではないという考え方も持ってきた。MS-DOSの時代には、特定ハードウェアに依存したプログラムを書くことが常識であったが、そんな時代に、MS-DOSであればハードウェアを問わずに動くプログラムを作成したりもした。特定環境に依存しないプログラムの有用性は、人一倍わかっているつもりだ。

　しかし、実際にJava言語でプログラムを書いていると、99％までは書けるのに最後の1％に手が届かないという状況にしばしば直面した。つまり、OSに含まれている機能が存在しているのに、Java言語のAPIにそれに対応するものが存在しない、ということだ。Java言語ではAPIを通してさまざまな機能を利用するからこそ、100％ Pureになれるのである。直接OSの機能に手を出しては、そのOSでしか動作しないプログラムになってしまう。これでは、100％ Pureの理想を実現することはできない。

　こんなとき、どうすれば良いのだろうか。Javaカンファレンスの依頼で、Internet Week'98のJavaカンファレンスのセッションで話したときは、この問題を説明し、99％ Pure Java主義という考え方を提案した。これは、環境に依存する必然性がない部分はPureに記述し、本当にやむを得ない箇所のみ依存性のあるプログラムを記述するという考え方である。しかし、100％ Pureの理想に燃える聴衆の方々には、あまりウケが良くなかったようである。だが、世の中には、100％ Pureでは意図した機能をプログラムに書けないことも存在するのである。その場合、100％ Pureを取るか、機能を取るかという選択を迫られることになる。だが、プログラムの仕様の決定権が自分自身に無いときは、あまり選択の余地はない。クライアントが、機能の方が重要だと考えた場合は、100％ Pureという理想を捨てるしかない。

　別の角度から考えてみよう。Java言語はネットワークを強く意識しているので、ネットワーク上のどのコンピュータでも同じプログラムが実行できねばならない、と考えられている。だが、すべてのプログラムがネットワーク上に流れる訳ではない。実際には、特定のコンピュータでしか実行しないものや、極端なことを言えば、目の前のパソコンで1回実行したら、そのまま捨てても良い、というようなプログラムも存在する。そういうプログラムを開発する場合は、そのプログラムが100％ Pureであるという状況には何の意味もない（開発に使用するプログラムの部品が100％ Pureであるという話なら意味がある）。たとえば、OSに用意された機能を呼び出せば簡単に記述できるのに、100％ Pureであろうとすると、非常に回りくどいプログラムを書かねばならない場合もある。こういう場合は、100％ Pureを守ろうとすること、そのものが無意味である。

　この話をまとめるとこういうことになる。100％ Pureであることはメリットも多い。だが、100％ Pureであることしか許さないような考え方は現実に即さない場合がある。問題は、どう上手く、Pureであることと、環境依存であることを切り分け、バランスを取るかにある。

■Javaの弱点をうまくカバーするC#

　筆者の見る限り、新しいC#という言語は、Java言語の弱点をよく研究し、それをカバーするように作られていると感じられる。一例として、上で例に挙げたJava言語の問題点に関して説明しよう。まず、単純な数値がオブジェクトではないためにラッパオブジェクトという回りくどい機能を使わねばならない点に関しては、boxing／unboxingという機構を導入することで対処している。これは、単純な数値を単純な数値として使うだけなら、そのまま処理するものの、オブジェクトであるかのように扱おうとした瞬間に、自動的にラッパオブジェクトが生成されて、オブジェクトに変身してしまうのである。この処理は、コンパイラが自動的に判断して行うため、Java言語のようにプログラマがいちいちソースコード上にラッパオブジェクトを生成するコードを書かなくても良い。つまり、処理系の負担を増やすことで、プログラマの負担を減らしていると言える。

　また、特定の環境に依存するコードを記述することを許しており、実際にWindowsのWin32 APIやCOMオブジェクトにアクセスすることも可能だとアナウンスされている。しかし、これが可能になるのは、特別に指定された範囲だけに限られるようである。つまり、特殊な構文によって、機種依存性のあるコードであると宣言した箇所にのみ、このような依存コードを記述できる。そのような指定がなされなければ、おそらく、依存コードを書いてもエラーになるのだろう。これは、もしかしたら、筆者が主張した99％ Pure Java主義と似通った考え方かもしれない。また不必要に環境依存コードを記述することを阻止する抑止力となることも予測される。たとえば、高度な知識を持たない一般的なプログラマは、そのような高度な機能を使うことなく、自動的に依存性のないコードを記述するようになるだろう。

　このように、C#という新しい言語は、Java言語の弱点をうまくカバーし、より効率の良い開発環境を提案しているかのように見える。実際に、マイクロソフト社内では、すでにいくつかの製品がC#によって開発されているらしい。また、先日のアメリカで行われたPDC（Microsoft Professional Developers Conference）では、参加者に、C#の処理系のテストバージョンが配布されたという。少なくとも、C#は、絵に描いた餅（ぺイパーウェア）ではないようだ。まだ、C#が本当に実用的かどうかの判断を下すには早い。しかし、ポストJava言語、ポストC++言語として、新しい主力開発言語の座を獲得する可能性はある、と考えても良いだろうと思う。

■1つの言語にこだわる時代は終わった

　さて、ここまでの話だけでも、相当世間の常識をひっくり返してきたという自覚がある。だが、これすらも小さな地震に過ぎないような激震がさらに続くかも知れない。

　C#がいかに良くできた新しい言語であるといっても、それは、Java言語の利用教訓を色濃く反映したbetter C++でしかない。それは、不連続な革命というよりは、連続性のある革新である。

　本当の爆弾は、C#言語よりも、CLIの方に隠されているのかも知れない。

　CLIはC#の実行環境だが、アナウンスを見て分かる通り、C#だけの実行を意図したものではない。先日のPDCでは、17種類のプログラム言語が、実行可能であるという報道もある。これには、COBOLのようなビジネス系の言語や、研究者やマニアしか使わないような名の知られていない言語などが並んでいた。これらの言語は、マイクロソフトが供給するものではなく、それぞれの言語のオーソリティがCLIをターゲットにした処理系製品を開発する、という形になるようである（これは、世間の印象と違って、マイクロソフトが新しいマーケットを創出しているように見え、とても興味深いのだが、この話題は本筋と離れるので割愛する）。

　この17種類の中にJava言語が含まれないのは、マイクロソフトとJava言語の間の冷え切った関係を暗示しているかのようだ。だが、その話題は政治的な色彩が強いものだと思われるので、ここでは深く触れない。

　重要なことは、CLIの上では、これらの言語のプログラムがすべて共存することである。つまり、どの言語で書いたプログラムであっても、CLI環境があるすべてのマシンで実行可能であると推測されるからだ（もちろん、環境依存コードなどが入っていないことは条件になるだろうが）。また、それだけでなく、異種言語を混在させたプログラムを開発できるらしい。C#で作ったクラスをVisual BASICで継承できるという情報もある。ただ単に共存できるだけでなく、相互に複雑に絡み合ったコードも記述できるようだ。

　このような本格的な複数言語の開発環境が本当に現実のものとして得られた場合、プログラム言語を1つに絞り込む必要が無くなる。そうすると、本当に適材適所でプログラム言語を変えるという方法論も、1つの選択肢となる。

　もちろん、わざわざそんなことをするメリットがあるのだろうか、という疑問を感じる人もいるだろう。これに関して、筆者は「それが有益かも知れない」という印象を感じている。

　まず、前提となるのが、プログラム開発にたった1つの正解はないという状況認識である。このような考えを持つに至ったのは、XMLを使うようになってからだ。XMLを処理するプログラムをJava言語やC++言語で書くのはけっこう周りくどくて面倒である。しかし、XMLのスタイルシート変換言語であるXSLTで記述すると、はるかにすっきりするという事実に直面した（とはいえXSLTも完璧と言うわけではない、いろいろと別の意味で問題があるので、XSLTを使えば解決というわけではない）。

　もちろん、ここまで地道に実績を積み重ねてきたJava言語やC++言語が間違っていたとは思わない（間違いだとすると、その先に位置するC#も間違いということになってしまう）。そうではなく、問題は「対象分野によって、それに合ったプログラム言語は変わる」ということではないだろうか？

　より抽象的に言うなら、Java／C++／C#はいずれもオブジェクト指向言語というジャンルでくくることができる。現在の実用プログラム言語の世界は、オブジェクト指向言語が圧倒的に主流であり、実際に過去の他の言語よりも生産性が高いという実績を残している。しかし、どうもオブジェクト指向が向かないジャンルがあるのではないかと感じている。そこに、XMLという存在がジャストミートしてしまったのではないか。では、オブジェクト指向がXMLと相性が悪いとしたら、どんなパラダイムがXMLと相性が良いのだろうか？

　この問いに対する解答は、今のところ筆者にはない。

　だが、CLIの上では、17種類ものプログラム言語が使用できるという。その中には、これまで実用的と評価されず、研究者やマニアにしか相手にされなかった言語も多くある。それらの言語の中に、オブジェクト指向言語が不得意とする分野に上手く適合するパラダイム(たとえば関数型プログラミングのような)をサポートする言語が含まれている可能性があるのではないだろうか？

　この可能性を実証するには、ともかく使ってみるしかない。

　しかし、たった1つの言語だけで、なんでもこなす時代は終わりつつあるような、そんな印象が筆者にはある。

■C#は本当に普及するのか？

　最大の懸念事項は、マイクロソフト社の今後の態度だ。どんなに素晴らしいものを提案しようと、それが供給され、普及しなければなんの意味もない。

　だが、Windowsの圧倒的なシェアを背景とするマイクロソフト社が、その優位性を自ら失わせかねないような、C#とCLIという技術を提供するのだろうか？ しかも、ECMAに提案するという状況からすると、C#とCLIを思いのままに変更する権利をマイクロソフトは手放してしまったようなものである。

　これに関しては、1つの仮定を持ち込むと、すっきりと状況を解釈できる。現在、マイクロソフト社はアメリカにおいて独禁法に関する訴訟の真っ最中であり、会社分割の危険に晒されている。もし、分割された場合、アプリケーションソフト部門とOS開発部門は別会社にされると言われる。そのような状況になった場合、アプリケーションソフト部門はWindowsだけをターゲットに製品をリリースすることは許されないだろう。ならば、そのような状況に陥った場合に備えて打つ手は1つである。つまり、Windowsに依存しない体質への転換である。C#とCLIの提案は、もしかしたらWindowsに依存しないもう1つのプラットホームの構築なのかもしれない。

　もしそうだとすると、つねにWindowsに依存する技術を提供して顧客を囲い込むマイクロソフト社というイメージは書き換える必要があるだろう。実際、マイクロソフト社は、.NET構想を打ち出して自らネットワークサービス企業に転換しようとしているのである。

　激動しているのはプログラム言語だけではないのかもしれない。

■参考資料

　現在、.NET Framework SDK Technology Previewと呼ばれるソフトウェアがダウンロード可能であり、この中にC#コンパイラと実行環境が含まれる。

http://msdn.microsoft.com/downloads/default.asp

　日本語でのC#に関する情報交換を行っているメーリングリストが2つある。

「Master of IP Network総合インデックス」


Master of IP Network フォーラム 新着記事
＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

注目のテーマ

Master of IP Network 記事ランキング

本日 月間
＠IT