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.
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
What is your position at Microsoft today?
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
- What features provide a compelling customer
- Is our current design one that works for our
- How will features written by other groups
integrate into our customer's experience?
- Are we getting what we need from other
- What are customers asking for? What are their
- 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?
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?
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
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
What is your favorite feature of C#?
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)
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
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)
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
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
(Submitted by mOOzilla)
I'm afraid I can't give a very definitive answer on
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
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)
We have an ongoing commitment to language
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?
The big language features that we've disclosed are:
- 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
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
(Submitted by Ray Houston)
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?
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
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?
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
Is there any plan on adding independent getter/setter access modifiers
to properties in C#?
(Submitted by RMD)
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)
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.
GotDotNet Website (Microsoft)
C # .NET
Introduction to C#, Second Edition
Interested in doing an interview?
contact us for more information.
Return To The Front Page