The C# Programming Language Version 4.0

By Doug Holland (Intel) (235 posts) on March 30, 2009 at 10:02 am

Visual Studio 2010 and the .NET Framework 4.0 will soon be in beta and there are some excellent new features that we can all get excited about with this new release. Along with Visual Studio 2010 and the .NET Framework 4.0 we will see version 4.0 of the C# programming language. In this blog post I thought I'd look back over where we have been with the C# programming language and look to where Anders Hejlsberg and the C# team are taking us next.

In 1998 the C# project began with the goal of creating a simple, modern, object-oriented, and type-safe programming language for what has since become known as the .NET platform. Microsoft launched the .NET platform and the C# programming language in the summer of 2000 and since then C# has become one of the most popular programming languages in use today.

With version 2.0 the language evolved to provide support for generics, anonymous methods, iterators, partial types, and nullable types.

When designing version 3.0 of the language the emphasis was to enable LINQ (Language Integrated Query) which required the addiiton of:

If you're in need of learning about, or distilling knowledge of, any of these language features that I have mentioned so far I would highly recommend that you take a look at the C# Programming Language by Anders Hejlsberg, Mads Torgersen, Scott Wiltamuth, and Peter Golde.

What is excellent about this edition is that it contains annotations from many other Microsoft employees and Visual C# MVP's giving you additional perspectives on the language and its capabilities. Another excellent book is Essential LINQ by Charlie Calvert and Dinesh Kulkarni.

   

In the past programming languages were designed with a particular paradigm in mind and as such we have languages that were, as an example, designed to be either object-oriented or functional. Today however, languages are being designed with several paradigms in mind. In version 3.0 the C# programming language acquired several capabilities normally associated with functional programming to enable Language Integrated Query (LINQ).

In version 4.0 the C# programming language continues to evolve, although this time the C# team were inspired by dynamic languages such as Perl, Python, and Ruby. The reality is that there are advantages and disadvantages to both dynamically and statically typed languages.

Another paradigm that is driving language design and innovation is concurrency and that is a paradigm that has certainly influenced the development of Visual Studio 2010 and the .NET Framework 4.0. See the MSDN Parallel Computing development center for more information about those changes. I'll also be blogging more about Visual Studio 2010 and the .NET Framework 4.0 in the next few weeks.

Essentially the C# 4.0 language innovations include:

Enough talking already let's look at some code written in C# 4.0 using these language innovations...

In C# today you might have code such as the following that gets an instance of a statically typed .NET class and then calls the Add method on that class to get the sum of two integers:

Calculator calc = GetCalculator();
int sum = calc.Add(10, 20); 

Our code gets all the more interesting if the Calculator class is not statically typed but rather is written in COM, Ruby, Python, or even JavaScript. Even if we knew that the Calculator class is a .NET object but we don't know specifically which type it is then we would have to use reflection to discover attributes about the type at runtime and then dynamically invoke the Add method.

object calc = GetCalculator();
Type type = calc.GetType();
object result = type.InvokeMember("Add",
                                  BindingFlags.InvokeMethod, null,
                                  new object[] { 10, 20 });
int sum = Convert.ToInt32(result);

If the Calculator class was written in JavaScript then our code would look somewhat like the following.

ScriptObect calc = GetCalculator();
object result = calc.InvokeMember("Add", 10, 20);
int sum = Convert.ToInt32(result);

With the C# 4.0 we would simply write the following code:

dynamic calc = GetCalculator();
int result = calc.Add(10, 20);

In the above example we are declaring a variable, calc, whose static type is dynamic. Yes, you read that correctly, we've statically typed our object to be dynamic. We'll then be using dynamic method invocation to call the Add method and then dynamic conversion to convert the result of the dynamic invocation to a statically typed integer.

You're still encouraged to use static typing wherever possible because of the benefits that statically typed languages afford us. Using C# 4.0 however, it should be less painful on those occassions when you have to interact with dynamically typed objects.

Another major benefit of using C# 4.0 is that the language now supports optional and named parameters and so we'll now take a look at how this feature will change the way you design and write your code.

One design pattern you'll often see as that a particular method is overloaded because the method needs to be called with a variable number of parameters.

Let's assume that we have the following OpenTextFile method along with three overloads of the method with different signatures. Overloads of the primary method then call the primary method passing default values in place of those parameters for which a value was not specified within the call to the overloaded method.

public StreamReader OpenTextFile(
         string path,
         Encoding encoding,
         bool detectEncoding,
         int bufferSize) { }

public StreamReader OpenTextFile(
         string path,
         Encoding encoding,
         bool detectEncoding) { }

public StreamReader OpenTextFile(
         string path,
         Encoding encoding) { }

public StreamReader OpenTextFile(string path) { }

In C# 4.0 the primary method can be refactored to use optional parameters as the following example shows:

public StreamReader OpenTextFile(
         string path,
         Encoding encoding = null,
         bool detectEncoding = false,
         int bufferSize = 1024) { }

Given this declaration it is now possible to call the OpenTextFile method omitting one or more of the optional parameters.

OpenTextFile("foo.txt", Encoding.UTF8);

It is also possible to use the C# 4.0 support for named parameters and as such the OpenTextFile method can be called omitting one or more of the optional parameters while also specifying another parameter by name.

OpenTextFile("foo.txt", Encoding.UTF8, bufferSize: 4098);

Named arguments must be provided last although when provided they can be provided in any order.

If you have ever written any code that performs some degree of COM interoperability you have probably seen code such as the following.

object filename = "test.docx";
object missing = System.Reflection.Missing.Value;
doc.SaveAs(ref filename,
           ref missing, ref missing, ref missing,
           ref missing, ref missing, ref missing,
           ref missing, ref missing, ref missing,
           ref missing, ref missing, ref missing,
           ref missing, ref missing, ref missing);

With optional and named parameters the C# 4.0 language provides significant improvements in COM interoperability and so the above code can now be refactored such that the call is merely:

doc.SaveAs("foo.txt");

When performing COM interoperability you'll notice that you are able to omit the ref modifer although the use of the ref modifier is still required when not performing COM interoperability.

With previous versions of the technologies it was necessary to also ship a Primary Interop Assembly (PIA) along with your managed application. This is not necessary when using C# 4.0 because the compiler will instead inject the interop types directly into the assemblies of your managed application and will only inject those types you're using and not all of the types found within the PIA.

The final language improvement that we will explore is co-variance and contra-variance and we'll begin by exploring co-variance with .NET arrays.

string[] names = new string[] {
                     "Anders Hejlsberg",
                     "Mads Torgersen",
                     "Scott Wiltamuth",
                     "Peter Golde" };

Write(names);

Since version 1.0 an array in the .NET Framework has been co-variant meaning that an array of strings, for example, can be passed to a method that expects an array of objects. As such the above array can be passed to the following Write method which expects an array of objects.

private void Write(object[] objects)
{
}

Unfortunately arrays in .NET are not safely co-variant as we can see in the following code. Assuming that the objects variable is an array of strings the following will succeed.

objects[0] = "Hello World";

Although if an attempt is made to assign an integer to the array of strings an ArrayTypeMismatchException is thrown.

objects[0] = 1024;

In both C# 2.0 and C# 3.0 generics are invariant and so a compiler error would result from the following code:

List<string> names = new List<string>();

Write(names);

Where the Write method is defined as:

public void Write(IEnumerable<object> objects) { }

Generics with C# 4.0 now support safe co-variance and contra-variance through the use of the in and out contextual keywords. Let's take a look at how this changes the definition of the IEnumerable<T> and IEnumerator<T> interfaces.

public interface IEnumerable<out T>
{
    IEnumerator<T> GetEnumerator();
}

public interface IEnumerator<out T>
{
    T Current { get; }
    bool MoveNext();
}

You'll notice that the type parameter T of the IEnumerable interface has been prefixed with the out contextual keyword. Given that the IEnumerable interface is read only, there is no ability specified within the interface to insert new elements with the list, it is safe to treat something more derived as something less derived. With the out contextual keyword we are contractually affirming that IEnumerable<out T> is safely co-variant. Given that IEnumerable<out T> is safely co-variant we can now write the following code:

IEnumerable<string> names = GetTeamNames();
IEnumerable<object> objects = names;

Because the IEnumerable<out T> interface uses the out contextual keyword the compiler can reason that the above assignment is safe.

