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. [Eric Gunnerson's C# Compendium]