O'Reillyの Rachel Rouemeliotis氏は、最近Microsoftの C#コンパイラチームにおけるPrincipal Software Design Engineer である Eric Lippert氏と話した。この インタビュー では、幾つものトピックが話題になり、Lippert 氏によるC#世界の要点が提供されている。この議論が引き金となり、InfoQは、氏に連絡を取り、言語設計哲学の思慮深い分析に繋がる彼のコメントのより広い背景を話してくれるように頼んだ。
氏は、 O'Reillyとのインタビューを「Windowsエコシステム全体に渡る」C#の人気に関するコメントとX-Box 360, Windows Phones, Active Server Pages,そして事業部門アプリケーションの開発に使われていることに注目することから始めた。C#の強みの１つは、非常に一般的で、ドメイン特有の言語ではないこと。この汎用性にも関わらず、氏が指摘したのは、C#は「不要なもの以外全て」を含むことを意図していない、ということである。
これが動機で、InfoQは、氏にMicrosoftのC#と Visual Basicそれぞれの製品のゴールを明確にするために、両製品の戦略をアップデートするように頼んだ。両製品を比べると、Microsoftは両製品は共存しながら進化していく汎用目的の言語である、と考えている。これは、両方がシンタックスが違うだけの同じ言語になる、ということではない。そうではなく、「Microsoftは、新規の主要なC#のフィーチャは、VBでも似たようなフィーチャとなり、その逆もある、という意図です」。
既に追加されてきたフィーチャの例には、LINQサポートやジェネリック共変性がある。近々追加予定のフィーチャには、 async/awaitキーワードを使った非同期プログラミングのサポートがある。氏がO'Reillyとのインタビューの中で言っているのは、「問題は、我々は遅延のある世界に住んでいる」ことであり、プログラマは、ユーザー入力やネットワーク通信を待つ時に、直面する遅延に対処するようにプログラムを書かなければならないことである。この負担を緩和するために、async/await キーワードを使うと、プログラマはコードにアノテーションを追加することで、コンパイラが非同期コード部分を管理する手助けをしてくれる。これによって、更にコードの可読性は増し、開発が容易になる。
我々とのインタビューで、氏は、「単にそれぞれの言語がどのフィーチャをサポートするか、ということより一層深刻化するC#とVBの設計上の歴史的な哲学的違い」を認めた。
VBは歴史的に「ユーザーの道に可能な限り障害を少なくする。もしコードが明確でなかったら、何を意味しているのかを努力してわかろうとする」という哲学で設計されてきました。C#は歴史的に「もしコードが明確でなければ、それは間違いかもしれない。ユーザーに、続ける前に直すように言わなければならない。」という哲学で設計されてきました。ゴールは、プログラマの生産性で同じですが、生産性を実現する哲学的アプローチが逆です。これは良いことです。プログラマは、いかに最も効果的に問題解決をするかについて、異なる意見を持っています。我々が異なる開発スタイルを奨励する2つのツールを提供することは、良いことです。
最後に、氏は O'Reillyとのインタビューの中で、彼が考えるC#が将来取るであろう幾つかの方向についてコメントした。しかしこれら全ては、彼の個人的な推測であり、公式なMicrosoftの見解ではない、という前置きがなされた。
しかし、Project Roslynに関して、氏がInfoQに確かに言ったのは、Visual Studio と一緒に出荷されている既存のコンパイラは、 Roslynプロジェクトで開発されたものが完成したら置き換えられる、ということである。更に、Roslynの分析ツールが既存のオーサリング時 コード分析に取って替わる。（これは、コードがVSエディタウィンドウで書かれると、リアルタイムでフィードバックを返すコード断片である）。
氏が今日現在、明言したかったのは、現時点でVisual Studio 2012に含まれているフィーチャに勝る C#/VB言語バージョンの「特別なフィーチャセットが既に念頭にあるわけではない」ということである。今の時点で、Microsoftは、C#5の後継ために「何か特別なフィーチャセットを念頭に置いているわけではない」が、どのような言語研究領域が力添えを提供できるかを見極めるために、業界の傾向を良く観察している。彼のグループは、業界でよく見る問題とその可能なソリューションの両方をより明確にしようとしており、彼のグループは、まだ調査段階である、と彼は述べている。