The Active Network
ActiveWin: Interviews Active NetworkEditorials | Reviews | FAQ | Mailing List | Forums


Interview with Eric Gunnerson, Program Manager: Microsoft Visual C# .NET Please introduce yourself for our readers and give a small background, just a short paragraph to keep it simple.

Eric Gunnerson: I started programming in 1979 on a Alpha MicroSystems Z-80 based timeshare system. I've worked at 4 companies professionally, writing engineering software, database software, and utility software. At one time or the other, I've been fluent in Pascal, FORTRAN, C, C++, and now C#. Oh, and Perl.

I've worked as a developer, a developer lead, a tester, a test lead, and a program manager. I wrote "A Programmer's Introduction to C#" (Apress), and I write a C# column for MSDN online.

In my spare time, I cycle (both kinds), ski, dabble in microcontrollers, launch rockets, and play far too much Xbox live. What is your position at Microsoft today?

Eric Gunnerson: I'm a Program Manager on the Visual C# .NET team. Program managers are a unique Microsoft discipline that I should perhaps explain a bit.

On a typical Microsoft team, there are developers who write the code, QA members who are responsible for the quality of the code, and User Education members who write the documentation. And then there are Program Managers, who are focused on the final result and enabling the team to get there. We try to answer questions like:

  • What features provide a compelling customer experience?
  • Is our current design one that works for our customers?
  • How will features written by other groups integrate into our customer's experience?
  • Are we getting what we need from other Microsoft teams?
  • What are customers asking for? What are their problems?
  • What state is the product in? Are the new features working, do they make sense, etc.?
  • Is our team on track to hit our milestones?
  • etc.

The interesting part is that PMs have no reporting authority over the team members they work with - the developers and testers do not report to them. They are successful based on their ability to help their team determine the right goal and reach it. If I had to come up with one phrase, it would be "Professional Technical designer, organizer, facilitator, and customer interactor".

I own all of our community activities (conference attendance, advisory groups, online customer interaction), and I also own the C# project system (though the developers are not on the C# team). I also own our content on What's it like being on the C# language design team? What is a typical design meeting like?

Eric Gunnerson: I've moved off the design team as I've been less involved with the language. The bulk of my involvement came on the 2002 release.

Language design is a huge investment in time, since there are thousands of small details that you have to decide on, even if it's unlikely that any C# programmer will hit that case in a year's time. But it's also hugely rewarding, and working on a new language is a once-in-a lifetime opportunity. I'm really only a semi-professional language designer, but I think I was able to offer a useful perspective on the design team. Oh, and I should mention that I got to work on a really great team - Anders, Peter Golde, Scott Wiltamuth, Peter Solich, and Todd Proebsting are all very skilled technically, not to mention being really great people.

Design meetings usually follow one of two models. The first is when we have "special guests" to talk about a specific issue. It could be the SQL team talking about the problems they've encountered trying to write nullable types, or Jim Blinn to talk to us about performance issues in trying to write fast C# graphics code, or somebody from the CLR team to discuss a shared bit of functionality. Those meetings are always fascinating.

The second type of meeting involved just the design team. We always had a list of issues that we needed to resolve, and we'd try to pick the ones that we could make progress on. For months we had one named "backtick strings", which languished at the bottom of the list. The goal was to come up with an alternate syntax for specifying strings. We tried several times to make progress on the topic, without much success. We then reached the point where we'd cover most of the issues we could make progress, and somebody would say, "well, we could always work on backtick strings", which would swiftly lead to the end of the meeting. We got it in the end, though, and verbatim strings are a very good feature. They do what you need, and they don't do more or get in your way, and they're easy to understand.

Oh, and it was fairly common for us to have one of the compiler developers stop by to either ask for clarification on a how something should work, or discuss an issue he found when doing compiler development. What is your favorite feature of C#?

Eric Gunnerson: The plus sign. Definitely the plus sign. Not a big fan of minus.