Using the in contextual keyword we can achieve safe contra-variance, that is treating something less derived as something more derived.

public interface IComparer<in T>
{
    int Compare(T x, T y);
}

Given that IComparer<in T> is safely contra-variant we can now write the following code:

IComparer<object> objectComparer = GetComparer();
IComparer<string> stringComparer = objectComparer;

Although the current CTP build of Visual Studio 2010 and the .NET Framework 4.0 has limited support for the variance improvements in C# 4.0 the forthcoming beta will allow you to use the new in and out contextual keywords in types such as IComparer<in T>. The .NET Framework team is updating the types within the framework to be safely co- and contra-variant.

I've listed here some resources you might find useful in exploring the capabilities of the C# 4.0 programming language and would encourage you to also download and install the beta once it is available in the coming months.

Categories: Parallel Programming, Software Engineering

Comments (145)

March 31, 2009 4:15 AM PDT


Zxjay		 Greate!!
March 31, 2009 4:47 AM PDT


efactor		 Awesome first look at C# v. 4.0
March 31, 2009 8:52 AM PDT


Cookie haid		 It's great, too.
March 31, 2009 9:55 AM PDT

Doug Holland (Intel)
Total Points:
12,755
Status Points:
12,755
Black Belt
 Hey Zxjay, efactor, and Cookie,

Thanks for the comments and be sure to check out the beta in the next few months when it ships.

Regards,

Doug
March 31, 2009 10:55 AM PDT


Clifford Nelson		 C# has been moving in the right direction. The optional parameters are great since can make program easier to read. Still looking for a more flexible switch statement like in VB.
March 31, 2009 11:38 AM PDT


Logan		 NICE!
March 31, 2009 12:12 PM PDT

Doug Holland (Intel)
Total Points:
12,755
Status Points:
12,755
Black Belt
 Hey Clifford,

C# and VB, according to Anders, are now on a co-evolutionary path and so many language features that are added to one will also find there way to the other. Given the two languages have a distinct audience however, there will continue to be features of one language that will not be added to the other. An example of such a feature is the Xml literal strings in VB which the C# team has no intention to add to C#.

Regards,

Doug
March 31, 2009 12:15 PM PDT

Doug Holland (Intel)
Total Points:
12,755
Status Points:
12,755
Black Belt
 Thanks Logan!!!
March 31, 2009 6:15 PM PDT


Lance		 About time, when will the beta release be available
March 31, 2009 9:11 PM PDT


RK		 What would happen in you had the following method signature with optional parameters...

public StreamReader OpenTextFile(
string path,
Encoding encoding = null,
bool detectEncoding = false,
bool ignoreErrors = false,
int bufferSize = 1024) { }

And you only wanted to specify one of the bool parameters, like this: OpentTextFile("foo.txt", Encoding.UTF8, true);

Would this be a compiler error? Or would the first bool parameter in the signature, detectEncoding, be given the value 'true'?
March 31, 2009 10:16 PM PDT

Doug Holland (Intel)
Total Points:
12,755
Status Points:
12,755
Black Belt
 Hey Lance,

Microsoft hasn't publically commented upon when the beta will be available although if you look at the following two facts we can guess it should be within the next few months:

1. Microsoft hasn't released a CTP build in almost six months and the teams must have been really busy in that time.

2. If the RTM build is to be available within 2009 they would have to deliver beta one during Q2 2009 followed by the RC build in Q3 and an RTM in Q4.

Given those two facts we should see a beta in Q2 and Q2 begins tomorrow so keep your eyes on MSDN and the blogosphere.

Regards,

Doug
March 31, 2009 10:20 PM PDT

Doug Holland (Intel)
Total Points:
12,755
Status Points:
12,755
Black Belt
 Hey RK,

Good question and the answer is simple, especially when I can paste your code into the VS2010 CTP :)

Essentially the path = "foo.txt" and the encoding = Encoding.UTF8, no surprises there.

The Boolean 'true' you passed in next is assigned to detectEncoding which would otherwise be false.

Regards,

Doug
April 1, 2009 1:38 AM PDT


rakesh		 Nice work on c# 4.0
April 1, 2009 1:56 AM PDT


Fatma		 You came at the right time
thanks
April 1, 2009 7:03 AM PDT


daniel		 @RK, said:
"And you only wanted to specify one of the bool parameters, like this: OpentTextFile("foo.txt", Encoding.UTF8, true);

Would this be a compiler error? Or would the first bool parameter in the signature, detectEncoding, be given the value 'true'?"

i'm convinced it will be handled like in c++. your example will set detectEncoding to TRUE, OpentTextFile("foo.txt", Encoding.UTF8, , true); will set the ignoreErrors to true and leave detectEncoding at default.
April 1, 2009 7:53 AM PDT


Andres-CO		 Hi ,
In the question of RK when the method is invoked as OpentTextFile("foo.txt", Encoding.UTF8, true) the detectEncoding will be set to true because optional parameters must be in order it means that if you call the method like OpentTextFile("foo.txt", Encoding.UTF8, 1024) a compiler error is generated. It does not mean that parameters must be strictly in order because you can explicitly set the order using the parametername = parametervalue e.g. OpentTextFile(bufferSize = 1024 , Encoding encoding = Encoding.UTF8, path = "foo.txt")

Regards,
April 1, 2009 8:05 AM PDT


Andres-CO		 Also you can do this OpentTextFile("foo.txt", Encoding.UTF8, ignoreErrors : true)

........
@
The right way is ParameterName : ParameterValue use ":" instead of "="
April 1, 2009 8:06 AM PDT


shervin		 it's greate . i hop that when i test the beta version the LINQ is improved . there are many mistake in LINQ 1.0 that i discussed about them.
April 1, 2009 2:42 PM PDT


Berliotz		 Hi, we can write now this:

var result = SomeIEnumerable.Where(a=>foo(a) == 0).FirstOrDefault();

So I can get or result of type a or default(a).

I would apreciate if there would be possible to write something like

var result = [a.b.c.d, new D()];

where any of a b c d could be null. Now I have to write if(a != null && a.b != null .....) or ugly try{...}catch{return new D()}, what's realy absolutly wrong way. With the construct above I would get or .d or new D() id any object in the way is null. How can I now write var result = someIEnumerable.Where(a=> a.b.c.d == 1).firstOrDefault?
And what about var res = [a.b[0].c[2].d, 3].ToString();
Is too creasy?
April 1, 2009 3:38 PM PDT


Sai Satish		 Nice tuturial...



Sai Satish
Indian Servers
April 1, 2009 10:05 PM PDT

Doug Holland (Intel)
Total Points:
12,755
Status Points:
12,755
Black Belt
 Hey Daniel, Andres-CO,

You're both right in the additional answers you provided to the question posted by RK, and yes named parameters use ":" instead of "=".

Regards,

Doug
April 1, 2009 10:07 PM PDT

Doug Holland (Intel)
Total Points:
12,755
Status Points:
12,755
Black Belt
 Hey Shervin,

You could elaborate about what you didn't like about the implementation of LINQ although I'd recommend you post such feedback to the Microsoft Connect website such that other users can vote on your suggestions / bugs.

http://connect.microsoft.com

Regards,

Doug
April 2, 2009 1:16 AM PDT


sealight		 Yeah,

It's great for me

sealight
April 2, 2009 1:25 AM PDT


Wang		 It's nice
April 2, 2009 9:47 PM PDT


eric		 finally optinal parameter like trandtional C++
April 2, 2009 10:46 PM PDT

Doug Holland (Intel)
Total Points:
12,755
Status Points:
12,755
Black Belt
 Hey Berliotz,

If you have suggestions for the C# programming language then I'd suggest you post a suggestion on Microsoft Connect.

http://connect.microsoft.com

Regards,

Doug
April 3, 2009 1:01 AM PDT


Qadir		 A good introduction to C# 4.0 features. Thanks Dough
April 4, 2009 5:39 AM PDT


tc master		 All these all REALLY great? Some might be and some might not. It seems to me that C# is giving more and more options to errors, and with those options, it is doomed that those errors will be there by abusing the features. And mostly it seems those features are mostly focusing on writing codes, but will definatly make reading code a mass (in most cases).
April 4, 2009 7:10 PM PDT


Ved Prakash		 great........................
April 5, 2009 6:04 PM PDT


