Whidbeyへのいざない：Visual Studio Magazine（4/7 ページ）

[Don Kiely，FTPOnline]

各ユーザーで異なるIDEの姿

　WhidbeyのIDEも、それぞれのMicrosoft .NET言語に対して異なる機能を実装している。VB.NETはエディット＆コンティニューを復活し、また、コードを自動的に生成し、必要とされるコード量を削減するためのハイレベルの抽象概念を特徴としている。C++はWindows Fusionをフルサポートし、ネイティブコードを使ったDLLディプロイメントにおける地獄の苦しみを解消する。

　C#はフレームワークの作成と、コードの自動生成のサポートを強化するための新しい機能を持つ（エンタープライズレベルの機能が突出しているので、Whidbeyがリリースされれば、私はC#を使うだろう）。

　.NET言語のことではないが、私が気付いているのは、新しい言語バージョンでの拡張に対して大きなゆとりを残しているILの能力を、最大限に利用することだ。IL自身は、上位のレベルとなる各言語と伴に、不一致を克服するための拡張を受け続けている。もしMicrosoftが自らの言語間での協調を維持できないなら、サードパーティである言語ベンダーも20種類以上もの.NET言語と、より良い連携を持つことは無いだろう。私が公言しても差し支えないと思うのは、.NETではない言語も、いつかは他の言語と完璧に協調するということだ。言語の選択は、これまでにおいて、また将来においても、個人の好みと利便性という意味で単純なことではない。各言語の機能を進歩させるために、Microsoftとサードベンダーの言語開発チームが努力するにつれて、それぞれにおける要件と機能の大きすぎる違いが浮び上がってくる。

　しかし、.NET言語間で協調していないのは問題ではない。VBを長く使っているならVB.NETでも良い。C++のコーディングに慣れているのならC#、Javaがクールだと思うのならJ#、メインフレームでの経験を生かすのならサードパーティの言語でよい。何らかの言語で書いたアセンブリは、他の言語とともに使用できる。ある言語が必要なシンタックスを持つなら、あるいは別の言語が必要な機能を持つのなら、他に優先してその言語を選択すべきだ。

　貴方の所属する企業が、長期にわたるアプリケーションメンテナンスや、その他の理由のために単一の言語を必要とするなら、それでも構わない。言い換えれば、言語の選択のために歯軋りすることはないということだ。つまり、1つの言語を選んで、人生を上手くやれればいいが、切り替えが必要なときのために、言語の変更のための準備はしておいて損はないということなのである。

　IDEの変更も重大だが、データベースの変更はより大きな影響をもたらすだろう。WhidbeyはYukonと緊密に統合している。Yukonは.NET CLR（Common Language Runtime）を含む予定で、ストアドプロシージャを各種の.NET言語で記述できる。

　本稿の執筆時には、Yukonはファーストベータの段階で、まだ新機能の全てが実装されていない。そのため、どの程度CLRとの統合が進み、また、T-SQLのためにコードを書く必要ガないことのすばらしさを見せるに止まっている。

　VS.NETに含まれる機能が、カスタムアプリケーションにおけるSQL Serverのデータ利用を簡単にすることで、Whidbeyは他の面でもYukonとの統合を促進する。例えば、それはかつてないほど簡単に、アプリケーションに対するディプロイメントデータベースとして、SQL Server Desktop Edition （MSDE）を使用することだ。たとえSQL Serverに替えてMSDEに対するアプリケーションを開発しても、ユーザーが必要とする全ての開発ツールはIDEに適合する。新しいディプロイメントツールキットは、MSDEとカスタムデータベースのディプロイメントにおいて山積みにされている現状の問題を取り去るだろう。