I think this question is the analog of asking a parent which child they like best. I avoided that question by only having one child, so I guess I'll try to answer this one.

I think attributes are an absolutely killer feature, and their design is very clean and elegant. They give you a new option in how you structure frameworks, which makes a huge difference in our overall approach.

I'm also a big fan of foreach. If I only had a small percentage of the money wasted worldwide writing:

for (int i = 0; i < arr.size; i++)
Employee e = arr[i];

I'd be set for life.

But I think my absolute favorite feature is really a non-feature. As we like to say on the design team, "Simplicity is also a feature". I spent a fair amount of time writing and testing C++ code, and while I was pretty good at templates, I never fully understood them, and reading other people's templated code was always a pain. I read a comment once that programmers don't like languages that make them feel stupid, and C++ certainly did that to me a number of times. C# is definitely my kind of language in that regard. After going through the process of creating a new language and looking back, is there anything you would have done differently? (Submitted by Ray Houston)

Eric Gunnerson: In using the language, there are a couple of areas where I'm not satisfied.

The first has to do with having both .Equals() and the overloaded operator==. It's unfortunate that we have to have both, and this is a case where the intersection of what we wanted in the language and what we built in the CLR didn't work that well.

A similar area has to do with indexers and IEnumerable, and that there's no synergy between the two of them.

Those are the ones that come to mind. There are areas where we explicitly considered additional functionality and decided not to, but we were trying to tread carefully, as C# is already complex enough. If we really like those features later, we can add them then, but it's virtually impossible to remove language features. One of the largest criticisms (at least that I've heard) of C# today is that it copies from, or is a cheap knock-off of, Java. What do you say to these critics?

Eric Gunnerson: When we started with C#, we wanted a language that was comfortable for C and C++ programmers. Because of that, much of the C# syntax comes from C and C++. Java took a similar approach, and since both languages run in managed environments, it's not surprising that there are more than a few similarities.

But if you look at our design goals, I think that you'll find some core differences between C# and Java. Java values protection higher than C#, and C# values capability a bit higher. C# is willing to tolerate a higher chance of abuse for increased expressiveness, which is why we have things like unsafe code, operator overloading, and unsigned types.

While we had this approach from the start, we were guided in our design by the needs of the .NET Base Class Library team. If C# wasn't good enough in some area for them to write their code, we'd see if there was a way to make their job easier. This gave us an excellent proving ground for the language.

There results is that there are considerable differences between the two languages. A short list is unsafe code, unsigned type, user-written value types, boxing, explicit interface implementation, non-virtual methods by default, override, different method lookup rules, attributes, foreach, multi-dimensional arrays, events, delegates, and the using statement.

Programming languages have been around for a long time, and the pace of evolution is slow. Most successful languages are evolutions of existing languages, and if you know a lot of languages, you will see a lot of similarities. I think discussions about copying are largely irrelevant to the real issue, which is whether the language is well suited for the task that it's designed for. I don't care, for example, that foreach is a concept that is in both Visual Basic and Perl. I just care that it makes my job easier. How is C# seen within Microsoft? Is there a big push by developers to get their PMs to start projects in .NET? (Submitted by RMD)

Eric Gunnerson: There are big pushes towards managed code throughout the company. It's quicker to write, easier to maintain, and reduces the security surface area of your code. The majority of our programmers are C/C++ programmers, and most groups are using C# as their managed language, though some are using MC++ because they need the extra control.

Different groups will move at different speeds, however. Most of Microsoft's web properties have moved to ASP.NET as their technology of choice, and most are written in C#. In the developer division, virtually all of our work is in the managaged area, and you shouldn't expect to see much unmanaged code in the future.

For applications that have large codebases - like Office or Visual Studio - it's going to take a while to move to managed code, simply because of inertia. There is also some latent skepticism about the speed of managed code, though the work the DirectX team has done on DX9 has quieted some of that, as they've gotten very close to unmanaged code speed. What is your vision for C# on platforms other than MS Windows in the future? (Submitted by mOOzilla)

