Why does C# have ? Why doesn't it have ?

  • Article

Over the past few years, we've gotten lots of suggestions and questions about the
C# language, and we haven't done a very good job responding to them, for a variety
of reasons.  

The first reason is that we haven't devoted as much time as we probably should have
to interacting with customers on the subject of language design. That's something
I'll be trying to improve in the next few months. You can expect to see some more
information about new language features before we give out bits at PDC.

The second is a bit harder to explain. Basically, it revolves around whether a feature
fits into what I'll call, for want of a better term, "The C# Philosophy". Some of
the philosophy can be reduced to guidelines or rules, such as "Simplicity is also
a feature", but there remains a fair portion that is really just based on the informed
judgement of those on the design team. On some issues, that can make it
really hard to communicate why we made a specific decision, as it's hard to put into
words how we make our choices.. In the words of one of the design team members,
"it took me 6 months of design meetings before I stopped making a fool of myself".
For me, I think it was close to a year.

So I don't expect the communication to be perfect. But it should be a lot better.

I'm hoping to devote a number of entries to some of the guidelines we use. Note that
this is really on my view of the philosophy of the design team, so don't view this
as the definitive view. Guidelines I hope to cover:

- Simplicity is also a feature

Magic only when justified
  • Serve the target audience
  • Tread lightly on unproven features
  • Remember that you aren't the customer
  • Solve real problems

I'll try to do one of these each week.