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

). 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.
Follow the Discussion
Oops, something didn't work.
What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in. You need to be signed in to Channel 9 to use this feature.What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in and view them all on your notifications page.sign up for email notifications?
Still trying to grasp all the stuff in the last few versions...
I guess the next few things are for them to create the following "Global Methods"
DoWhatIMeanNotWhatISay(Program P);
SaveThisData(Class C, DataBase DB);
MakeThisDataBaseIntoOOp(Database DB);
oh and:
WriteMyApp( Object FuzzyIdeas);
just a few simple productivity helpers like that
C
Fascinating interview. I found the most interesting part was when the conversation was turned to concurrency.
If there's one thing I'd really like to see in C# 4.0, then it would be covariant return types. I know it's going to take a new version of the CLR, but please take it into consideration (once more).
Not sure if it's my connection or something else
C
EDIT: I downloaded the file without any problems (DSL).
Where he was for so long time?
<bad neo impression>woah.... </bad neo impression>
has erik left the c# team btw? or was he just not available?
man ive been waiting for ths :O
--
btw i ve tried for a few days to reply tto the app virtualization thread but i cant :/ nothing happes when i click add.. i can reply to this thread though so i got no idea whats wrong
gonna contine watching the vid now
Now, I am off to go watch this.
Great work getting these vids up - thanks a lot.
~sparky
So if the team is going to consider wish lists; mine is here!
Thanks!
c# really balances the addition of new features so that they are meaningful and not redundant
linq is the perfect example of this, it uses the good ol Ienumerable interface and foreach loops that have been around forever but its so incredibly powerful
lambda expressions are really just delegates (unless they are expressions
i guess what im saying is that c# allows yo to leverage what you already know in a way that no other language do. that whole thing about starting at -1000 point.. the c# team has really really done a good job of keeping that number close to 0.
My download of the large WMV bailed out too. Odd since I normally have no problems what so ever downloading the larger (>1GB) C9 videos...
Excellent stuff - I have say, I enjoy Anders, E Meijer and the PFX team interviews. I hope to see more of F# folks in the near future. I wish I can work with these any of these groups - they do such cool stuff.
I hv been waiting for likes of this for a long time....
Anders is just gr8 ....
Thanks,
C
I was trying to download from the Netherlands, from a town near Eindhoven. and will add that I normally have absolutely no problem dowloading (really) big files whatsoever. Thanks for looking into it
Many great developers use VB. It's a very powerful language. For example, the great Brian Beckman uses VB. Erik Meijer uses VB (in fact he innovates the language to be extremely powerful, yet easy to use.... That was my point exactly, in context.)
My apologies to all I've offended.
C
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
Great talk guys, and looking forward to the next interview!
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.
Our file hosting service provider has told us that they are unable to find a problem (they tested their servers in Europe and can't duplicate the error). They tell us that the problem could have been a transient one due to ISP overload or router issues. They say: "At this point it looks like an intermittent issue that may have passed, perhaps a congested ISP or router on the last mile."
Have any of you tried running a tracerout from your PC to mschnlnine.wmod.llnwd.net? In order to figure this out they need more data. For example, how are you downloading the file (right-click, save as? Playing the video in your media viewer application? Etc...)
C
C
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..
Well, what I asked I in fact thought about before interpreting and conceptualizing ideas, constructing the word patterns to describe the idea and finally delivering it by mouth.
The question is based on the notion that
If your runtime and default libraries are capable of providing functionality that can address specific hardware configurations (especially the runtime engine, but so too the collection of classes that you program with...), then the languages used to manage the manageable parts of the runtime can be very thin. TPL and CCR demonstarte that libraries (with support in the base virtual machine when necessary(e.g., Generics, etc) can provide sufficient capability to program (express) parallelism. So, my question was aimed at exploring the necessity of adding the same or similar functionality to the syntax of the language.
C
It sounds like there's an exciting opportunity here to combine those two and get run-time specialization of code.
E.g. if you have a regexp matcher that takes a regular expression and a string and returns true if it matches, you could specialize the first parameter of that function for a specific regular expression (which isn't known at compile time, only at runtime) and then run that specialized version on ten million strings. The benefit is that the regular expression would get hard coded into the specialized version so that the matching doesn't have to "interpret" it each time. There's a cost involved in doing thie specialization, but quite often you'll use it so often that the benefit outweighs that cost.
Seems to me like compilation can be viewed as basically the act of "baking in" known facts about your code (e.g. the size of a variable) into machine code so you can execute it faster. Well I'd say that many applications will have "known facts" that may not be true for the entire duration of the program, but will at least be true for "long enough" that it's worth baking them in anyway. Another example is an image filter, where you take the filter kernel and compile it down into machine code and then run it over the image (because the kernel won't change for the duration of the filter operation). A third example is a game where you load a game level, that level won't change for several minutes at least so it would be cool if you could "bake it in" and do all sorts of optimizations under the assumption that the game level is "constant" for some duration of time (e.g. inline calls that are virtual, but since the data is constant you know exactly where you need to go, unroll loops, recursion, do standard constant folding etc.).
Anyway, this is my pet idea for a "killer app" where you'll see all C++ advocates gladly switch to C# for the increased performance, and if you have both meta programming *and* runtime code generation/loading you're basically almost there.
Here is my list: http://jrwren.wrenfam.com/blog/2008/05/15/c-vnext-feature-request/
Left out of that list is my request for an extensible literal system. We already have the wonderful TypeConverter system in the BCL. The compiler could use that and I could have extensible literals in the language. Short of that, just list and dictionary literals would be great.
It should be obvious, but this is the thing plaguing software teams; we write buggy code and we spend a lot of time writing unit tests, physically testing, debugging, and doing formal code reviews -- all in an attempt to get rid of bugs.
C# 4 should add some constructs that help us write software with fewer bugs in it.
For me, this means integrating some of the excellent research done over the last several years by the Spec# guys. The design-by-contract stuff would help us rid our codebase of mistakes developers often make when working on large, complex, real-world software systems.
Great video, Charles!
With regards to the dynamic typing-static typing dichotomy, it is not either-or. It is not only-but also. We want not only the affordances of dynamic typing but also the assurances of static typing. Type inference sorta fakes us out into believing that it provides this, but it's still static typing, and there are limitations to that approach that cannot be worked around until changes to the type system are made.
Java and C# have been around for a while, long enough to where people will grumble if you make too many changes to the language. If it is impossible to make changes to the language without incurring "-1000" penalties, then maybe it's time for a new language (or perhaps an old one whose time hadn't quite yet come...) to step up and pave the way for programming language innovation. Better ways of getting the job done is the goal.
Sounds like your talking about F#. Looks dynamic, but static types and a new language.
Impatiently waiting for this version of C#.
Charles (I mean the Charles who wrote the post (as in the one who signed his name (you know Charles))),
You forgot to close one of your '('s
Thanks for testing
C
ff
Even if included as language features, I feel a LINQ-like provider based model (which allows users to write their own providers) would allow the most flexibility since multi-core processor development is going to be in flux around the time C# 4.0 might be released. Allowing people to decide the model of concurrency to be used, while supporting basic constructs (I feel COmega has some very nifty ideas there). It is also entirely possible that the "scalar" processors we run some part of the code on, may not be x86 (Tesla?).
In all, this is the perfect direction for C# to be heading in. But please, pretty please(?) give us, the developers ways to extend and control this beast's innards.
Thanks.
It seems to me that the ability to have statement blocks as expressions could be very powerful, for example; you could have an expression as the handler for an enumerator, this could be useful for tools like linq to sql.. because you could do analysis against the expression, and determine which properties are being used.. and thus you could optimize the query to return just the fields that should be called..
I know that example isn't a guarentee, there would be rules about unsafe code still, and you would still need control over this optimization happening or not.. but thats just an example of things that could happen..
http://research.microsoft.com/research/downloads/Details/8826adb9-8398-40d6-a22d-951923fe2647/Details.aspx
Enjoy!
C
Finally, congratulations to Microsoft and the C# Team past and present on a world-beating product and apologies in advance and please excuse me if I have been presumptuous in any of my questions.
I have a question why the below mentioned code snippet is a forever loop in C# 2.0... I haven't tested it in > 2.0 frameworks but I bet the behavior won't be different..
for (byte index = byte.MinValue; index <= byte.MaxValue; index++)
{
// do something forever untill the stack is exahausted...
}
I know the reason but I would like to know the what was exact design decision related to it the way post increment ++ operator is implemented for the BCL type BYTE...
Email: tricky.vikas@gmail.com / gupvikas@hotmail.com
Guys, I'm current C# user and I use a lot of threading code especially when it comes to delegating on multiple cores. I would like to use my democratic voice to influence some of your decisions, hopefully!
I had many projects in my past year where I
had to write code that interfaces with hardware such as application that was using C# driver and wrapper around Canon’s digital camera SDKs. I managed to write code in pure C# (of course a lot of it was unsafe and with pointers, but still in C#). Let me tell
you something… If it wasn’t for the currently available mechanism in C# when it comes to threading, I mean, the way I create, control, and synchronize the threads and so on I would not be able to do what I’ve done in the past year, especially driver for 60+
models of different cameras in pure C#… The control and power that I have over my threads was phenomenal I just hope you won’t take this away.
Also, I’m closely watching COSMOS (http://www.gocosmos.org/index.en.aspx) project and because of the some “high-level” features it is not yet possible to emit directly into machine code, so netwide assembler is used. I hope that you guys would think about bringing those kinds of features into C# also the ability to talk to hardware directly without any 3rd party APIs and I know it is possible now at some level because I’ve done it with digital cameras through USB but one day I’d like to see a jet flying with C# OS instead of Ada written code…. Please add more cool low level features, I love C# more than C/C++ and I would like to see more stuff like that happening. If they can write a control panel (http://farm1.static.flickr.com/131/384637216_4c85a7bbd8.jpg?v=0) in DotGNU for a laser in Europe why can’t we have more for system programming in current official C# distributions?
http://flickr.com/photos/t3rmin4t0r/384637216/
J/K >- Hi! My name is "Blank" and I’m a C# addict, I WANT MORE LOW LEVEL FEATURES in C#!
Congratulations C9! this video very, very interesting ...... still more with a team's expert.
I'm waiting for C# 4.0...
see you later....
good stuff.........
Remove this comment
Remove this thread
close