C#／Visual Stduio.NET／.NET Frameworkの実像を探る １．Visual Studio.NETのIDE　 ― 意外にもVisual J++のIDEの直系子孫 ― 川俣 晶 株式会社ピーデー 2001/01/11

---

この記事の位置づけ

　この記事は、プログラミング言語C#とそれをコンパイル実行可能な実行環境である.NET Frameworkに焦点を当てて、実際に、Visual Studio.NET（英語版）（以前はVisual Studio 7.0と呼ばれていた）を用いて体験した内容と、その他の雑感を述べた記事である。

　併せて、筆者が以前書いた記事、「Master of Network：プログラム言語のパラダイム・シフト『C#』という提案」の内容のアップデートという意味を持っている。この記事をお読みの方のために、本記事の最後にこの記事の内容の訂正、変更点、追加説明などを記すので参考にしていただきたい。なお本サイトには、初心者向けの記事として「特集：.NET Framework入門」や、ニュース報道的な性格の記事として「特集：Microsoft.NETが目指す次世代情報環境とは？」などもあるので、適宜参照していただきたい。

体験可能な未来と引き延ばされた過去

　実は最近になって、Visual Basic 6.0（以下VBと略）でそれほど大きくはないプログラムを1本書く羽目になってしまった。本当は、「一丁C#を試してみるか」と思っていたのだが、さすがに、C#のプログラムは、CLR（Common Language Runtime：.NET Framework上でアプリケーションやコンポーネントを動作させるための実行エンジン）がないと実行できないので（JavaプログラムがJavaVM抜きで実行できないのと同じ）、急遽VBに切り換えたのだ。しかし、書けば書くほど泥沼に入っていくソース・コードを見て情けなくなってきた。実は、かつて筆者はVBの大ファンであった。何しろ、英語版のVisual Basic 1.0を早い時期に入手して、それを使って遊び倒したぐらいである。これほど優れたビジュアル開発ツールはめったにあるものじゃないと、しみじみ思ったものである。プログラム言語としても、Modula-2あたりの影響を受けているようで、その気になればわりときれいなプログラムが書けた。もちろん、過去との互換性という機能も盛大に抱え込んでいたので、スパゲッティにするのも極めて容易であったが。ともかく、私はVBは素晴らしいと本気で思うことができた。

　ところが、今、筆者の目の前にあるVBは、もはやかつてのVBではない。1.44Mbytesのフロッピーディスク3枚に何もかもが収まっていた、コンパクトで軽快で分かりやすい開発環境は、今や、人間業では全貌を見通すことができないジャングルと化している。混乱の理由は、よく検討していないが、漠然とした印象で言えば、Variant型の導入と、安易なCOMオブジェクトへの対応にあると感じる。Variant型は、どんなデータ型のデータでも入れることができる魔法の箱である。だが、強力すぎる魔法は、プログラマを手助けするだけでなく、バグも手助けしてしまう。メリットとデメリットを比較すれば、デメリットの方が多いというのが、一般的な解釈と言えるだろう。

　だが、この魔法はCOMオブジェクトが出てくると突然機能不良に陥る。例えば数値を入れるときには、

dim a : a = b

とただ代入文を書けばよいのだが、同じ変数にCOMオブジェクトを入れようと思ったら、

dim a : a = b

と書くとエラーになってしまい、

dim a : set a = b

のようにsetキーワードを付ける必要が生じる。これによって、Variant型の魔法を効果的に活用して、「どんなデータであっても処理できる汎用の変数操作機能」を書こうとすると、それがオブジェクトかどうかいちいち判定しなければ代入もできない、ということになる（ただ、値の代入と参照の代入は違うのだから、構文で区別すべきという考え方はある。その考え方に立つなら、setキーワードの存在は正しい。しかし、それを言うなら、値も参照も入るVariant型の存在は不健全である）。

　これに限らず、いろいろ書きながら体験して筆者が感じたことは、すでにVBは複雑すぎる怪物と化したという感慨だ。かつて、プログラミングの入門はVBで、という話も多かったが、最近はあまり聞かない。今、プログラミング入門と言えば、Javaが多いと思うのだが、筆者もそれは正しいと思う。これほど時代遅れになり複雑化したVBを教えても何らメリットはない。

　VBは筆者にとってのすでに終わった美しい想い出にしておくのがよいのだと、はっきりと分かった。

　だが、終わりにすればそれでよいというものではない。プログラムを書かねばならない現実というものがあって、何らかのプログラム言語は必要とされているのである。