Gregory Kornblum		 Out of all the new features I would have to say the parameter changes are the best as they will allow for leaner, easier to understand code. Of course we will still have to break the different paramter scenarios out into smaller pieces but having a single point of entry is pretty sweet compared to overloads. Imagine if we didn't have this capability when creating T-SQL procedure paramters. If you think of it like that you can definitely see the value in this.
April 6, 2009 1:15 AM PDT


Mahesh		 good introduction to C# 4.0
great
April 6, 2009 5:23 AM PDT


Ravindra Joshi		 Really cool. Thanks Doug!!!
April 6, 2009 5:44 AM PDT


Namwar Rizvi		 Excellent stuff!
April 6, 2009 10:51 PM PDT

Doug Holland (Intel)
Total Points:
12,755
Status Points:
12,755
Black Belt
 In regard to the comment by tc master, all programming languages provide features that can be abused if not used in the way that the language designers intended and the C# programming language is by no means an exception to this rule.

When using the C# programming language you should always set the compiler options such that the compiler will generate an error in place of warnings. Your code should compile without error and without warnings.

With Visual Studio you can take this to the next level by using static code analysis and source analysis to ensure the language is being applied correctly.

- Doug

April 7, 2009 12:43 AM PDT


satish Topiya		 Great Work..
Thank you Doug.
A really nice feature for developers community.

April 7, 2009 3:05 AM PDT


ranjit		 great
April 7, 2009 7:43 AM PDT


TRK		 I feel this is more useful me as a biggner to learn computing application.
April 7, 2009 7:59 AM PDT


Ram Kishore K		 Great stuff !!
Loads to learn - again ! oops !
April 7, 2009 10:31 AM PDT


Imran Nazir		 Its really a nice article. However, I wonder if these features can become the part of C# language then why not some validation stuff while passing parameters.
Like simply using the example method call:

