To read this article in its entirety, please visit Visual Studio Magazine: Q&A: Microsoft's Lisa Feigenbaum Talks about C# 4

MD: Is Microsoft still heading toward its vision of the "compiler as a service" for future versions of the C# compiler?

LF: Yes, very much so. "Compiler as a service" is a project in which we're re-writing the C# compiler in C#. In the process, we're opening up the compiler and exposing managed API's, so that you can query the compiler for information that was previously hidden behind a "black box." This change will enable several scenarios, including a richer language object model to support third-party extensions, the creation of a Read-Eval-Print-Loop, DSL embedding, and the ability to host C# in other contexts. We started on this project a couple of years ago, and plan to ship it in a future release, yet to be determined. It is a huge undertaking, and will take some time still to complete.

MD: .NET 4 and Visual Studio 2010 codified the "co-evolution" strategy for C# and Visual Basic. There are obvious and critical benefits here -- not the least of which is respecting the core value of .NET as a universal framework -- but what challenges does Microsoft need to manage as VB and C# evolve? Is there, from a language development standpoint, a strategy behind the strategy?

LF: Yes, while there had been attempts in the past to differentiate C# and Visual Basic, we've found that both developers actually want the same features, and therefore we've committed to providing the same major features in both languages. This is quite evident in the Visual Studio 2010 release, where new features were added to both languages together, and parity features were added to fill in existing gaps.

From a language design perspective, our philosophy is to add the same functionality to both languages, but to implement features in a way that feels natural to each language. Both C# and Visual Basic have their own unique styles, and we want to preserve that. Therefore, we won't necessarily implement features in a way that looks exactly the same in both languages.

One challenge we faced when pursuing this strategy in the VS 2010 release was determining the best practices and processes to implement it. On the language side, we have joint language design meetings where we discuss the high level feature plans, and then break up into C# and Visual Basic meetings to iron out the syntax. On the IDE side, we can do even more in common and we generally have one specification and one team to implement the feature for both C# and Visual Basic.