統合される強み，統合されない強み
だが、プログラミング言語とコンパイラにできることはまだある。実際、多くの動的型付言語ではできていることなのに、静的型付言語ではなぜかできていないことは多い。C#とVBの次（Visual Studio 2005の次）のバージョン（これらは現在「C# 3.0」、「Visual Basic 9.0」という名前で呼ばれている。以下では「C#3」「VB9」と表記）では、まだあるいくつかの問題の解決に挑戦することが、C#とVBの担当者によって宣言された。
- 暗黙の型指定
- 型推論とラムダ式
- Extension Methodsの導入
- クエリの統合「LINQ」
これらの機能は共通言語ランタイム（CLR）やフレームワーク・クラス・ライブラリのレベルではなく、できるだけ言語仕様とコンパイラのレベルで解決することが発表された。つまり、まもなく登場する共通言語ランタイムの新版（.NET Framework 2.0）の上で動作するということである。RubyやJavaScriptにすでに存在する機能が、C#やVBにも遅ればせながら提供されることになった。
この「言語仕様とコンパイラのレベルで解決すること」というのは，正しくもありまた誤解しやすい点かもしれません．LINQ は 2 つの側面を持ちます．ひとつは LINQ をサポートするために C# 3.0，Visual Basic 9.0 それぞれ言語仕様に変更が必要だった点．そしてもうひとつは，LINQ の内部実装を「ライブラリ」として共有する点です．CLR 2.0 の上で LINQ が動くのは，単に CLR 2.0 の上で実装された「LINQ ライブラリ」が存在するからです．プレビュー版のコンパイラはライブラリに処理を丸投げしているに過ぎません．まさに C# と Visual Basic に対する .NET Framework の関係の縮図です.
今回の発表の面白さを一言で言い表すとすれば，統合と独自のバランスが織りなす妙でしょうか．
実は，言語へのクエリ統合は当初各チームで別々に実装が行われる方向で動いていたそうです．それが最終的に統一の実装を利用するように方針転換され，そのために双方の言語で必要十分な言語拡張がまず優先されたわけですから，2つの言語の改良点に同じような指向が生まれるのはある種同然の帰結です．その意味で「統合」とは単にクエリ構文が言語に統合されたという意味ではなく，LINQ を glue として言語間の指向が「統合」されることに真の意味があると言えそうです．
一方，Visual Basic が独自の進化を遂げつつあるという指摘が，名無しさん♯や吉松さんによってなされています．
Visual Basicを再び動的プログラミング言語にする試み
本レポートの最後に触れておきたいのが、動的型付言語としてのVB9固有の拡張機能である。
VBにはC#にはない大きな特徴がある。遅延バインディング（Late Binding）支援機能だ。C#ではリフレクション構文を使って書かなければならないコードを、VBではあたかも型の内容を知っているかのように書くことができる。これはCOM Interop（COM相互運用）でExcelのセルを操作するようなコードを書くときなどに重宝する。
だが一方で、Option Strict Onを無条件に推奨するような風潮の中では、VBのこの機能はVBが「本物のプログラミング言語」になるためには捨て去るべき過去の遺物のように扱われているのも事実だ。
結局のところ、.NET Frameworkにおける当初のメッセージは「どの言語でも同じ」だったのだから、C#とVBに違いがあってはならず、VBはC#の後を追いかけているような印象を常に与えていた。
しかし今回のPDC05では、VBチームはいよいよこの風潮と決別しようとしていることが明らかになった。「My」の導入やフォームをインスタンス化する構文など、OOP（オブジェクト指向プログラミング）至上主義からは反対される機能をVisual Basic 2005で導入したことは前触れにすぎなかった。
多様性の確保という意味でもこのような変化は望ましいですね．上に書いた共通部があることで，逆にこの独自色がよく映えているように思えます．Visual Basic が徹頭徹尾独自方面に舵を切っていたとしたら，バラバラ感溢れるトークになっていたことかもしれません．
