C# 4.0 - Questions and reasons behind the answers

Description

The topic of "C# 4.0" is an area we've been diving into a bit lately. So we took this opportunity to sit down with Niner-regular Anders Hejlsberg and C# Community PM Charlie Calvert to dive into some of the most common questions we are hearing about C#
4.0 and the reasoning behind some of the answers.

The Discussion

I think I've watched that bit of Anders presentation at PDC 2008 where he cons's up a eval loop using C# '5' more than half a dozen times now. Reminds me of the F# demo Don did a while back where he created and hooked up a WinForm on the fly. Having this
in C# will be utterly cool and I really hope Anders et al can make good on their hopes of getting the 'eval' stuff out to us some time before Visual Studio 2012! Huge kudos to the whole C# team, your compiler continues to be a big contributing factor to my
on-going love affair with programming!

As usual, Anders presents us with all the goodies, packaged up in time for Christmas. A paedagogical talent as well.

The explanation of dynamic is very good and should lay to rest the unfounded criticism of the feature. Of course anytime you introduce another hammer there's a chance someone else use it to knock themselves out, but it sure is a nice thing to have. The
examples of DOM and REST are very good and I'm very intrigued to explore them closer. Some things are indeed inherently dynamic and "unsafe", you just have to box them in, and that is exactly what the dynamic type does.

Also looking very much forward to the next VS with MEF and "AST coloring" (okay, bad term).

I wanted to ask Anders: any chance to get covariant return types for overridden methods in the near future? I know the co- and contra- variance features will be added only for generics, delegates and interface types so I was wondering...

I completely agree with the question on covariant return types. When I met Anders at the PDC bookstore I really tried to get the message across and I've been pushing the request for a long time (as have numerous other people in the community).

Love Anders and would not presume to know anything compared to him, but did he really say XElement is a good alternative for VBs XML support? I think I would rather chew glass. Sure you can make it easier with an extention method like:

But that lacks two major things, compiler support and designer support. Naturally, it becomes a slippery slope of what meta languages to support as the next question becomes support for JSON and M. I think M makes this more interesting as I think we will
need compiler support for that. So should M, JSON, and XML have compiler support in c#? Why or why not? Could these be opt-in/opt-out extentions to the language?

Will Visual C++ status quote be enough to overcome the appeal of the D programming language in 2010?or is C# going to be unleashed?

Why doesn't Visual Studio provide for two forms of compilation. For example the exiting just in time and full compilation of the MSIL to machine code. I really see that C++ at this stage only serves for the purpose of maintaining legacy code. The incarnation
of C++ was a hack and will continue to grow as a hack. .Net languages (in particular C#) for one should take full charge of future development in both desktop, web and yes system development. D programming language is already making an impression on a small
but growing C++ community. D programming languages has syntactic appeal of C# and the horse power of C/C++. So what is the constraint, religion or technical feasibility. DotNet languages will be competing against the up an coming D programming languages
sooner or later for development of system software and embedded systems. Again I say C++ is dead weight and should only be relevant for legacy code (in other words C++ will soon be Cobol). C# (all .net lingos) can easily take the manto if Visual Studio provided
for this option and full support for "producing" applications that are true platform independent.

Thanks for this discussion. As we train ourselves to think in terms of Abstraction when programming we many time find ourselves purposely genericizing the type. Passing objects in and out of methods becomes attractive with repsect to Abstraction. The problem of course is in the reconstruction of the Object into statically typed objects just for the sake of calling a method. As you mentioned using the Reflection class does indeed become messy (and actually predates things such as the HTML DOM (for example MethodInfo and FieldInfo) are not terms used within the HTMLDOM, so we have to convert mentally when trying to work with HTML DOM that a Reflection.MethodInfo = DOM.FiledAttirbute (or something similar). It requires speding too much time in the debugger's immediate window trying to ferret this stuff out. With Dynamic it looks like we will immensly ease this problem. Thanks again.