public StreamReader OpenTextFile(
string path,
Encoding encoding = null,
bool detectEncoding = false,
int bufferSize = [1024 ... 4096[) { }

indicating the bufferSize >= 1024 && bufferSize < 4096, though it can't be possible for all datatypes.
April 7, 2009 10:48 AM PDT

Doug Holland (Intel)
Total Points:
12,755
Status Points:
12,755
Black Belt
 Hey Imran,

An interesting thought although like you say, it might not apply to all data types. In the example you suggested I would say that for now and likely with VS2010 you'd have to write the following:

public StreamReader OpenTextFile(
string path,
Encoding encoding = null,
bool detectEncoding = false,
int bufferSize = 1024)
{
if(bufferSize < 1024 || bufferSize > 4096)
{
throw new ArgumentOutOfRangeException("bufferSize", "bufferSize out of range. Acceptable range is between 1024 and 4096");
}

....
}

With this way of controlling argument ranges you'd have more control over the message sent to the calling code within the exception although I do like the approach you've taken there.

An academic project to integrate the Object Constraint Language (OCL), which is part of the Unified Modeling Language (UML) specification, can be found here:

http://www.davearnold.ca/csocl/

Unfortunately most programmers to not validate arguments within methods today although possibly syntax such as you suggest might get them to do so.

I'd encourage you to use Microsoft Connect and suggest such an extension to the language and even if it is not added to the language it will at least be considered.

Regards,

Doug
April 7, 2009 2:03 PM PDT


Igor		 Thanks for the digest version! I've got something to look forward to. I doubt that any of these features will replace support for generics as my favorite improvement in the .NET framework since 1.0.
April 7, 2009 2:12 PM PDT

Doug Holland (Intel)
Total Points:
12,755
Status Points:
12,755
Black Belt
 Hey Igor,

Generics is definately a very cool feature although what do you think of LINQ?

If I had to give up one language feature in C# then I'm not sure that I'd be able to choose although Generics and LINQ would definately be staying.

- Doug
April 8, 2009 3:20 AM PDT


Prashant		 Nice one....C# and VB are really evolving offer us gr8 productivity.
Dynamic types are really handy and helpful.
April 8, 2009 3:29 AM PDT


Amin Allah Rezaei		 I need moor information about LINQ
how can help me?
April 8, 2009 4:09 AM PDT


Frederick Brock		 default parameter values have been in C++ for years, so have multiple inheritance..I use niether, what was the push to add default parameters? I do like the fact that you will have them, but ciuorous why now? and is there an actual use case for them? In my opinion if you have a method that takes so many parameters you have to default them to some resonable value its possible you have a flaw in your design from an OO perspective, from an old style WinMain C side of life I would have loved to have default values for all those structures because it was a real pain in the back side, but with
OO being very mature and several very well, commonly used patterns to model interactions and encapsulate data etc seems like "Default" parameter values are a solution for hiding poorly designed code (just my opinion, not saying if you use them you have a poorly designed app, but personally I prefer very small, pointed methods and very clean interactions)

so having something like OpenTextFile that take so many parameters may be modeled via TextFile -> CSVTextFile -> TextFileReader etc.. where the Object itself has a distinct purpose and doesn't require so much input.

I do like to see C# adopting a more functional features that awesome and a very well written review as well! ... thanks



April 8, 2009 7:00 AM PDT


Srikrishna		 Great Work
Thank you Doug.
April 8, 2009 2:50 PM PDT


Chris		 Looks good!
However, I would like to have more control over the overloading of the shift operators (<< and >>) to be able to use them as insertion and extraction operators like C++ streams.
April 8, 2009 3:11 PM PDT


VB Developer		 Welcome, C#, to the world of optional parameters and proper COM interop, something Visual Basic developers have had for... well... basically forever. Only took eight years for C# to catch up.
April 9, 2009 6:12 AM PDT


Matteo		 Thanks!
April 10, 2009 5:43 AM PDT


Thanh Hai P Mai		 Not really great changes.

I'm sorry to say that, but what I'm expecting to see is C# has some more support to build multi-cores applications.

Although the changes for C# 4.0 are nice, but the fact is we still can LIVE without those. However, in this world of multi-cores, I don't want to wait for C# 5.0 to really get some effective ways to develop applications that used the power of multi-cores. I think C# team should focus on that area. C# will become the best language in the world if it support multi-cores applications effectively.

Just my 2 cents,
Hai
April 10, 2009 4:38 PM PDT


acole		 A bit difficult, isn't it?
April 11, 2009 12:28 AM PDT


Dinesh		 Hey Doug,

That was an awsome article!!!!!!!!!!!!!!!
April 11, 2009 5:01 PM PDT


Kitty		 Where's unmanaged C#? They seem to be patently dodging that particular innovation. I'd honestly like some update on why it seems to be an insurmountable task.
April 11, 2009 7:01 PM PDT


usman bashir		 i love the optional parameters as i have worked across c++,Delphi and Visual Basic so i always love to have this feature in it. i also like the "dynamic static typing" , as it saves a lot of code now. cool improvements.
April 11, 2009 7:26 PM PDT


Chandra Sekhar Doosari		 NICE.
April 12, 2009 2:13 AM PDT


Mubshir Raza Ali		 Cool... Exciting new features...
April 12, 2009 6:58 PM PDT


Michael Golan		 Basically, Microsoft is moving to C# and needs a decent COM operability... this is why we get dynamic (which was trivial to implement as reflection examples indicate), and optional/named paramaters. the in/out is still more lip service to functional programming.

We still have trivial issues missing, making C# "too rigid" for fast & dirty code. Or in other words - the syntax still tends to show up more as COBOL than Perl (ok, that is insulting). Why not have regular expression match at the synax level, as well as more default values/actions (a->b to indicate (a? a.b:default), more flexible switch(), a pascal "with" so we can write with(Math) a=Pow(b,Sqrt(c)), a Pow operator(**) in the langauge, etc?

Its obvious to any software/language expert what steps C# needs to take to make perl-style code look decent in C#, but alas, too many academics (been there, done that) miss the mark - it's the syntax, stupid! Programmers never really understand semantics because they are humans, thinking in associative terms, meaning they really graps syntax ... which is why a langauge dies or live based on its syntax.

Certainly, C# 5.0 will have to include heavy math operations (matrix multiplication operator allows parallel computations), so I'm afraid we're not going anywhere with this. Too bad. I thought we'd get a little more dirty with dynamic.
April 13, 2009 12:22 AM PDT


Meta		 Thanks for the digest version! I've got something to look forward to. I doubt that any of these features will replace support for generics as my favorite improvement in the .NET framework since 1.0.
April 13, 2009 4:49 AM PDT


mm		 not a good question.
April 13, 2009 8:17 AM PDT


Ayşenur		 thanks, great
April 14, 2009 2:10 AM PDT


Arash		 About the dynamic type, to me it seems that this dynamic type is a type that is treated in a special way by the compiler, in a sense that anything can be assigned to a variable of this type and also the (.) (dot) operator is not the normal one that works on other types.
The problem is that this way readers of a code would be confused about the meaning of the (.) operator; but if this functionality was provided by another operator, ! for example (I think something like this existed in VB) they would notice that they are reading some C#4, dynamic like code and thus they wouldn't be confused.
April 14, 2009 1:49 PM PDT


Ronaldo Bertelli Jr		 Interesting
April 14, 2009 11:16 PM PDT


Eric Fan		 Optional parameter has been there in C++ for a long time. But it's not supported in C#. Glad to see it back.
April 15, 2009 7:18 AM PDT


*		 **
April 15, 2009 7:40 AM PDT


alen		 its realy col man its goin in the rite path being a fresher to the industry c# 4.0 is gona help me a lot!!
do help me with the new postings
April 15, 2009 5:54 PM PDT

Doug Holland (Intel)
Total Points:
12,755
Status Points:
12,755
Black Belt
 Hey Amin Allah Rezaei,

I'd really recommend Essential LINQ by Charlie Calvert and Dinesh Kulkarni if you need to learn LINQ. Another great book on LINQ is Programming LINQ by Paolo Pialorsi and Marco Russo.

Ideally I'd suggest buying both books although if forced to choose just one then I'd say Essential LINQ would be my choice because it is more recent.

Regards,

Doug
April 15, 2009 6:10 PM PDT

Doug Holland (Intel)
Total Points:
12,755
Status Points:
12,755
Black Belt
 Hey Thanh Hai P Mai,

Although you don't see changes in the C# 4.0 programming language for writing multi-core applications you do see support within both the .NET Framework 4.0 and Visual Studio 2010 for multi-core programming.

As Anders Hejlsberg and others have joked, you're not going to see a /parallel switch for the C# compiler that suddently makes all of your code execute concurrently.

Language innovation for multi-core can be found with languages such as Maestro, and the lessons learned by Microsoft and the wider industry with languages for multi-core will undountedly be a topic of debate for the C# team.

http://channel9.msdn.com/shows/Going+Deep/Maestro-A-Managed-.....ogramming/

While we can introduce frameworks for multi-core and evolve those frameworks overtime, using the [Obsolete] attribute on types as those frameworks evolve, it is much harder to evolve languages in the same way. Once a language feature is out there in the wild is is much harder to [Obsolete] it than it is with framework features.

Before the C# team evolve the C# language for multi-core we have to ensure that we truly know what changes are appropriate at the language level. Until then look at PLINQ and the Task Parallel Library types and the advances for multi-core programming in the Visual Studio 2010 environment.
April 15, 2009 6:14 PM PDT

Doug Holland (Intel)
Total Points:
12,755
Status Points:
12,755
Black Belt
 Hey Kitty,

I believe that if you're targeting unmanaged code then C++ is going to be your answer as the C# programming language was designed from the beginning with the Common Language Runtime (CLR) in mind.

I don't imagine you'll see a version of the C# language for unmanaged code anytime soon as there are so many benefits to writing code that targets a managed runtime.

If you need more direct access to the metal then assembly programming and unmanaged languages such as C and C++ are really your answer.

Regards,

Doug
April 16, 2009 12:21 PM PDT


Sean		 In regards to the question regarding multi-core. The task parallel library will be part of the .NET Framework 4.0. For more information visit http://blogs.msdn.com/pfxteam/
April 16, 2009 1:14 PM PDT

Doug Holland (Intel)
Total Points:
12,755
Status Points:
12,755
Black Belt
 Hey Sean,

Exactly, ... the Task Parallel Library is part of .NET 4.0 and if you need a good introduction to it then I'd recommend checking out the TPL session from last years PDC which was presented by Daniel Moth.

Regards,

Doug
April 16, 2009 3:48 PM PDT


taimoor		 Fine tool for the development but still need to update its features
April 17, 2009 7:57 AM PDT

Doug Holland (Intel)
Total Points:
12,755
Status Points:
12,755
Black Belt
 Hey Taimoor,

If you think features are missing then I would really recommend you submit feedback via connect.microsoft.com.

- Doug
April 18, 2009 4:03 AM PDT


ali		 code for transfair from from form to form
April 18, 2009 4:54 PM PDT


Thanh Hai P Mai		 Hello Doug Holland,

Thank you for your reply. I understand why Microsoft prefer the framework way to the language way now.

I have a few cents left still. As we know, C# (and .net) involved very fast. It has more and more features, and it's hard for new people to progress to the expert level of it.

We can see a young man starts his first steps in programming, learn the basic functions, learn the usage of IDE, learn how to make classes. Next we will see him study about delegate, research about reflection, dive into attributes. Later he will need to know about LINQ, makes use of dynamic and a lot more stuffs. This prolongs the learning process of C# (and .net).

C# started as a very easy to learn language to become a harder to understand language.

When a newbie looks at C#1.1 code, he can easily guess what the code is going to do using his English. And he can start to code the same way with little research to do. It really helps with self-studying process.

But now, when a newbie looks at basic anonymous code or dynamic type, they still can understand it, BUT hardly can start to code the same way without doing intensive research via google or need to read C# documents. And most newbies cannot understand why they can declare a variable in many different ways and which is the best way to do that.

Back to our human, we are involving every hour, every minute. We invent new things, we know how to do the work in better way, and we also know how to forget things.

This is not a problem yet. But later, when C# involves to its later major versions, being more complicated, I think we need to be selective when we decide which features we will include. It will not be so benefit for majority of users if a feature requires 1-2 months more to expert if the problems can be solve in the old ways with just a little more work.

My questions is, do Microsoft have any plan to reduce some of the old features of C# (and .net) when the work now can be done in a better way (using new features) ?

I know this is a debate and people will have disagreement, tell me your oppinions then ^_^.

Best regards,
Hai
April 19, 2009 11:26 AM PDT


Amir		 These are all fantastic features, though I'm still strugliing with C# 3.0.

Good job guys!
April 20, 2009 2:23 PM PDT


David Cole		 Doug,

Thank you for posting the update on C# 4.0. I'm looking forward to Beta testing as soon as it's available. I was feeling pretty negative about optional parameters in C#... now I would say my feelings are more in the neutral range which I would classify as an improvement. I definitely view the improved Interoperability syntax as a big plus!

I'll be interested to see first hand how well dynamic types are handled. While this might be a strength for a language such as JavaScript, it can also be a tremendous weakness if not wielded properly (true of any powerful programming language feature I suppose).

Very psyched about the addition of Covariance and Contravariance for generic types. This is something I've wished to have many times in the past, and not having it has forced me to be very... creative in finding solutions at times. Definitely looking forward to this new feature.

To Thanh: Part of the beauty of C# and the .Net Framework is that a programmer doesn't need to know how to do -everything- in order to be successful. I understand the desire to keep C# simple. It's always been a language with an easy entry-level learning curve but with many advanced features that take longer to learn. This doesn't seem to be changing. These new features are available to those who have a stronger grasp of the language and wish to use them. From what I can see, those who wish to continue developing with 2.0 or 3.5 style code will still be able to do so. (Correct me if I am wrong, Doug). Some of these features, such as optional parameters, might even be shortening the learning curve a little.
April 20, 2009 10:31 PM PDT

pramodblackbird
Total Points:
470
Status Points:
420
Green Belt
 .Net & C # 4.0 indeed is too cool,..i mean, workflow n all other stuff,..eager to work on it,...
April 21, 2009 4:18 AM PDT


Arman		 Thanh,

I would have to say that Microsoft should select only those features for C# who not only add some new features but also provide easy to understand and use programming technique. And I think this is what they actually do, our mission is to help them in that work.
Mmm... or maybe they would like to run two different versions of C#, one for newbies and another for others :). Say, C# 4.0 Pro and C# 4.0 Baby ;)... and why not, 'C# 4.0 Bro' for dudes ))

Thanks,
Arman.
April 21, 2009 11:36 AM PDT

a-dacole
Total Points:
5
Registered User
 There is already a C# Baby edition... it's called VB.Net ;-)

Ok ok I was just kidding! Let's not start language wars. I just couldn't resist the wide open opportunity for a jab.

April 21, 2009 5:56 PM PDT


IGA		 Been looking at other languages for kicks and education of late. One of the strengths of a static language is just that. Why try to make it Quack when a it obviously doesn't want too. All the so called inventive changes are great, but nothing new. Seems to me that its all just a Marketing exercise in looking at the strengths of other languages and shining bright lights into the happy punters eyes and say....."its allllll new! really. It is!, we are the best". I love c# for what it is, Delphi done with curly brackets. I don't want it to be the all singing all dancing superstar, I want it to be my bread winner, the Black Ford, the thing that the managers at companies go, yup Microsoft, thats safe. Keep it cool guys, keep it static. If I want Dynamic shucks I go Python every time. If I want declarative I go Haskell. If I want Iron pants I go C. If I want Managers special, C# every time. I loved the LINQ stuff, really made me appreciate the hard work that went into C# 2.0 under the hood. But Dynamic is just a step too far. Stick to what the compiler was designed for, else the code will go bang and managers will go back to the bad old days of C++.
April 21, 2009 6:28 PM PDT


IGA		 Oh, whats happening with F#. Now that was innovative!

Before MS goes on with anything else, the Multi-core chip is still there, not processing what we want. Quad cores and only one being used is just shoddy. I thought Parallel LINQ was making a guest appearance in 4.0?

Also the Dynamic stuff isn't really Dynamic at all, no sign of tail recursion at all, and you still got to declare two statements to do the classic fibonnacci function. But that would require a real overhaul of the framework, not the powder and paint stuff thats presented here.

Has the Budgets gone down at MS now Bill has left home and saving the world?


Prob my fav feature of c# was the whole Event System, and delegates and very cool Threading.

Might have to Jump ship this time, I hear the sea calling me, and damn it python is luring me fantasy island.
April 21, 2009 11:31 PM PDT

Doug Holland (Intel)
Total Points:
12,755
Status Points:
12,755
Black Belt
 Hey Thanh Hai P Mai,

Microsoft .NET has evolved quite considerably since version 1.0 was released in 2002 and here we are seven years later with version 4.0 about to go into beta testing.

While I'll agree with you that there are aspects of both the C# programming language and the .NET Framework that might be a little more difficult to learn than some other aspects I do not believe any aspect cannot be mastered by the average developer given the time and effort.

In my experience the majority of developers moved quite easily from C# 1.0 and 1.1 to version 2.0, realizing quite quickly the benefits of Generics over writing custom collections. Generics enabled us to leave behind much of the boxing and unboxing performance penalties caused by the fact that the ArrayList as well as many other collections used an object array to store elements.

The move however from C# 2.0 to 3.0 was a little more challenging for some developers who had little to no experience with functional programming constructs. If you're still challenged by some of the features added to C# in version 3.0 then I'd highly recommend the two books listed in this post.

Beyond the language there is certainly a wealth of capabilities within the .NET Framework and so much so that developers are left wondering where to direct their energy.

Since the RTM of the .NET Framework 2.0 you could spend time learning: WCF, WF, CardSpace, LINQ, PLINQ, ASP.NET AJAX, ASP.NET MVC, or the TPL.

It is here within the .NET Framework that I find myself in agreement to a degree as there really are so many new technologies that have entered the framework since version 2.0.

I have personally spend more time learning WCF and WF, for example, than WPF simply because of the kind of code I have been writing since the release of .NET 3.0. If you're more of a user interface developer then you're likely to have spent your time learning WPF.

If you accept that you'll no longer be able to be a guru with every aspect of the .NET Framework then you'll likely find peace.

- Doug
April 21, 2009 11:42 PM PDT

Doug Holland (Intel)
Total Points:
12,755
Status Points:
12,755
Black Belt
 Hey David,

I completely agree that language features must be wielded properly, and are subject to potential abuse, that's why I believe we should take the time to learn how to use these features effectively.

Developers should learn when a given feature is appropriate and when it isn't although fortunately there are static code analysis and source analysis tools to help us in this area.

In response to your comments to Thanh, you're right with regard to the fact that there is nothing to stop you writing code with VS2010 in the C# 3.0 style. VS2010, like VS2008, also allows you to target earlier versions of the framework and so there are separate questions to be answered for when to adopt the framework and the tools. I'd imagine however that most teams will adopt the .NET Framework 4.0 as soon as they move to Visual Studio 2010.

Regards,

- Doug

April 21, 2009 11:45 PM PDT

Doug Holland (Intel)
Total Points:
12,755
Status Points:
12,755
Black Belt
 Hey 'a-dacole'

While I personally prefer the C# programming language to VB, and got a chuckle from your comment, the two languages really are on a co-evolution now. :)

- Doug
April 21, 2009 11:52 PM PDT

Doug Holland (Intel)
Total Points:
12,755
Status Points:
12,755
Black Belt
 Hey IGA,

I believe one of the real benefits to adding language concepts from other paradigms such as functional and dynamic programming is that most developers do not have time or energy to learn several different programming languages.

F# is a very cool language although the reality is, in my humble opinion, that few C# developers will take the time to learn the language beyond writing a few very simple sample programs. I hope to be proven wrong in that assumption but we'll see.

- Doug

April 22, 2009 8:58 AM PDT


IGA		 Hey Doug,

Thanks for your reply.

I beg to differ, on the fact that adding language concepts. If you go the static route, then doing dynamic is not a choice to be retro fitted.

MS is going the functional route, as far as I can see it solves many of the multi-core problems. I saw the many presentations on Haskell and Python that MS did on comparing the languages.

Trouble is that the vibe that this comes off, is that C# is not cutting edge. Dynamic is seen as the bad boy, the upstart, the one that the science profs said, its bad, but boy, look what it can do! Haskell is so academic that it may as well wear leather elbow patches. I got lost on the whole monads thing, else I would be doing Haskell.

Do you think that C# can harness some of the stuff that Haskell can do, without affecting the core of the Framework? (a whole lot of stack space to sort out, unless we go 64 bit)

As said before without tail recursion and gutting out the inards of the Framework, going to be very difficult to get over that stack overflow problem.

Saying that, I like C# or what it is in the .net 2.0 format. A strongly typed, static , Object oriented state based programming system. I think Linq gave a lot of false hope to what basically was there in 2.0 with Anonymous methods and the very cool Array.Foreach etc.

The Lisp thing was done back in the 70's with the dynamic stuff, however as many know there is a reason why Lisp didn't take off. You could do everything with the language, even stuff that was slightly mad and weird that broke code, including changing symbols (+ to a - etc)

As for Dynamic in C#, looks an awful lot like pointers in C++, but on the virtual machine instead of the physical memory. Don't like that, scares the "£$"£ out of me. Introduces all the same seat of your pants problems without the kind Compiler helping out.

To be a good dynamic programmer requires years of experience that I feel that the Managers in many companies can't afford to give their turn stile staff retention of under 2 years. I think the fight about Dynamic V static is not a technical one these days, but an economical one. Managers want High turn over staffing with low wages, but solid Code that just works. C# provides this as is. If you take the average programmer doing something super duper, watch this type programming, that Dynamics is going to give, then they are going to fall. How many lost hours are going to be introduced in finding that super cool function bug that accidentally calls a null object that existed for a moment but then transmogrified into a new Object type.

Can't we do enough just using the Object system, and inheritance, or is OO going stale as a marketing tool?

Iestyn
April 23, 2009 3:09 AM PDT


Arman		 I don't see any bad thing if you can easily access COM objects from C#. It's easy, useful and flexible, so what else do we need, guys?
And I agree with opinion that at the moment C# provides us with ample opportunities to work with all the .NET Framework layers such as WPF, WCF, ASP.NET, LINQ, etc.. so it's time when our knowledge concentrates around a given technology, without covering all the parts of .NET Frm.
And of course, i think, the other side is that Microsoft will always do everything to involve as many developers from other platforms as they can adding and adding new features. It's not bad if it's done accurately.

All the rest is our train of thought, in my opinion.

Regards,
Arman.
April 23, 2009 8:40 AM PDT


Yuriy		 I would be very glad if in next C# 4.0 we can use the declaration of the generic type's constructor more complex and usefull by adding parameters types into constructor definition.

Currently supported just public parameterless constructor like:
class EmployeeList<T> where T : Employee, IEmployee, System.IComparable<T>, new()
{
// ...
}

I propose to extend decalration of the possible constructors like made for interfaces. We can use any interface to specify our generic type, but should use only one parameterless constructor.

I propose to extend syntax in something like that manner:

class EmployeeList<T> where T : Employee, IEmployee, System.IComparable<T>, new(),new(string name)
{
// ...
}
April 23, 2009 9:43 AM PDT


Richpal		 nice introduction to c# 4.0 Thanks
April 25, 2009 6:12 AM PDT


mastermemorex		 Some of these improvements are “looking cool”. But it do seems to add significant improvements to the language, allowing to do nothing that it can not be already be done; not even dynamic types. Nevertheless there is a list of largely demanding issues from professional programmers that you guys are simply ignoring for years. So let’s continue pinning any “cool” feature of every language leading to an inconsistent language for hobbies but complete useless for professional applications.
April 25, 2009 6:20 AM PDT


mastermemorex		 Ok Doug, that looks like pretty cool. Will improve the performance of my applications to run safer and faster?
April 26, 2009 7:06 AM PDT


POURYA		 hi kides
c# 4 best
April 29, 2009 3:36 PM PDT


JeoWilson		 Frameworks are only win32 api wrappers that are made up of Defined Types such as namespaces, enums, structs, methods and classes. Anyone with knowledge of message arcitecture and interop services can easily build frameworks as reusable dll's that incorporate all the missing elements like DWMAPI and VFW; as for driver/hardware interaction most hardware vendors supply documentation on the workings of the api's which can also be imported with interop services into a class library for use in managed applications. so stop waiting on the updates and make them yourselves. submit them, go GNU style and opensource it if your worried its not good enough, then many people can make mods and repost them to you and then you can incorporate it into your version.
I say to you all, stop waiting on the updates and read up on C++ win32 implimentation which can be found at MSDN Library and learn to use the header files to to buld complete Class Libraries for the API's we dont have, I have completed the entire DWMAPI and will submit it soon, (still need to add some exception handlers and delegates) i wanna make it as user friendly as posible.
managed code is the way to go, rather than constantly revalidating everthing echtime something is accessed just doing it at runtime in the JIT compiler makes it worth all the while, as for programming in C# or any managed language for that matter you dont really even need the framework just the normal api's - But please dont reinvent the wheel if there is allready a framework for something that dosent suit your need just stack it

ex:
public class MyTcpClient : TcpClient
{
public MyTcpClient(string hostname, int port)
: base(hostname, port)
{

}
// your extra Methods, Classes , Enums, and Structs here!
}

ex: message architecture
namespace UnsafeNativeMethods
{
[System.Runtime.InteropServices.DllImport("DwmApi.dll")]
public static extern int DwmIsCompositionEnabled
(
ref bool fEnabled
);
}

ex: usage
bool IsCompositionEnabled()
{
bool fEnabled = false;
try
{
int hResult = -1;
if ((hResult = UnsafeNativeMethods.DwmIsCompositionEnabled(ref fEnabled)) != 1)
{
throw new Exception("Error Checking Status of Composition");
}
return fEnabled;
}
catch (Exception)
{
return fEnabled;
}
}

Have fun!!!!!!
April 29, 2009 3:51 PM PDT


JeoWilson		 sorry typed the wrong thing in code
here's the right example

ex: message architecture
class UnsafeNativeMethods
{
[System.Runtime.InteropServices.DllImport("DwmApi.dll")]
public static extern int DwmIsCompositionEnabled
(
ref bool fEnabled
);
}
April 30, 2009 4:48 AM PDT


Paul Bartlett		 C# is already a nice language, BUT default parameters and static/dynamic typing have been around for years. Delphi had it 15 years ago and VB3 probably the same. COM interop changes are a bit late! Why not just have a look at all the languages and see what is missing and then add them properly. Me for one needs the WITH statement and also why not add proper SETS like in Delphi/Pascal. I love "IF optDisplay in Options". I'm not sure but can C# actually do what the introduced in Delphi a few years back. The ability to update a class lower in the hierarchy. Introduce and change methods of something you inherit, but not just your predecessor ... maybe even the base object. I know OO purists will freak, but are they the guys using these features and producing real code that has to run faultless for years?
May 2, 2009 12:01 PM PDT


Artem		 excellent..its mostly was waited by me
May 4, 2009 2:00 AM PDT


Thanh Hai P Mai		 Thanks Doug and others for comments, I really appreciate it :).

@Doug: thank you for your books suggestion, but I'm not having struggles with C# (yet) :P. Instead, I am a team leader of a nice company. The problems are that my developers have some difficulties to catch up with C#, and most of them use C# 2.0 styles except when they need to do database with LINQ. And none of them say they want to use the new Dynamic so far.. :(. I also agree with them about "Dynamic will introduce many harder-to-trace bugs, increase the development time".

If I code an app for myself, I will try all the best combinations of techs like Reflection, LINQ, Dynamic... etc for the fun of it (yes it's really fun when you can code something "beautiful" :P). However, when it comes to work, I would rather try the least time consumed way. While LINQ, Anonymous and others are great changes -- I really love them because they simplified the work, the incoming change of Dynamic has potential to produce some hard to trace bugs in large-scale projects.

I am not saying Dynamic is a bad thing; I am just saying it is not a great change for us.

IMHO, C# roadmap is focus on getting more users. C# new features set is trying to combine many other languages to C#, like JavaScript + C#, or C++ + C#.. in order to persuade more developers to use C#. This is nice, because C# indeed is a very nice language. However, this leaves many of us developers unsatisfied. Microsoft should do a survey to learn how many percent of developer actually uses more than one language in their project, like C# + JavaScript, C# + Ruby. While there are many nice features developers would love to see, Microsoft added to C#4.0 the features that the majority of us do not need, or simply can do it in not-really-hard-way.

Some people will tell that Microsoft did this because many companies have their codes in C++, and Microsoft introduces an easy way to immigrate to C#. However, again, Microsoft does not see the reason why they coded their projects in C++, the speed, and because most of their developers are mastered C++ not C#. Instead of making C# more faster (support multi-core), making C# more easier to master, Microsoft end up making it more unnecessarily complicate.

It is like the Vista. Instead of improving the speed, reduce ram consumption; Microsoft added many "effects" just to make the OS more beautiful. It would attract some users because of the beauty, and they would try Vista. But many users have left Vista because it did not meet their expectations. I do not want the same thing with C#. Windows 7 is on the right track, focus on stability and speed, which majority of users expected to see for many years. I also hope C# will focus on the features that majority of current users would love to see, not the features to bring more new users or to satisfy a few percent of users.

@Paul Berlett: I like your comment, I would love to see a "with" statement for C#. It is not hard to implement I think, and it is valuable for most of us (unlike some features that only target a few percent of us). Still, I think optional parameters is a nice enough feature :).

@mastermemorex: I do not think any of the above features will actually make your applications faster, but I think C# team has done many improvements in their framework :). They did a good job maintaining a great framework.

@ JeoWilson: I completely agree with you. Manage code is the way to go.

I would love to hear your opinions.
Kindest regards,
Hai
P.S: My first name is "Thanh Hai" not "Thanh" :P. You can also call me Hai for short. Thank you for reading.
May 5, 2009 3:12 PM PDT

uj
Total Points:
1,350
Status Points:
0
Brown Belt
 I don't want to spoil the soup but what's wrong with C++ really?

If anything I think Microsoft should promote C++/CLI.
May 5, 2009 6:44 PM PDT

uj
Total Points:
1,350
Status Points:
0
Brown Belt
 Why is Microsoft pouring this much money into a language that has no future. C# hasn't because it's so attached to a certain platform. C# isn't a necesesarry language and that's why it has no future. Like Java hasn't.
May 6, 2009 12:17 PM PDT

Doug Holland (Intel)
Total Points:
12,755
Status Points:
12,755
Black Belt
 Hey UJ

A language that has no future? Are you kidding!!!

If you mean that the C# programming language is tied to the .NET platform then you would be correct, if you mean the C# programming language is tied to the Windows platform you would be correct to a degree.

While almost all .NET developers are writing their code, and deploying their solutions, upon the Windows platform; the .NET platform has been extended to the UNIX and Linux world with Mono.

With C++ you are compiling your code with direct assumptions about the hardware upon which the resultant executable will run. It is therefore necessary for C++ code to be compiled against the lowest common denominator.

With managed code environments such as .NET and even the Java virtual machine, it is possible for a Just-in Time (JIT) compiler to discover the actual hardware upon which it is executing and then tune the machine code it generates accordingly.

Given this, it is possible for managed applications to out-perform their unmanaged counter-parts...

In some respects this is no different to the argument that some may have had when C and C++ were relatively new programming languages. Why not just write everything in assembler?

Within 10 feet of my desk is another developer at Intel who lives and breathes assembler programming although he recognizes the developer productivity gains in code in higher-level languages such as C, C++, and C#.

Regards,

Doug
May 8, 2009 8:24 AM PDT


Ihtesham		 Mr Brown Belt...you are a looser. How can you say c# has no future...You better care of your future...
May 8, 2009 11:03 PM PDT


pradeep kumar pandit		 Nice features added in C#4.0
May 10, 2009 6:22 PM PDT


Tom Koster		 I like the new features in C# and never want to go back to C++ and COM. However, it looks to me like C# is becoming the new VB6 where it allows anyone to become a developer and write horrible code. Then people like me have to come in after the previous "developer" and maintain the code and hopefully get a chance to rewrite it. And please forbid that they attempted to write multi-threaded code with little or no knowledge of shared resources or mutexes and semaphores. I guess that means job security for me. Where I work the architects are already developing coding standards to discourage the use of some of the new language features. Thanks for letting me ramble. I am not as upset as I sound.
May 11, 2009 8:33 AM PDT


Jamie Nordmeyer		 I agree with Tom. The idea of dynamic typing scares me. I love the idea of it when it comes to dealing with some of the more complex COM interop, such as Microsoft Office, but it doesn't seem to be checked. In other words, as mentioned by Tom, Mr. Jr. Developer can come along and start using dynamic for everything. At that point, C# really is VB6 with a different syntax.

My thinking is that first, you should have to enable dynamic typing on the project, just as you do with unsafe code, and second, the compiler should only allow you to use the keyword on code that ultimately uses reflection to interop. I should NEVER be allowed to do this: dynamic x = 3;.

Architecture and policy departments are going to have a field day with this laying down corporate rules on its use.
May 12, 2009 1:44 PM PDT


Ignotus		 Doug, it's out of topic but you said in your comment of April 21, 2009 10:31 PM PDT to Thanh Hai P Mai the following: "I have personally spend more time learning WCF and WF, for example, than WPF simply because of the kind of code I have been writing since the release of .NET 3.0.".
Have you some example about Receive activity to resume a workflow?
This is the hypothetical scenery:
One WinForm application as Service Host for "Requisitions" workflows (Sequential WF diagram: One initial Receive activity "RequestRequisition" starting workflow, next step a Listen activity with two branches, WaitForApproval or WaitForReject, and each branch has a Receive activity).
Other WinForm application for request some stuff and use a Send activity to communicate with "RequestRequisition" Receive activity.
Workflow then is idle and persisted in SQL Server.
Other Winform Application is used to approve or reject requisition. How to connect resume the persisted workflow? I been using other Send activity at this point but do not works because instance do not exist in host.
That is an idea to use Send/Receive activities and persisted workflows, but have you some example that I can use as a guide with this kind of situation? I haven't found information about it.
Thanks in advance.
May 13, 2009 7:27 AM PDT


DW		 Very interesting article on the future of C#. However, particularly with regard to LINQ, it was my understanding from other trade journals that Microsoft was backing away (rather rapidly) from LINQ in favor of the Entity Framework...is this not the case?

May 19, 2009 10:42 PM PDT


Nouman Naseer		 Great work... will love to code in C# 4.0

Thanks Doug Holland
May 20, 2009 4:51 PM PDT


Cris		 And the beta is finally out!
May 21, 2009 11:45 PM PDT


Jitendra		 cool feature ..moving twards c++ :)
May 28, 2009 12:31 PM PDT


Nethemas		 Great just what C# needed. Another feature (dynamic typing) to enable ingenious short-term thinkers to sabotage long-term efforts in stability, maintainability, and understandability.
May 31, 2009 7:01 PM PDT


charles		 写的还可以，学习了。
June 1, 2009 1:45 PM PDT


Markus		 Dynamic typing makes me think of the C++ Win32 API, and I don't like it.
June 4, 2009 9:54 AM PDT

Prasanna PK
Total Points:
60
Status Points:
10
Green Belt
 We know that C# allows event-driven programming or event-based programming, does F# allow the same?
June 8, 2009 7:49 AM PDT


Daniel B		 I personally think the dynamic addition is a great feature if viewed in the right context : to allow proper interop support with COM and the DLR, as well as a succinct way of handling some types of reflection calls (if i remember correctly from past MSDN blogs, non-interop dynamic calls will use reflection under the hood). invoking PropertyInfo's Get/SetValue methods can be a bit of a drag. If users start abusing it, that is unfortunate, especially if they are your co-workers, but then again I believe users shouldn't bother with features they don't understand.
June 16, 2009 11:07 AM PDT

V-Map Enterprise Edition
Total Points:
5
Registered User
 Also Great !
June 19, 2009 11:44 AM PDT


Fred Zarguna		 Props.

One thing I believe a number of people are missing here is that the covariance/contravariance and addition of optional parameters actually address design weaknesses in the usability and maintainability of C#, and they are not only welcome but necessary to reduce its difficiencies in these areas. For example: you have a method, Foo(int x) and client code needs to access or change additional state information or behavior in the class. In C++/object Pascal, you can do:
Foo(int x, bool hasY = true) without breaking any existing code, and without changing the basic logic of the method or proliferating a lot of pointless overloads.

Dynamic stuff is required for decent interop with COM and with dynamic languages, which we must accept as emergent technologies whether we like it or not. The point should be to enable your engineers and developers with the best skills, not hamstring them because the idiots in your organization write bad code. I started coding on the 029 keypunch and I can guarantee you that the morons in your shop are going to write terrible dreck and no language feature is going to stop them. Those of us who are actual craftsmen are going to spend some part of our time cleaning up the bottoms of their birdcages no matter what, so please don't omit language features at our expense because they're too "dangerous" (read: kewl) for "most developers."

Unmanaged C#: drop into unmanaged code, or code C++. If you need performance you are going there anyway. .NET will *never* match C++. That said, the interface for unmanaged structures in C# is craptacular and needs to be improved. A lot of systems in legacy code are going to stay that way simply because at the current evolution of C# it's too hard to do I/O and pass legacy strucutred data across language boundaries. If moving legacy applications into C# is important to the C# team, this is something they need to fix.
June 24, 2009 2:02 PM PDT


pspet		 I think of dynamic type as a simplification for reflection code. The problems you have with reflection, you will have with dynamics.
No other implications if you use it only in this context.

[quote]
object calc = GetCalculator();
Type type = calc.GetType();
object result = type.InvokeMember("Add",
BindingFlags.InvokeMethod, null,
new object[] { 10, 20 });
int sum = Convert.ToInt32(result);

----------------------------------------------
dynamic calc = GetCalculator();
int result = calc.Add(10, 20);
[/quote]
June 29, 2009 12:39 PM PDT


sfg		 not LINQ. Why, Microsoft, why?
July 1, 2009 9:48 AM PDT


Paul Jones		 I agree with Thanh Hai P Mai.

I think the language will improve for a few elite programmers but become more difficult for the rest of us to understand as a result of this.
I really wish some things would become simpler.

1. Creating, raising and handling events without creating scores of delegates.
2. Creating and using threads without creating scores of delegates.

Frankly, I wish delegates would just go away.
July 1, 2009 12:49 PM PDT


Daniel Smith		 Lame.

Programming languages should be like tools in a toolbox. Certain tasks are best performed with certain tools. C# is quickly turning into one of those Swiss Army pocket knives you find in thrift stores. I'm talking about the one with something like 100 gadgets in it. Sure, it does everything, but it weighs a ton and doesn't fit in your pocket.

As the old adage goes, if you try pleasing everyone, you end up pleasing no one.
July 3, 2009 3:29 PM PDT


Kalyan Dixit		 its too good to have.plz try to mess with it
July 3, 2009 3:45 PM PDT


kalyan
hi,doug
what about msdn library for vs2010 ?????
for vs 2010 which ebook shall i refer ?
plz send the link to download it.
July 6, 2009 11:44 AM PDT

Doug Holland (Intel)
Total Points:
12,755
Status Points:
12,755
Black Belt
 Hey Kalyan,

With Visual Studio 2010 beta one there is no MSDN library that you can install locally and so you'll have to use online MSDN documentation.

Once we have beta two we should have an MSDN library that can be installed locally.

Regards,

Doug
July 6, 2009 12:03 PM PDT


Pat Siazon		 Doug, how about the automatic outlining on control structures. A lot of developers have been requesting this since VS2008.
July 6, 2009 12:05 PM PDT

Doug Holland (Intel)
Total Points:
12,755
Status Points:
12,755
Black Belt
 Hey Pat,

I'm not familiar with the proposed feature, please e-mail me at firstname dot lastname at intel dot com and I'd be happy to look into it for you. Please provide me with as much information as you can and ideally a MSFT connect feedback item ID where either you or someone else suggested the feature.

Thanks,

Doug
July 10, 2009 3:41 AM PDT


Quantumplation		 One thing I'm waiting to see (and someone fill me in if they can try it for me), is to see if named parameters can be used to create signature-identical overloads:

// Create an object with a name
public void Initialize(String name)
{}

// Create an object, pulling properties from a file
public void Initialize(String file)
{}

then:

MyObject.Initialize(name: "Foo");
MyObjec2.Initialize(file:"Bar");


One concrete example I would use this for is with a certain object I am writing called "marbles". Marbles have "tags" (a string array), and Data, which is a mapping of string to object. I would like to have the this operator access the tags in some cases and the data in others. For example, object[tag:"A"] and then object[data:"B"].

Another feature that I would like to see is the application of Generics to a this operator.

Object<Type>["name"];

Just syntactic sugar stuff that would clean up the interface to several things I'm working on.
July 22, 2009 7:09 AM PDT


Mitesh		 Nice.

Please upload code Particularly with COM operations with F/W 4.0 in detail.
August 2, 2009 9:33 AM PDT


peter		 Very interesting stuff. look forward to C# 4.0
August 6, 2009 4:00 AM PDT


Rama kanth		 It's nice article for a startup into C#.NET 4.0.
August 6, 2009 5:37 AM PDT


Selva


Good very Nice,

Thanks,
August 12, 2009 1:54 AM PDT


felix		 I must say, after the excitement of LINQ, I was a bit disapointed by this article. None of the new features seem that exciting to me as someone who doesn't use COM...

Dynamically Typed Objects. - for COM, or am I missing something?
Optional and Named Parameters. - syntactic sugar
Improved COM Interoperability. - for COM
Safe Co- and Contra-variance. - somewhat useful, but a minor detail.

Where are the cutting edge developments and whizz-bang features? Maybe its time to look into F# :)
August 18, 2009 8:51 PM PDT


Greg		 As for Dynamic typing - like anything else it can be abused. Think of it as 'fire' - it can keep you warm at night or burn you to ash. You just have to use it right and supervise the 'kids' when they use it.

For the Jr. Developer who wants to use dynamics for everything - that is what code reviews are for :).

