関連記事＝「『次のC#では，データとオブジェクトのミスマッチを解消したい』---C#の開発者が語る(1)」
---次世代の .NET FrameworkやC#が備えるようになる新機能は，開発者にどのような影響を与えると思いますか。成果物であるシステムにはどのような変革をもたらすと思いますか。
最終的には開発者の生産性がより高まればいいと思います。新機能によって，プログラムの抽象度が高まり，より宣言型言語（編集部注：Prologなどが代表格）に近くなってくると思います。今日のプログラミングでは，「何をしたいか」（what）だけでなく，「どうやってそれを実現するか」（how）も記述します。しかし，プログラム中に「どうやって実現するか」の部分が多くなりすぎると，ランタイム構造がプログラムを最適に実行するうえで問題が生じます。
例えば，現在のプログラミングでは大きなデータを扱うときは，forループやif文を書いて，データの要素を適当な位置に配置したりします。ランタイム構造は，命令通りに処理をします。より良い処理方法をランタイムが選ぶようなことはできません。しかし，プログラムで，「これがデータソース，これがフィルタ，これが射影（projection）」などと指定すれば済むようになれば，いろいろなことが実現できるようになります。例えば，マルチプロセサ搭載機でクエリーを並列実行させるなどといったことも容易になります。こうしたことを実現するには，プログラミング言語をより抽象度の高いものにしていく必要があります。
---言語の抽象度を高めていくということですが，世の中にはアセンブリ言語で一生懸命プログラムを作ること自体が楽しいという人もいます。そのような要素をC#に残しておいていただけると，楽しい言語になると思うのですが。
（笑）C#にインライン・アセンブラを実装することはないでしょう。私自身アセンブリ言語でプログラムを作っていましたが，最近ではアセンブリ言語でプログラムを作る理由はあまりないと考えています。プロセサが8ビットで，メモリーが64Kバイトの時代に適していた方法と言えるでしょう。ただ，楽しいということは変わりないと思いますよ。
---プログラミング言語の進む先として，プロのプログラマが使いやすい言語という方向と，コンピュータの知識があまり無い人でも使える言語という方向があると思いますが，C#はどちらの方向に進むと思いますか。
今日のプログラミング言語は命令型のプログラミング・スタイル（pure imperative programming style）を持っています。このスタイルではできることに限界があると思います。一方で，宣言型のプログラミング言語はこれからもっと進化すると思います。こういう話をすると，DSL（domain specific language）がよく話題にのぼりますね。
私は，プログラミングをより高いレベルで抽象化する方法を考える必要があると思います。例えば，金融の仕事をしている人は，ルールを上位レベルで定義したいだけであって，システムを細かく操作したいと考えているわけではないと思います。こういうときにDSLが活躍するのですが，DSLにも問題はあります。プログラマが操作する表層の下にあまりにも多くのことが隠されているのです。抽象度が高いところでプログラミングできるのは良いことですが，旧来のスタイルでプログラムを書こうと思ってもDSLではできません。私は，抽象度が高いところでプログラミングできるということと，必要なときには旧来のコードも書けるということの両方を達成したいと考えています。
---最近はJavaの世界でアスペクト指向やDI（Dependency Injection）といった新しい開発方法論が登場しています。これらの新しい方法論についてどう思われますか。
アスペクト指向については，今は，何が起こるのか見守っているところですね。アスペクト指向はデバッグとかモニタリングには役立つと思います。しかし，大規模なシステム開発では心配な点もあります。私の書いたコードにほかの誰かがコードを注入してくると，私のコードが現在どう動いているのかを把握しにくくなると思います。私が自分で予期したようにはコードが動かない可能性があるわけです。つまり，副作用があるということです。
アスペクト指向が実現していることの多くは，別の方法でも実現できると思います。例えば，.NETならメタデータを追加するアトリビュートとリフレクションがあります。C# 2.0ならパーシャル・クラスがあります。これを使えば，自動的に生成されたコードと自分で書いたコードを合成できます。もちろん，これらの機能が完全にアスペクト指向を代替できるとは思っていません。しかし，大部分は代替可能ではないかと感じています。結局のところ，アスペクト指向はある問題を解決するものかもしれないですが，同時にほかの新しい問題を引き起こすものではないかと思います。
---.NET Frameworkが登場してからかなり経つにもかかわらず，未だにVisual Basic（VB）6を使っている人が沢山いるようですが…。
確かにVB 6はとても素晴らしいツールです。同じものをほかの環境の上に作り直すことは不可能ではないかと思います。VB 6を生かすなら，同じコードベースを使って少しずつ進歩させていくしかないでしょう。しかし，そのコードベースを生かしたとしてもすぐに限界が来ると思います。一方，.NET Frameworkは今後何年も使ってもらえるように作りました。残念ながら .NET FrameworkとVB 6の互換性は完全ではありませんが，新しいVB 2005は以前のバージョンよりVB 6との互換性が高くなっています。
VB 6は使いやすいクライアント・アプリケーションを作ることを目的としたツールでした。しかし，.NET Framework 2.0ならばもっと使いやすいクライアント・アプリケーションを作れます。それだけでなく，WebアプリケーションやWebサービスといったアプリケーションも作れるようになっています。VB 6プログラマが .NET Frameworkに移行する価値は絶対にあるはずです。
---10年，20年前に比べるとプログラミングを取り巻く技術が大きく進歩してきました。プログラミングを学習するうえでも，身につけるべき知識や技術が大幅に増えています。これからプログラミングの世界に入ろうとする人たちにとって大きな負担だと思います。これからプログラミングを始めようとする人々は，どこから着手してどのように学習すべきと思いますか。
個人的には，ソフトウエア開発の世界は，ハードウエアに比べると非常に進化が遅いと思います。今私が持っているコンピュータは，私がプログラミングを始めたころのコンピュータと比べると1万倍以上も高性能になっています。一方，プログラミング言語自体はそれほど変わっていません。私が考えるに，プログラミングの世界では40年前の話題が今でも通用するということが多くあると思います。書籍で言うならNiklaus Wirthの「アルゴリズム＋データ構造＝プログラム」（Algorithms + Data Structures = Programs，Prentice Hall発行，1976年）などは今でも私の本棚に並んでいます。今読んでみても使える内容がたくさんあります。「クイックソート（quick sort）」（編集部注：データの並べ替えにおいて，多くの場合に最も高速なアルゴリズム）は，今でもクイック（速い）ソートだということです。
新しい言語やスタイルが続々登場していますが，中核となるコンセプトを理解することが大切であることは昔も今も変わりません。どの言語を最初に学ぶかということはそれほど重要ではないと思います。アルゴリズムを書く方法もあまり変わらないと思います。最近は従来の言語を教える前に宣言型言語を教えている大学もあるようです。このような試みがどんな結果になるのか楽しみですね。
---今でも自分の趣味としてプログラミングをすることはありますか。
ありますよ。
---最近作ったプログラムにはどんなものがありますか。
最近ではLINQプロジェクトにかかわっていますね。
---仕事ではなく，趣味としてのプログラミングについてお聞きしたいのですが。
あぁ，趣味ですか（笑）。私は仕事が趣味なもので。仕事に関係ないプログラムですか。最近はあまりないですね。仕事と趣味をあまり分けられないもので。
---ほかに趣味はお持ちですか。
ゴルフやスカッシュをやっています。それから私には3人の子供がいて，いちばん年上の子供は5歳です。子供の相手をするだけでもとても忙しいですね。そういうわけで，最近は新しい趣味としてレゴ・ブロックを楽しんでいます。
