C#／Visual Stduio.NET／.NET Frameworkの実像を探る ３．まとめと前回記事への補遺 川俣 晶 株式会社ピーデー 2001/01/11

---

プログラム開発をシンプルに、扱いやすくする.NET

　以上をまとめると、WebFormとは、従来型のHTML＋プログラム言語によるWebシステムから、抽象レベルを1段階上がって、同じシステムをWebFormのコントロールの組み合わせとして記述するものだと言える。しかし、その結果として生成されるものは、単なる普通のHTMLにすぎないため、ユーザーは特別なソフトウェアを用意する必要なしに、そのソフトウェアにアクセスすることができる、と言うわけである。

　これを理解した今、筆者は、Visual Basic 1.0に最初に触れたときのことを思い出してしまった。元々、Windowsプログラミングは複雑怪奇で巨大な地獄のような世界であった。すでに述べたとおり、ソースとリソースとヘッダが複雑に絡み合い、OSが要求するさまざまなルールに沿って記述を強制される要素も多く、イベント・ハンドラとなるウィンドウ関数は、容易に収拾不可能な巨大なswitch文に陥ったものである。その地獄が、Visual Basic 1.0の登場によって、マウスを使って鼻歌交じりに遊べる世界に激変したのである。それどころか、それまで簡単だとされていた文字ベースのBASIC言語よりも、さらに簡単とすら言える代物だったのである。

　これと同じように、VS.NET／.NET Framework／C#の提供するWebFormとその開発環境は、複雑怪奇に混迷を極めた開発状況を、軽やかにかわして、もっとシンプルで扱いやすい新しい開発モデルを提供しようとしているように見える。

　おそらく、WinFormが現在のVB的な開発の直接的な後継環境となるのは間違いないだろう。だが、それは後ろ向きの後継である。実は、かつてVBが持っていた本質的なVBらしさは、むしろ、WebFormの方に受け継がれているように感じられる。

　さらに恐るべきことは、C#という言語が、従来のC++的な領域や、Java的な領域をカバーする機能も持っていることにより、これらの領域と、従来のVB的な領域が、1つのプログラム言語をとおして、シームレスに連携していく可能性が存在することだ。たとえば、何らかのデータを処理するプログラムを記述したときに、それに付けるユーザー・インターフェイスとして、コマンドラインやWinFormやWebFormなど、いろいろな方法を用意することができる。しかし、どの方法を採るにせよ、内部処理のロジックは1つのコードを記述するだけでよい。どんな方法からでも、1つのコードを呼び出すことが容易だからだ。

　もちろん、従来でも、COMなどの標準インターフェースを介することで、言語を超えた相互運用性は確保できる。だがソース・コードを書くときに、似て非なる複数の言語を使い分ける苦痛を思えば、同じ1つの言語ですべてを記述することができるというメリットは大きいものに感じられる。

　これは、筆者のように1人で何でも書く場合だけでなく、チームで開発する場合にもメリットになるだろう。たとえば、複数言語混在で開発する際、C++プログラマが不足したからと言って、手の空いているVBプログラマにC++のプログラムを書かせることはできない。だが、すべてC#なら、その種の融通が可能になるかもしれない。

前回の記事への補遺

　前回の記事は、C#とVS.NETがアナウンスされたごく初期に書かれたもので、内容的にもすでに古い。これに関するフォローが遅れたことはお詫び申し上げたい。

　まずタイトルであるが、「プログラム言語のパラダイム・シフト『C#』という提案」というタイトルに関して、読者より「C#は、パラダイム・シフトというほど大きな変化をしてないのではないか」という指摘があった。これは筆者の同意するところである。実は、この見出しは編集部が付けたものである。本文中に「パラダイム・シフト」と言う言葉を用いたことから、それを見出しに持ってきたのだと思うが、筆者としては「C++とVBとJavaとその他のいろいろな言語があって、言語仕様というよりは実装の機能の違いによって言語を使い分けるというパラダイムが終わり、言語選択の基準が変わる」という状況を示して、「パラダイム・シフト」と呼んだのであった。

　以下の3つの用語に関して混乱していると記述したが、現在では用語の意味が明らかになっている。

Common Language Infrastructure（CLI）
Common Language Runtime（CLR）
Common Language Specification（CLS）

　CLIはMicrosoft関係では見られない用語で、ECMAで標準化作業中の実行環境の名称である。CLRは、.NET Frameworkの実行環境の名称である。JavaでいうところのJRE（Java Runtime Environment）のようなものと考えてよいだろう。CLSは、CLR上で実行される各プログラム言語のデータ型とCLRのデータ型の関連を規定する仕様である。

　中間言語の効能として、特定のCPUに依存しないプログラムを作成できること、プログラム・サイズを圧縮できること、という2つの要素を挙げたが、読者より、これに加えて「セキュリティ」という効能もあり得るという指摘を受けた。つまり、中間言語プログラムは、それをインタープリタで実行するにせよ、コンパイルして実行するにせよ、必ず意識的にコードの意味を解釈する段階を経由する。この段階で、不正なアクセスを検出することは容易である。実際に、JavaVMでは、この種のチェックが行われていることから、これも中間言語を使うメリットといってよいと思う。