Good article.
August 26, 2009 12:39 AM PDT


Carey Tenali		 Excellent Tutorial ....
August 27, 2009 3:55 PM PDT

Baltazaar
Total Points:
314
Status Points:
264
Green Belt
 I've been programming in C# since the first release of the language, along with Visual Studio 2003, 2.0 in 2005, 3.0 in 2008, and I'm currently studying for a MSCD certification in C#/.Net 3.5 programming.
C# Started out as a "Simple, Object Oriented, General Purpose programming language". But now, if you think that C# is easy to learn, think twice.
The problem is manifold, as I see it. For starters, C# is very high level. The .Net components are vast. It is so much to keep up with, and I'm speaking from personal experience, I read books on C# all the time, and it's a never-ending, painful experience to keep up with the evolution in a "young" language like C#.
Second, I believe that no one is capable of doing "great" programming in a high level language without knowing t least one language "closer to the metal". It becomes so abstract that you don't know what or why you're doing what you do, it's just what the implementation says, and what intellisense comes up with as you code. If you top that with a product like JetBrain's ReSharper, you don't actually have to know how to program, to cook up a "working" solution.
But. It doesn't run as fast as your customers want. You don't know how to make it run faster, because you don't know how to write efficient algorithms that suits just the problem at hand. All you know is the generic solution, that comes in the package with "batteries included". But the batteries don't last forever.
I've recently swiched to native C++ and total control, with new threading libraries and a weapon that shoots what I'm aiming at. For the less critical code, sure, C# and .Net are great. I would certainly use it for the GUI shell of my application. But for the core functionality, I would never rely on precoded libraries alone. Especially when the whole thing has to JIT compile after initial CIL compilation. That is just not effective.
In ten years, there will be a shortage in qualified programmers that can do both efficient, relatively low level programming AND the high level solutions that is increasing in popularity as we speak.
With the possibility to make native .dll's and mix and match them with .Net code, I see no reason for relying on one paradigm alone. I'm much more comfortable in C++, and no matter what gets glued on top of C#, I'd never use it for efficient mission critical code.