　今この瞬間に適切なものがなければ、未来を先取りするしかない。以前から新しいプログラム言語C#に興味のあった筆者は、米Microsoftが、Visual Studio.NET（当初はVisual Studio 7.0と呼ばれていた。以下VS.NETと省略）のベータ1を配布するという話に即座に飛びついた。MSDN ユニバーサル・サブスクリプションの会員であれば、容易に手に入るのだが、筆者は（会社では）MSDNプロフェッショナルのレベルまでしか契約していない（さらに上位のユニバーサル会員ならば、VS.NETのベータ版をインターネット上のサイトからダウンロードできる）。だが、米Microsoftのサイトからオンラインショップに発注できると分かり、ドキドキしながら発注した。過去の経験から言って、本当に来るかどうか、予断は許さない。昔は、この手のソフトウェアは、日本からのリクエストだと分かると「現地法人を経由して入手してくれ」と言われ、現地法人に問い合わせると「そんなものは知らない」と言われることも珍しくなかったのだ。だが、待つことしばし。ちゃんと到着した。素晴らしい。世界は間違いなくよい方向に進んでいる。

　ちなみに、ここでいうVS.NETベータ1とは、もちろん英語版である。だが英語版であることにさしたる問題はない。実は筆者は、英語版のVisual C++を何度も愛用した過去があるのだ。例えば、Windows NTでデバッグを含む機能がすべて完璧に動作する最強の16bit開発環境であったVisual C++ 1.5は、それ単体で日本語化されることがなかったため、筆者はやむを得ず英語版を使っていた。だが、英語版でもソース・コードに書き込んだ日本語文字は問題なく通り、メニュー、メッセージ、ヘルプのたぐいが英語であることを気にしなければ、完全に実用的に使用できた。現実には、ヘルプの日本語訳は（今も昔も）誤訳の塊なので、英語版なのはむしろ「有り難い」ほどだ。不慣れな英語をじっくり読んだ方が、日本語で読むよりも迅速に意味が把握できるという本末転倒した状況は、筆者の実感である。このほか実際に筆者は、Visual C++ 4.xの時代にも英語版を愛用したが、日本語をちゃんと扱うことができた。このような実績から考えれば、日本語版を待つ必要などまったくない。英語版さえあれば、「ガンガン行こうぜ」という状態である。

　もっとも、日本語版のVS.NETベータ1の受付が始まったと聞くと、すぐに手続きしたのは事実である。やっぱり日本語版も欲しいのも事実だ。

　ともかく、日本語版はまだだが、英語版のVS.NETベータ1は入手できた。これで未来を先取りする準備は完了である（日本語版VS.NETベータ1は、2000年12月11日より、MSDNユバーサル会員向けのダウンロード・サービスが開始された。このほかマイクロソフトは、VS.NETベータ1日本語版のCD-ROMによる実費提供も受け付けている。詳細はマイクロソフトの対象ページを参照されたい）。

激変？ のVS.NET統合環境

　VS.NETベータ1は製品版以前のソフトウェアなので、とりあえずテスト専用マシンに独立したパーティションを確保し、そこにOSから新規にセットアップした。OSとしては、試しに英語版のWindows 2000 Professionalを使用してみた。これをインストール後、Service Pack 1を当て、Internet ExplorerをVer.5.5 SP1にバージョンアップしてから、VS.NETベータ1をインストールしてみた。VS.NETベータ1はCD-ROM 2枚で、これに加えてComponent UpdateというCD-ROMが必要になる。送付されたCD-ROMには、さらにSQL-Serverの体験版もあり、計4枚であったが、SQL-Serverはどうしても必要ということではないようだ。

　意外にもVS.NETベータ1はあっさりと動いた。軽くHello Worldなどを作成してみると、ちゃんと動く。

　VS.NETは、1つのIDE（統合開発環境）の中で、C++、C#、Visual Basicのプログラミングを扱う。マイクロソフトのアナウンスでは、C#はC++の発展形に位置づけられるため、一見、Visual C++にC#サポートが追加されるかのように思えるが、VS.NETを見るかぎり、Visual C++のIDEの発展形というよりは、マイクロソフトのJava開発環境であるVisual J++との類似性が強く感じられる。

　おそらくVisual J++をちゃんと使っているユーザーは少ないと思うので、ここで軽く具体的な例について触れておこう。Visual C++では、ビルドを行うとコンパイラのエラー・メッセージなどの出力が下部のウィンドウに表示され、その行をダブルクリックすることでタグ・ジャンプが起こり、エラーの発生した行に飛ぶことができる。

　これに対してVisual J++では、発見されたエラーはタスク・リストというものに登録され、これをダブルクリックするとエラー個所に飛ぶという仕組みである。一見すると似ているように見えるが、タスク・リストにはエディット中にIDEが発見した構文エラーなどが随時登録されるため、ビルドしなければエラーの分からないVisual C++の方法よりも、より先進的であると言える。またそれだけでなく、初期設定のキー操作の中で、ブックマークの登録がVisual C++ではCtrl＋F2なのに、Visual J++ではCtrl＋K Kであるといった操作流儀の相違点がある。実はここで述べたVisual J++の特徴がすべてVS.NETのIDEに当てはまるのである。もちろん、キー操作などはカスタマイズでき、Visual C++互換のキー設定も提供されるのだが、タスク・リストの存在などは、明らかにVS.NETのIDEが、Visual J++のIDEの直系の子孫であることを示している。

