Visual Studio（VS） 2005のパッケージが2月3日に発売されたばかりだが，既にVS次期版（開発コード名Orcas）に搭載されるVisual Basic（VB） 9.0の言語仕様が一部公開されていることをご存知だろうか。例えば，2月2～3日に横浜で開催されたMicrosoft Developers Conference 2006の講演で紹介されたし，マイクロソフトのWebサイトで参照できるものとしては，VBの開発者によるブログやPDC（Professional Developers Conference）2005での講演がある(いずれも日本語のドキュメントも公開されている)。

　これらの講演/資料で目を引くのは，VB 9.0には「動的インタフェース」「動的識別子」「暗黙の型のローカル変数」といった，最近評価が高まっている「動的言語（Dynamic Language）」を意識したいくつかの機能が追加される予定であることだ(参考記事)。動的言語は，型に対する判断をはじめとするさまざまな決定を，コンパイル時ではなく実行時に行う言語のこと。Perl，Python，Rubyなどのスクリプト言語がこれに相当する。

　動的言語の特徴は，「変化に対して柔軟である」，言い換えればプログラムの仕様変更などが生じたときにコードの修正量が少なくて済むことである。「Duck Typing」が可能である，というのがその例だ。「Duck Typing」は，「アヒルのように歩き，アヒルのように鳴くなら，それはアヒルである」，つまり「オブジェクトが期待する振る舞いをするなら，そのオブジェクトの実際の型が何であるかは問わない」という考え方を指す。例えば以下のコードは，引数duckが実際に参照するオブジェクトが文字列を返すQuackメソッドを備えてさえいれば，そのオブジェクトの型が文字通り何であっても動作する。オブジェクトが特定のインタフェースを実装するかどうかなどは関係ない。 

Option Strict Off
…
Sub DuckTalk(duck)
  Console.WriteLine(duck.Quack())
End Sub

　C++，C#，Javaといった静的言語でも，多態性を利用することでよく似た振る舞いを実現できるが，そのためには「Quackメソッドを持つスーパークラス/インタフェースを定義する」「対象となるクラスでそれらを継承/実装する」といった余分な作業が必要になる。プロトタイピングをはじめ，試行錯誤を繰り返しながらプログラミングするような開発スタイルの場合，機能追加のたびにこうした型に関する記述を修正するのは面倒だ。特にWebアプリケーション開発では，「永遠のベータ版（Perpetual Beta）」という言葉があるように，プロトタイピングから正式リリースまでの境界があいまいなケースも多い。一昔前ならシステム開発の主流にはなりえなかったスクリプト言語が最近注目されている背景には，こうした事情がある。

動的言語と静的言語の間を行き来するVB

　ところで，VBが動的言語を意識した機能を追加すると聞いて，「そもそも昔のVBは動的言語では？」と感じる人も多いのではないだろうか。例えばVB 6.0では，一応型を持つものの，Variant型やObject型を利用することで動的言語とほぼ同様のコーディングが可能だった。ただ，最近の動的言語と違い，VB 6.0はコンテキストに応じて内部で暗黙の型変換を行う機能を備えており，これがバグの原因になることが少なからずあった。浮動小数点数の「1.0」を「1899年12月31日午前0時」と解釈する，というのがその例だ。当時，“正統派”とされていたJavaやC++などの言語と比較してこの点に不満を持つ人は少なくなかったし，記者 も以前このコラムで苦言を呈したことがある。

　2002年に登場したVB .NETは，オブジェクト指向関連機能の強化とともにこうした型の扱いを変更し，C#などと同様のカッチリとした型を持つ言語に生まれ変わった。ところがこれらの変更は，既存のVB 6.0ユーザーには受け入れられず，結果的にVB 6.0からの移行が進まないという事態が生じた。VB 6.0とVB.NETでは，言語仕様もライブラリもまるで違うので，簡単には移行できない。どうせ移行するなら，C#やJavaなどの別の言語のほうがいい，というわけだ。

　そこで，マイクロソフトはVB 2005で，My機能を新たに追加し，.NETクラスライブラリの中で頻繁に使う機能には簡単にアクセスできるようにした。VS .NET 2002の登場時点では，VBもC#も.NETクラスライブラリを扱うための言語の一つという意味で同列の位置付けであったが，VS 2005では「VBのほうがより簡単に」と，多少の差別化が図られたわけである。

　次期VSでも，このVBとC#を差別化するという方針が引き継がれる。C# 3.0があくまで静的言語として位置付けられるのに対し，VBは静的言語向きの分野から動的言語のメリットが大きい分野まで，より広い領域をカバーするという位置付けになる。

VB 6.0との互換性を優先してほしい

　記者は，VBとC#を差別化すること自体には賛成であるものの，VB 9.0が動的言語の方向に向かう点には少し疑問を感じている。ターゲットとなるユーザー（開発者）が今一つ見えないからだ。VBの言語仕様を多少変更したところで，VBが動的言語になるわけではない。PythonやRubyなどのユーザーを.NETに取り込むことを考えるなら，むしろ.NET上で動作するPythonやRubyの処理系を開発する方が美しい。実際，米Microsoftは.NET用PythonであるIronPythonをShared Sourceの形で公開している。

　「VBのほうがより簡単に」とは言っても，これからプログラミングを始める人々にVBを勧めるというのは現実的でないだろう。VB 9.0が型を意識しなくて済むといった初心者に優しい特徴を持つなら，C#などの代わりにVB 9.0を勧めるのもうなずける。だが，実際にはVB 9.0とC#の型の扱いはほぼ同じである。加えて，オブジェクト指向の概念や，.NETの膨大なクラスライブラリについて学ぶ必要があることを考えると，言語の差などたかが知れているとも言える。マイクロソフトはこれまで.NET用の言語を新たに覚えるならC#を勧めてきたし，この点は次期VSでも変わらないと思われる。

　結局のところ，VB 9.0のメイン・ターゲットはVB 6.0やVBA（Visual Basic for Applications）を以前使っていたユーザーか，もしくはこれらで開発したシステムの移行を担当する人になるだろう。だったら，VB 6.0/VBA 6.0との互換性を高めることをもっと考えてもよいのではないだろうか。移植専用と割り切ってコンパイル・オプションなどを追加すれば，言語仕様の互換性をもっと高めることができるはずだ。クラスライブラリが異なる以上，言語仕様だけ互換性を高めてもVB 6.0のコードをそのまま利用できるようになるわけではない。だが，GUI部分などと比べてコードの寿命がはるかに長いビジネス・ロジックの部分を，あまり手直しすることなく.NETに移行できるようになるメリットは大きいはずだ。

　マイクロソフトは2005年6月にVB 6.0の通常サポートを終了しているものの，VB 6.0で構築されたシステムはまだ多数が稼働している。VB 6.0，.NET，Javaなどの開発者向けに各種コンポーネント製品を販売するグレープシティは，いまだにコンポーネント製品の売り上げの約4割をVB 6.0用のコンポーネント（ActiveXコンポーネント）が占めるという。現在稼働するVB 6.0のシステムの寿命が尽きる前に，マイクロソフトが効果的な移行手段を用意できるか---。.NETで稼働するシステムが今後増えるかどうかの鍵を握っているのは，実はこの点ではないだろうか。

（山本　哲史＝IT Pro）