　「言語の実行速度と言語仕様は直接関係なく、速度は処理系の問題」と書いたが、これに関して、言語仕様も速度に関係するという指摘を読者より受けた。簡単な例で説明してみよう。足し算を行う際に、オーバーフローのエラー（例外）が発生する言語と、オーバーフローを無視すると言語仕様で規定された2つの言語があるとする。この場合、通常の機械語命令は、オーバーフローによってCPU内のフラグにオーバーフローを起こしたという結果を残す。オーバーフローをチェックするということは、このフラグをチェックする機械語命令を追加することを意味し、結果的に実行速度に影響を及ぼす。このような事例は、メモリ管理やデータ型など、さまざまな分野に見られ、現実的な話としては、言語仕様は実行速度に影響する。しかしながら、本文中で指摘したように、「C++は機種依存するが速い、Javaは機種依存しないが遅いという常識は真ではない」という指摘が誤っているわけではない。おそらく、言語仕様を守ったまま極限までチューニングした場合、C++の方がJavaより高速に実行できると思われる。しかし、さまざまな事情によって作られたさまざまな処理系が存在するわけで、それらは諸般の事情により理論限界までチューニングされているとはかぎらない。つまり、実装の内容次第で、実行速度は容易に逆転しうるものである。そして、速度が逆転する状況があっても、言語仕様に違反しているわけではないのである。

　「誰もFortranを使わない」という記述に対しては、読者より実際に分野によってはFortranは使用されているという指摘を受けた。しかし、誰もいないと筆者が思っているわけではない。実際に、スーパー・コンピュータなどを使用する科学技術計算の分野では、Fortranは最も重要なプログラム言語であるという話は筆者も知っている。この記述の手前に「利用者は非常に少ない」と書いたとおりで、ゼロだとは思っていない。編集段階で「誰もFortranを使わない」という記述が強調された文章の一部に入ったために、過剰に印象が強調されたような効果もあったと思われる。また、少ないと書いておきながら、「誰も……使わない」と言うのも文章として一貫性がなく、悪文を書いてしまったと思う。この部分は、以下のように訂正したい。

たとえば、世界最初の高級言語と呼ばれるFortran言語というものがある。Fortranで書かれた過去の資産の活用や、Fortranで書かねば性能を引き出せないスーパー・コンピュータなどの存在によって、科学技術計算を中心に根強いニーズはあるものの、通常のビジネス系のソフトウェアを記述する言語としてFortranが取りざたされることはほとんどない。Microsoftの開発製品として見ると、Visual C++ 4.0の時代にはFortranも同じ統合環境の中で使用可能であったが、現在のVisual StudioにFortranの姿はもうない。かつては圧倒的に大きな存在感を持っていたFortranがここまで後退した理由は簡単である。生産性が著しく低いのである。

　「より抽象的に言うなら、Java／C++／C#はいずれもオブジェクト指向言語というジャンルでくくることができる」と書いたが、これは短絡すぎたかもしれない。C#は、オブジェクト指向ではなく、コンポーネント指向の言語と呼ばれるためだ。コンポーネント指向とは、クラスの継承よりも、再利用可能な部品の組み合わせを重視する流儀だと考えられる。これは、クラスに複雑な継承関係があるときに、いかにプログラムが分かりにくくなるかを考えれば、1つの見識と言えるだろう。ただ、オブジェクト指向の世界でも、継承よりもコンポジションという考え方が出てきており、これをオブジェクト指向の次に来る新しい考え方とみなすか、オブジェクト指向の世界における内側の変革と見なすかは微妙なところである。

　「1つの言語にこだわる時代は終わった」という見出しもあるが、これの裏返しとして、何でもC#という1個の言語で書けるというメリットも考えられる。システム・レベルのコンソール・アプリケーションから、GUIもWebのサーバー・サイドもクライアント埋め込みも、全部C#で書けるなら、これ1個ですべて書ききるのもラクチンでいいかもしれないと思う。

　参考資料として示したメーリング・リストが2つあるが、このうちMicrosoft Unofficial C#（シーシャープ/csharp）メーリング・リストは終了して、もう1つのC# Mailing Listに統合された。しかし、その後、C#の話題を扱うとするメーリング・リストがいくつも自然発生的に生まれており、筆者も総数を把握していない。懸念されることは、話題が複数のメーリング・リストに分散して、情報が拡散してしまうことである。メーリング・リストの主催者はよく相談して、できるだけ場所を1つにまとめていただきたいと希望する。

関連リンク
Master of Network	プログラム言語のパラダイム・シフト『C#』という提案
USERS GROUP	C# Mailing List

INDEX
	［特集］C#／Visual Stduio.NET／.NET Frameworkの実像を探る
	1．Visual Studio.NETのIDE　―― 意外にもVisual J++のIDEの直系子孫 ――
	2．何はともあれ、C#プログラミングを体験しよう
	3. まとめと前回記事への補遺

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