Eric Gunnerson: I'm afraid I can't give a very definitive answer on this one.

I think it depends upon whether there is a business case for us going to other platforms. I can think of scenarios where it would make sense for us to do so, and scenarios where it wouldn't. Is there plans for ECMA and possibly ISO certification of the new C# features? If so, in what kind of timeframe could we expect to see those ratified? (Submitted by eldoen)

Eric Gunnerson: We have an ongoing commitment to language standardization.

There was an ECMA meeting a week or so ago to work on standardizing the new features, and there will be ongoing meetings to get to standardization. I'm fairly sure that once they're standardized in ECMA, we will fast-track to ISO as we did with the original version of the language.

I don't know about the timeframes we're working on, so I really can't go into details, but I expect that they'd be similar to those from the first version. What is in store for C# for .NET 2.0?

Eric Gunnerson: The big language features that we've disclosed are:

  •  Generics
  •  Iterators
  •  Anonymous types
  •  Partial classes

Generics are, of course, a long-awaited addition, and I'm really happy with our implementation. Java chose not to require JVM changes for their implementation, and while I understand why they decided that, I think it's unfortunate that you can't have a List<int> that performs well.

Iterators just make it easier to make classes foreach-able, and partial classes make it much nicer to use designers that generate code. Anonymous types are used to write delegates using an in-line syntax rather than having to refer to a separate delegates. You can find some more information on http:/

I've been spending some time writing code with these features, and I'm pretty happy. I think the language is in good shape for the next release.

On the IDE side, we haven't disclosed anything new yet, but there are some great features in there as well. What do you foresee to be possible future obstacles as the language progresses? (Submitted by Ray Houston)

Eric Gunnerson: I think the biggest likely obstacle is trying to do too much with the language. In the 2.0 version, I think C# is close to optimal, and future additions may not improve the language as a whole. There may be interesting language-related solutions to important problems, but it's not clear that those solutions should be in C#. They could be in a derivitave language, or perhaps an all-new language. I don't want C# to become baroque, in the "Jargon File" sense. What would you say to someone who can't decide between C# and VB.NET as their .NET language of choice?

Eric Gunnerson: First, read Dan Appleman's E-book at

Next, look at yourself. If you're a C++ or Java programmer, C# will probably be more comfortable for you. If you like the VB syntax, try VB.NET

Then, look at your situation. What language do your programmer's use now? What do they like about it? What resources are available in your area?

Finally, try writing some applications in both, and see what you think. If you're running a team, doing commercial development, the you probably need to standardize on one. If you're thinking for yourself, learn both languages, and see what on you like better.

Also, keep an eye out for the next version of Visual Studio. As we move forward, there will be more differentiation between the language experiences in the IDE, and my guess is that you'll find that one fits your style better. Is there anything that you're planning on removing from or changing in, as opposed to adding to, C# in the next couple releases?

Eric Gunnerson: I don't know of any big things for the upcoming release. We haven't disclosed all the language changes, so I can't comment in more detail right now. Is there any plan on adding independent getter/setter access modifiers to properties in C#? (Submitted by RMD)

Eric Gunnerson: We've discussed this a fair bit. We understand the utility of being able to do it, and we've certainly gotten a lot of customer requests, but there's a complexity cost to doing it.

So, we're considering it. Are there any plans on making C# more XML friendly? There have been rumors about a new XML-friendly language for .NET called X#, and we were wondering if any of the features might work their way into C#? (Submitted by eldoen)

Eric Gunnerson: This is another area where we have ongoing discussions. It would be nice to make dealing with XML easier, as it's not very straightforward now. But XML has a very different approach to types than C# does, and it's not clear to me that you can marry them in a useful way.

There's also the complexity argument, as this sort of feature that could make the language a lot bigger.

Additional Information:

GotDotNet Website (Microsoft)

C # .NET

A Programmer's Introduction to C#, Second Edition

Interested in doing an interview? Please contact us for more information.

Return To The Front Page


  *   *