Visual C++ 6.0のIDE

Visual C++では、ソース・コード中のエラー・レポートは、コンパイル時に、コンパイラが出力するメッセージとしてIDEのペインに表示されるようになっていた（つまり、コマンドライン・コンパイラ時代に出力されるエラー・メッセージがIDEのペイン内に表示されているのと同じ）。つまり、ソース・コードの編集を終えて、コンパイルを実行するまでは、エラー情報は表示されない。

Visual C++ 6.0のエラー表示ペイン。コンパイル実行時、ソース・コード中にエラーが発見されると、ここにエラー・レポートが表示される。

　

VS.NETのIDE

これに対してVS.NETでは、コンパイルをしなくても、エディット中にIDEがエラーを発見すると、その情報が「Task List」と呼ばれるペインに表示されていく。画面はVS.NETで追加されたC#を利用してプログラミングしているところ。

タスク・リストが表示されるペイン。エディット途中でも、IDEがエラーを発見すると、それらの情報をこのペインに表示してくれる。コンパイルしなければエラー・メッセージが表示されなかったVisual C++から一歩進んだ形である。

　

Visual J++ 6.0のIDE

タスク・リストというしくみは、実はVS.NETで新たに搭載されたものではなく、Visual J++では以前から採用されていたものだ。このように開発環境としてのVS.NETは、Visual C++の発展形というよりも、Visual J++の発展形だと考えてよさそうだ。

Visual J++のタスク・リストのペイン。この機能はVS.NETに継承された。

　この事実は、言語としてのC#は、C++の発展形と考えられているかもしれないが、VS.NETの構造としては、C#開発環境はJava開発環境の発展形という位置づけになっていることを示していると思われる。そうすると、VS.NETのC++の位置づけは、C#のオマケ的なポジションであると考えられる。これは、C++プログラマにとっては、かなり「精神的に痛い」状況だろう。元々、Visual C++は、プロフェッショナル御用達の最も堅実なツールである。それに対して、Visual J++の方は、利用実績も少なく、Javaの開発環境としてはMicrosoftの独自機能が入り込んでいて、100% Pure Javaの展開には不安が残り、かといって、これで機種依存するアプリケーション・ソフトウェアを開発するには、Microsoftの本気度が不安に感じられる、中途半端なツールであった。ある意味で、イロモノ的な性格を持ったツールと言ってもよい。

　ここで余談を1つ入れる。筆者はVisual J++をけなしているかのように見えるかもしれないが、実は、筆者が作成しているJavaで書いたメーリング・リスト配信ソフトである「りすと亭」は、Visual J++で開発しているという事実がある（りすと亭の詳細については「りすと亭のホームページ」を参照）。最初は、Symantec WinCafeだったのだが、あまりにWindowsの標準的なお作法から外れたエディタのキー設定と、なかなか機能してくれないデバッグ機能に嫌気がさして、Visual J++に移行してしまったのだ。もちろん、世の中には、多数のJava開発環境があり、Visual J++をベストと呼ぶつもりはない。特に、Java2に対応することもなく、進化が止まってしまったツールであるということを考えれば、これからJavaをやろうというユーザーに勧められるものではない。だが、これだけは書いておこう。Visual J++は少なくとも、「できる」と書かれた機能はちゃんと機能して、筆者のプログラム開発の手助けをしてくれた。

　また、もともとVisual C++の愛用者であった筆者であるから、ユーザー・インターフェイスが違うVisual J++に手を焼いたのは事実である。だが、これはすでに述べたように、Visual C++が正しくVisual J++が間違っているというような性格のものではない。これは正誤ではなく、流儀の違いと考えるべきだし、Visual J++の方が（成功したかどうかはともかく）より先進的なチャレンジであったと考えるのが妥当だろう。

　これらのことを頭に入れた上で、VS.NETのIDEがVisual J++の発展形であるという事実を考えてみよう。すると、単純に、Javaの開発環境が、C#の開発環境に進化した、というような単純な構図ではないことが分かるはずだ。また、けしてプロの道具がイロモノに乗っ取られた、という構図でないのも明らかだろう。

関連記事（Insider.NET内）
特集	.NET Framework入門
特集	Microsoft.NETが目指す次世代情報環境とは？
関連リンク
Master of Network	プログラム言語のパラダイム・シフト『C#』という提案
マイクロソフト	Visual Studio.NET ベータ 1 日本語版提供開始
株式会社ピーデー	りすと亭のホームページ

　

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

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