C# 4.0 and beyond by Anders Hejlsberg

Thanks for posting this wonderful presentation. 

Please follow up with more from DevDays 2010. Also, the video and audio quality are superb! All encodings of presentations should be this good.

I wish Anders would've clarified what his problem with optional parameters is. He mentioned the Ceremony versus Essence thing, but at the same time he's suggesting that he'd rather see

class MyClass 
{ 
MyClass() : this(string.Empty, null) 
{ 
} 
 
MyClass(string someString) : this(someString, null) 
{ 
} 
 
MyClass(string someString, Object someObject) 
{ 
// Do something with someString and someObject
 } 
} 

than

class MyClass { MyClass(string someString = string.Empty, Object someObject = null) { // Do something with someString and someObject } } 

which is far less ceremony and far more essence than the former.

Edit: well, the code layout is messed up so my point is lost. Thanks again, Channel 9 forum software.

I agree, Bas. Coming from VB6, I don't know why there's so much hate for optional parameters. I'd much rather have one constructor to maintain than 5 constructors that just pass a default value into the "real" constructor.

about the video quality, maybe thats because these DevDays videos use the WMV(High) version (_2MB_ in file names) as the default while others use the normal WMV version ?

im not really sure if that the whole reason, but i think bart de smet wrote a blog about this once.

he pointed out a caveat that when optional parameters are used, the name of the argument suddenly start to matter. if you make a seemingly innocent change to a argument name in a library, all callers that use that argument by name will break

also, bart wrote that, at least in the c# implementation, the values for optional parameters are "burned into the call site" that is, a method like this void Add(string firstName, string lastname = "") could be called like this:  Add("aL"), however what the compiler will actually emit is Add("aL", "")

this means that even if the library writer where to change the default value for a optional parameter, the callers wouldnt pick up that new vaalue unless they recompiled their code.

maybe he thinks it promotes "bad" design, that is having to many arguments.. but surely the users of such libraries *cough*office*cough* shouldnt have to suffer for that

the interactive c# shell is an excellent demostration and the Q&A session is very interesting and informative, nice video !

how to download these videos??????

Click on "Media Downloads" and it will show a dropdown list.

"this means that even if the library writer where to change the default value for a optional parameter, the callers wouldnt pick up that new vaalue unless they recompiled their code."

If that's true, then that's a really poor design decision from the compiler team. Optional parameter default values should be set in the method, not in the caller.

I think Anders presented this talk better in the "TechDays 2010 Keynote by Anders Hejlsberg: Trends and future directions in programming languages" video.

http://channel9.msdn.com/posts/adebruyn/TechDays-2010-Developer-Keynote-by-Anders-Hejlsberg/

I think this is also the case for C++ that in C++ what are termed default parameters are burned into the call site.

It's also the case for constants in C#, which I think a lot of developers don't realize - that the constant value is burned in, so changing a constant in a referenced assembly won't change the value in dependent assemblys unless they themselves are also recompiled.

I'm sure that they have good reasoning for doing the same for optional parameters in C#, even if it may have adverse affects in some scenarios.

Following the first supported product release of F# in Visual Studio 2010 on Monday 12th April, which includes a production-quality REPL like the experimental C# one Anders presented here, and hearing the questions about F# posed to Anders in this lecture, I think lots of Microsoft's customers will be wanting lectures specifically about F#.

Were there any lectures on F# at this DevDays conference?

Jon Harrop, you can have a look at Don Symes introduction to F#.

Great presentation. Meantime, thanks to Matt for all his effort.

Really its a very useful session

Overall this presentation is really good, I liked how Mr. Hejlsberg explained the current problems of modern programming and the approach C# took to accomodate those problems.

However, I wish he talked more about the debugging and specific run time errors that can occur.

The problem with dynamic, as far as I can tell, is that since you could give a dynamic variable anything you want, you won't know if it will work until you run the application at run time; but even then, you won't even know where the error will be in the code!

I can see debugging dynamic variables to be a big futuristic problem (part of the reason why many people don't like javascript), especially if you're asking the program to do what you want it to do, and it's not complying properly to your request. It would be quite difficult to track down problems if they occur. The only thing you'd be left to run on is how well you can design your code to narrow down where an error could result.

If Mr.Hejlsberg dedicated sometime to show possible runtime errors, and if there is some kind of message handling that will explain viable reasons as to why something is not working, I'd program using dynamic variables with higher confidence. But as far as now, I feel a little effy on making the leap and spending my time asking others why something isn't working.

Overall this presentation is really good, I liked how Mr. Hejlsberg explained the current problems of modern programming and the approach C# took to accomodate those problems.

However, I wish he talked more about the debugging and specific run time errors that can occur.

The problem with dynamic, as far as I can tell, is that since you could give a dynamic variable anything you want, you won't know if it will work until you run the application at run time; but even then, you won't even know where the error will be in the code!

I can see debugging dynamic variables to be a big futuristic problem (part of the reason why many people don't like javascript), especially if you're asking the program to do what you want it to do, and it's not complying properly to your request. It would be quite difficult to track down problems if they occur. The only thing you'd be left to run on is how well you can design your code to narrow down where an error could result.

If Mr.Hejlsberg dedicated sometime to show possible runtime errors, and if there is some kind of message handling that will explain viable reasons as to why something is not showing, I'd program using dynamics with higher confidence. But as far as now, I feel a little effy on making the leap and spending my time asking others why something isn't working.

the Eval thing is fantastic, but when we can use it, anders has done the demo for several times since pdc08

Now C# can do what Visual FoxPro has done for over 10 years.  

Where can one dowload the source code for demos shown in these presentations? Thanks!

Matt, thanks for putting these up; the quality is fantastic!  I can't thank you enough!

The problem with dynamic, as far as I can tell, is that since you could give a dynamic variable anything you want, you won't know if it will work until you run the application at run time; but even then, you won't even know where the error will be <a href="http://www.youtubeline.com">youtube</a> in the code! I can see debugging dynamic variables to be a big futuristic problem (part of the reason why many people don't like javascript), especially if you're asking the program to do what you want it to do, and it's not complying properly to your request. It would be quite difficult to track down problems if they occur. The only thing you'd be left to run on is how well you can design your code to narrow down where an error could result.

@Matthijs:Can you provide teaching videos Asp.net Controls, Security and State management?