The Future of C#, Part One

The Future of C#, Part One

Rate This
  • Comments 30

An attentive reader pointed me at this long thread on a third-party forum where some people are musing about possible future features of C#. There is far, far more here than I possibly have time to respond to in any kind of detail.

Also, I am not going to spill the beans. Anders is giving a talk at the PDC at the end of the month. His talk is titled "The Future of C#" and I'm not going to steal Anders' thunder (or give our marketing department conniptions) by giving specific details at this time.

Of course, I note also that we have not announced that there even will be a language called C# 4. We have not announced that there will be new versions of Visual Studio or the CLR either. But we also know that you people who read blogs about programming languages are not idiots. I posted a link to a video a while back where Charles interviews the C# design team; the fact that there is a design team is evidence that we're designing something. I've been posting about adding more covariance and contravariance to the type system, Charlie has been collecting comments about what kinds of interactions people would like to see between C# and dynamic languages. Clearly we're up to something here, and it is not hard to figure out the broad outlines.

This puts me in a bit of a tight spot -- I want to respond to all these great ideas, I want to inform the community about our plans and get feedback early, but at the same time I want to make sure that we don't overpromise and underdeliver, and I want to ensure that we provide information that is fully-baked and professionally presented.

Therefore, I want to talk about these ideas in the context of the design process we go through here, rather than in the context of specific implementation decisions of specific features.

I made a new friend at a birthday party I attended the other day. We got to making small talk about our jobs. I mentioned that I designed programming languages as part of my job. Now, let me tell you, when I say that at a party I get one of three responses: (1) that's really cool, (2) excuse me, I need to refill this drink, or (3) a puzzled look, followed by "you mean, someone actually designs programming languages? I thought they just, you know, sprang into existence... somehow." I informed my new friend that no, in fact there is a huge amount of design that goes into a language -- six hours a week of meetings for almost ten years, in fact, for C# alone.

I've already linked several times to Eric Gunnerson's great post on the C# design process. The two most important points in Eric's post are: (1) this is not a subtractive process; we don't start with C++ or Java or Haskell and then decide whether to leave some feature of them out. And (2) just being a good feature is not enough. Features have to be so compelling that they are worth the enormous dollar costs of designing, implementing, testing, documenting and shipping the feature. They have to be worth the cost of complicating the language and making it more difficult to design other features in the future.

After we finished the last-minute minor redesigns of various parts of C# 3.0, we made a list of every feature we could think of that could possibly go into a future version of C#. We spent many, many hours going through each feature on that list, trying to "bucket" it. Each feature got put into a unique bucket. The buckets were labelled:

Pri 1: Must have in the next version
Pri 2: Should have in the next version
Pri 3: Nice to have in the next version
Pri 4: Likely requires deep study for many years before we can do it
Pri 5: Bad idea

Obviously we immediately stopped considering the fours and fives in the context of the next version. We then added up the costs of the features in the first three buckets, compared them against the design, implementation, testing and documenting resources we had available. The costs were massively higher than the resources available, so we cut everything in bucket 2 and 3, and about half of what was in bucket 1. Turns out that some of those "must haves" were actually "should haves".

Understanding this bucketing process will help when I talk about some of the features suggested in that long forum topic. Many of the features suggested were perfectly good, but fell into bucket 3. They didn't make up the 100 point deficit, they just weren't compelling enough.

Next time, I think I'll talk a bit about the design process in the context of OOP.

  • My vote too for 4th and 5th buckets.

    If you cannot talk about C# 4.0 then talk about what is not in it (and why).

  • With a hypothetical next release of the C# language around the corner (more about that after Anders,

  • Will Microsoft ever care to design a programming language that is good for scientific programming?

    We need a language that supports complex numbers, matrix, and vectors.

  • How about F#?  It is used in the financial and scientific computing communities.

  • Hi Eric,

    Thanks a lot for the pointer. It looks great so far.

    Maybe we are finally coming out of the age of Fortran! If this is true, the potential impact will be enormous!

    It looks like I will have a busy Christmas, in a good way. Thanks again!

  • Is there a cross compiler to convert VB.NET code to C#?  It is on our must have list since we have standardized on C# and away from VB.NET.  This would be a big plus because over time C# and VB.NET should move together and converge into an identical feature set.

  • Hi Eric,

    To be honest, I still do not understand why C# does not have complex numbers built in. It would be such a trivial thing to do. (if there is an exuse for matrix)

    The only conclusion that I can draw from it is Microsoft never cares about what scientists or engineers think or use. We use complex as much as we use double!

    This partially explains to me why Microsoft is disliked on campuses (to put it mildly), which I did not understand for a while.

    While scientists are poor guys who do not buy much software, we do tell our students what to learn and use. That is a lot of potential users and customers!

    If only Java had better support for scientific computing, Sun Micro would not be in its position today.

  • I second Bo's comment about adding complex number support.  The engineering community is a large relatively untapped market...we would love to be able to see native support of complex numbers in a compliler!

    True, there are many third party numerical libraries available that fill this need, but having a built-in complex type would greatly simplify the use of these libraries -- remember most engineers are engineers, not elegant programmers.  I don't see it as creating bloat or complexity (pardon the pun) in the existing Math library...it would require overloading for Abs, +-*/, exp,log,and trig functions, as well as the creation of a new ' (conjugate) operator.

    Please, please, please.  Minimum effort/code change on MS part in exchange for much wider (and well-funded!) audience.

  • Welcome to the 47th Community Convergence. We had a very successful trip to PDC this year. In this post

  • Tenho que pagar uma dívida aqui. Falei na volta do PDC que iria falar sobre variância e contra-variância

  • Very good resources for the coming version... Sam Ng Dynamic in C# Part One Dynamic in C# Part Two Chris

  • Is conversion included?: Last February, I converted a 100,000 line VB.NET code base to C#. Didn't manage to find a tool that makes it painless.  Let me know if you want details (<reinpost@win.tue.nl>).

  • User : The typeof(T) operator in C# essentially means “compiler, generate some code that gives me an

  • Пользователь: Оператор typeof(T) в C#, по существу, означает «компилятор, сгенерируй некий код, который

  • (Old discussion, but I just cannot resist.)

    Bo said:

    "It would be such a trivial thing to do."

    How do you know this?  What knowledge of the world--or even just of the c# compiler codebase--do you possess from which you can derive any confidence in this belief.  You are, nevertheless, so confident, that you go on to assert the following:

    "The only conclusion that I can draw from it is Microsoft never cares about what scientists or engineers think or use."

    You are so perfectly sure that the thing you want is so trivial that the only possible reason that it has not been implemented is that Microsoft (as a company) does not care about you and your colleagues.

    Perhaps Microsoft is disliked on campuses, as you say, because people like you judge motives instead of trying to understand the enormous problems they face and to appreciate the significant contribution that they have made to human civilization.

Page 2 of 2 (30 items) 12