Chris

August 31, 2009 4:30 AM PDT


Nabil Al-Jarmozi		 NICE !
September 2, 2009 3:37 AM PDT


anandakumar muthusamy		 Nice article for new features of language C# 4.0. Specially, dynamic type is very useful for us in many ways. I think optional parameters are coming from one of the feature in C++ language.
September 6, 2009 7:37 AM PDT


sharad chaurasia
really good features r implemented inside c#4.0
October 15, 2009 3:01 AM PDT

saeidnasirlou
Total Points:
10
Registered User
 Greate!
October 15, 2009 3:03 AM PDT

saeidnasirlou
Total Points:
10
Registered User
 but that ebooks not found in Per to Per downloder
October 19, 2009 3:39 PM PDT

Doug Holland (Intel)
Total Points:
12,755
Status Points:
12,755
Black Belt
 Hey Chris,

While there has been much debate among C# MVP's and others about some of the new language features added within C# 4.0, the dynamic keyword being the cause of muc of that debate, I would still maintain that the core language is still true to the original claim that it is a "Simple, Object Oriented, General Purpose programming language".

Within the realm of .net technologies what is really causing an issue is the pace of innovation. In terms of the .net framework 1.n and 2.0 it was almost possible for most C# developers to be aware of most aspects of the framework. When the 3.0, 3.5, and 3.5 SP1 frameworks were released, and 4.0 next year, there has been such an explosion of new framework elemens and associated technologies that no one person can be expected to know the entire scope of the .net framework and how to effectively apply the framework.

