Fabulous Adventures In Coding
Eric Lippert is a principal developer on the C# compiler team. Learn more about Eric.
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 versionPri 2: Should have in the next versionPri 3: Nice to have in the next versionPri 4: Likely requires deep study for many years before we can do itPri 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.
PingBack from http://blog.a-foton.ru/index.php/2008/10/08/the-future-of-c-part-one/
Since you can't write about the features in bucket 1 at the moment maybe you could write something about the features in bucket 4 or even 5 - you know not the stupid ones that were obviously bad ideas but the promising ones that seemed very interesting at the beginning but than ... something aweful happenend and now it is extremly unlikely that they will ever become features of some future version of c#.
But maybe I'm the only one who would find this interesting ;)
Visual Studio 2010 and .NET Framework 4.0 Overview
Argh.. Tease. I see a blog headline like "The Future of C#" and then we're told to wait! Do you have any idea how torturous this is for a rapid .NET fanboy ;-)
When I read this blog post (just having finished viewing Anders Hejlsbergs presentation at the JAOO in Denmark a few weeks ago), it's probably not too hard to see where the trend is going for programming languages in general. Everybody is talking about dynamic languages (dynamic keyword?), parallelism and concurrency but then again, we won't know until PDC.
I'm just hoping that supprt for covariant return types made it to bucket 1 but I'm not going to start that debate again; somebody might step up and slap me at PDC. Then again, if this indeed is going to happen I promise to send champaign to the C# team - honestly.
@Frederik - I'd be interested in seeing that as well.
Like everyone else, I'm looking forward to hearing what's going to happen. One particularly interesting point sprang out from your post though:
"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."
Those are all relevant costs for Microsoft, but not for the language itself. I'm not saying they should be ignored - far from it, I do understand the practicalities of it. However, I'm possibly more interested in the costs of adding complexity to the language in terms of the difficulty of developers learning it and using it effectively.
What I would love to hear some time (but probably never will!) is a list of features which are useful enough to merit inclusion in an abstract sense - i.e. they would make the language genuinely better, despite the added complication - but which won't happen due to the real-life cost of design/implementation. It seems to me that the dollar cost of designing/implementing a feature is likely to be significantly easier to measure than the complexity cost.
Awww , when I saw the title my blood pressure started to rise and my and I could feel my heart beating while devouring the article .... till the I saw the end of it, it was just a teaser :(, this is so cruel. (Kidding about the cruel part ;) )
Can't wait for next your posts, you guys are certainly my superheroes, keep up the good work.
No C#! Thank God! C# lives, and C# lives forever. A thousand years from now, Virginia, nay, ten times ten thousand years from now, C# will continue to make glad the heart of childhood.
"Of course, I note also that we have not announced that there even will be a language called C# 4."
I knew it! Visual Studio 10 will replace C# with a hybrid of Logo and APL. You read it here first, people!
A similar thread exists on Stackoverflow.
Please give us call/cc (call-with-current-continuation) :)
I'd very much like to see what was in the fourth and fifth buckets, yes.
It's even more interesting than the first two, methinks.
another vote for the 4th and 5th buckets