Interview With Anders Hejlsberg
The architect of C# and Microsoft Distinguished Engineer speaks out on C# futures, security, and more.
by Elden Nelson

VSLive! SF, Day 3, February 14, 2002 — Anders Hejlsberg is a Distinguished Engineer in the Developer Division at Microsoft Corporation. Well-known for inventing Borland's Delphi programming language, Hejlsberg is the chief designer of C# and a key participant in the development of the .NET Framework.

Together, Hejlsberg and Bill Gates were the VSLive! keynote presenters yesterday, celebrating the launch of Visual Studio .NET. Following his presentation, I talked with Hejlsberg about C#, the .NET Framework, security, the ECMA standard, and more.

Q. What's the general impression you're getting from developers as they try out C#?
I'm really happy with where we've ended up with C#. C++ developers are seeing a short learning curve as they pick up the language. They're feeling empowered, productive, and even talk about having fun again as they're writing code. Which, ultimately, is really important. What does it matter whether you're productive if you're not having fun? That's what really drives developers.

Q. Much of the .NET Framework was written in C#, making Microsoft its own first customer with this language. You must have paid attention to the roadblocks developers encountered as they wrote the Framework with this language. What changes has the language made since your first cut at it?
I think there were almost too many to enumerate. We had a feedback cycle throughout the whole design. One that I could mention is the "using" statement we ended up adding, which allows you to control the lifetime of an object in a structured fashion. Another—sort of part of the language, but also the platform—is how you can define types so that everything's an object, as opposed to having an object and a variant type and so forth. There was a lot of pain involved in getting that just right.

Q. As you got C# ready for market, what had to be left on the cutting room floor?
Well, the most prominent feature would be generics, which we will see in a future release—I can't tell you which one. But we are working on that. There are a bunch of smaller features, but that was the big one.

Q. As you built the respective languages in VS.NET, was there collaboration between C# and VB.NET language development teams?
Absolutely. In fact, there are common parts of the compilers shared between the two languages. And I suspect that over time, the compilers will share more and more. There's definitely a lot of commonality.

Q. Why didn't this collaboration extend to the new keyword naming conventions? For example, "sealed" vs. "noninheritable"?
Each language has its own personality. C# has a very strong C++ heritage that we want to preserve. VB.NET has a more verbose style. I think the VB team wanted to make sure their product suited the VB customer. Ultimately, the VB customer cares less about whether their keywords are the same as the ones in C#.

Q. Now that VS.NET is released, have you been able to measure C# app performance compared to native C++?
That's a very tricky question. It really depends on what the application is doing. I could show you apps that run faster with managed code; I could show you apps that don't. Some of the mandatory things we do to enforce type safety and so forth come at a cost, though at less of a cost than you might think. The problem with this question is that it assumes infinite developer time and resources. So sure, given infinite time and resources, you'll do better with C++. But in the real world, what are you trading off? The fact is you get a slight performance tradeoff for dramatically better productivity, allowing you to focus on algorithms instead of housekeeping. And actually, you might come out a little bit ahead, because you wrote a better program.

Q. C# has been ratified by ECMA, making it a fully public language. As such, is it more susceptible to security problems?
That's an interesting question—I hadn't thought about the open nature of C# in that context. C# certainly contains features that are "not safe." But they are known not to be safe by the execution environment. Basically, you say, "Here comes a piece of unsafe code; I know what the implications of writing this are. Namely, I will not be able to run unless I have full trust in whatever context I'm running. But having said this, now I can call this old API or manipulate pointers or so forth." I actually think our approach to this problem is the correct one, compared to Java for example, where it's either 100 percent pure or you fall off the cliff. With those, there's no cooperation between the language and the execution environment. We believe in taking a more coherent and throttled approach to the problem. And certainly if you implement the Common Language Infrastructure (CLI) according to spec, these are not security issues.