I'm not suggesting that before 3.0 a developer could know every type within the framework, although they could have been equally comfortable writing code for console applications, ASP.NET based Web applications / services, and Windows Forms applications.

Today, you'd have to add to those .net technologies the following: Silverlight, WCF, WF, Entity Framework, RIA services, etc.

Instead of trying to learn all of these tecnologies, developers should master their language and the underlying runtime by reading a book such as CLR via C# by Jeff Richter. When you then have to apply these skills to WCF, WF, Silverlight, etc. you'll be well prepared.

Regards,

Doug
October 22, 2009 10:01 AM PDT


Mok		 If can include more feature like python dictionary, list or tube will be nice :)
October 29, 2009 8:43 PM PDT


Kyle Huff		 Doug: Agreed. The Richter book is all kinds of awesome. Sadly, mine is Copyright 2006, and therefore hopelessly obsolete.
October 30, 2009 12:49 PM PDT


Awadhendra		 Working with c#4.0 is really interesting..........
It is write it is not easy to learn but it is so interesting that it every difficulty go far away
November 5, 2009 12:26 AM PST


Iran		 Thank
very good

NextGen(Programing):
C# 4
November 12, 2009 11:43 AM PST


Moe		 Is there a committee at MS that evaluates new features and there impact on creating clean and easy-to-read code? Don't get me wrong, I love these new features like Generics and LINQ, but It would seem if you had so many different tools on your belt, one could find themselves in a abyss of counter intuitive syntax.

-Moe 2000

Trackbacks (26)


Leave a comment  

To obtain technical support, please go to Software Support.
Name (required)*

Email (required; will not be displayed on this page)*

Your URL (optional)


Comment*