Posted By: Charles | Jul 10th, 2008 @ 12:36 PM | 149,058 Views | 59 Comments
What's the C# team up to these days? Who's on the C# 4.0 design team, anyway? With the looming problem of manycore facing developers now and certainly in the near future (to a much greater extent - programming for 80 core (asymmetric to boot) processors, anyone?). I thought it was time to find out what Anders et al are working on to get a clear sense of C#'s near (and not-so-near) future so I asked if I could come to one of their design meetings to have an informal chat (are we ever formal on C9?) and meet the people behind the next iteration of the most popular .NET programming language.

There are some new faces (and some old ones (not in terms of age, mind you Smiley). As expected, merging functional constructs into imperative C# are still top of mind for the C# design team. Here, you'll meet some new programming language gurus and some old time Niners (you'll recall the great Eric Lippert. He was in fact the very first developer we interviewed for C9 back in 2004 - even though his was not the first interview posted, it was the first one shot and the one where Lenn, Jeff, Scoble, Bryn and myself looked at each other and said "wow, we are on to something here!".).

C# 4.0 will contain many new features that will help developers be, yeah, you've heard it before, more productive. There's also some very interesting work going on with adding dynamic constructs to the language, which is of course very interesting given the static nature of the C# language.

In this video you will not get any specific details since the C# team wants to reveal exactly what they've done at PDC 2008. That said, you'll still get a very clear sense of what they've been up to and where they're taking the language.

It's always a pleasure to chat with Anders and team. I think you'll enjoy this one. On a personal note, I was coming down with a cold during this interview so please excuse the asking of the same question more than once (though in a different context). Oh, the joys of cold medicine. You know, the same stuff Lenn was on when he conceived the idea of Channel 9 several years ago.
Rating:
22
0
LiquidBoy
LiquidBoy
Silverlight
I have nothing but awe for these guys, such pure thinkers.

One thing i want to say regarding a point they were discussing around how does a general purpose programmer (GPP) get up to speed with new features, in particular the parallelism problem. I would have to put my hand up and say that i am a GPP and that ever since C# 3 i have been struggling to keep up to date with alot of the new features . It's been a year since i started heavily using features like linq and lambda's, anon types, object/col initializers etc and im just getting the hang of them. The point im trying to make is that not everyone will make the transition to fully understanding these new features, what is required in todays world are teams of developers that have strong skills in some areas and a mediocre understanding in other areas eg. when recruiting for team members, whilst it's great to get people that have great understanding of all c# features  it's near impossible to find anyone that fits that skillset. So we go for people that compliment other peoples skills.

With parallelism, when it finally makes it into C# i forsee people that specialize in parallel coding (just like in the days of threaded programing), if we need that skill in our team then we'll hire skilled people that understand it well, and these people will balance out the other people that don't know it at all (and probably don't need to know it). Not everyone will be able to take that leap into parallel programming and I honestly believe not everyone should need to make that jump.

My days and remaining braincells are spent on Silverlight & WPF, but what cells i have free is dedicated to DLR Smiley

Great talk guys, and looking forward to the next interview!
Why does the interviewer keeps repeating the words "outstanding" and "excellent"?  Smiley
JoshRoss
JoshRoss
A righteous infliction of retribution manifested by an appropriate agent.
Isn't f# and spec# supposed to be a first class citizen in Visual Studio.Next?  I'm surprised to not hear anything about them in this video.  I can understand that as the different CLR languages grow conceptually further apart the amount of plumbing, within each language, will increase just to handle the requirements of calling code from one language to another, such as handling or acknowledging Spec# contracts when called from IronPython, in a reasonable manner.

Since all of these languages more or less have to interoperate, how important is it to have all this plumbing in-place, with a plan to abstract it to a high-level, when a new feature is added to the runtime to enable a new language that provides a better mechanism to perform a task in some domain?

When I think of what domains have not been addressed in the managed world, the first thing that comes to mind is low-latent problems, such as audio.  Next would be precision and optimization problems that are present in science and mathematics.  F# looks very promising in this field.  And, its promotion to a first class language must be very relieving to other .net language creators who might otherwise be pressured to stick some of those characteristics into a their language prematurely. Last but not least, how the heck do we leverage the GPU before the GPU leverages us? 
staceyw
staceyw
Before C# there was darkness...
Good show folks.  Great group.  Some things:

1) Always bothered by syncing datatypes like DateTime.  You can't use volatile or interlocked.  So your forced into a full monitor or using a long to represent the datatime.  For simple things like a perf counter class where you need atomic rw but maybe not exclusive access, a lock is too much tax.

2) I always thought another modifier may be good (i.e. "#").  So you could add sync to any datatype:
     private DateTime# start;
     private DateTime# end;

     And the system will figure out the best way to handle access (i.e. lock, volatile, interlocked, etc).  You also get declaritive knowledge for the compiler help.  A variation on this is adding variant sets with "#n", where n represents the variant set such as:

    private DateTime#1 start;
    private DateTime#1 end;
    private int#2 counterX;
    private int#2 counterY;

    So now we have two variant sets that have sync behavior for the respective variant set or "variant bucket".

3) I am not saying the CCR is the right api for the language, but I think the ccr pattern is.  Using Port(s) and async Selector(s) seems generic enouph that it could fit nicely in the language and allow extention points.  Think we need both the TPL model and the async ccr pattern.  So a solution that cleanly allows both would be nice.

4) Naturally, debugging support for locks and sync issues needs more tooling to allow us (and compiler) to find sync issues better.  I like the idea of some pattern that allows me to write sync code, but in such a way that the system can parallelize it safely.  Abstracting as many non-required details as possible.  Required details/options maybe could be exposed as attributes/metadata that gaurd sections of code.

Will enjoy to see what comes next.  Keep having fun.  Thanks.
stevo_
stevo_
Human after all

Yes, as before they even finished C# 3.0, they were planning 4.0... yadda yadda, this is purely talking about the future of C#.. although not much was given away..

I liked what anders was talking about regarding how he thinks concurrency could be tackled (definately correct me if I'm wrong), which was not to think about code as being concurrently designed or otherwise.. but instead, designing the 'parts' that make up your operation.. and letting the compiler/runtime link all those parts together in the best way possible..

Of course, we always need that overall control, so the challenge I guess is how to do all that.. c'mon guys hurry up!

Also I think when were talking about will there ever be any changes to .net, and the question got routed from language to library.. but I think what you were maybe referring to, or at least what I thought you were trying to ask was.. is there any thoughts to changing .NET CIL, as in add to the capability that CIL can describe (such as something like contracts being defined as a pure CIL construct (library aside).

Maybe its just me, but I'm interested in that question.. although I appreciate that ms wants to avoid changing CIL to avoid compatability problems..

Microsoft Communities