Asking the same of Java yielded some very interesting responses, so I thought it would be only fair to ask the same thing of C#, probably Java's closest rival.
I actually like this sort of question because it's a lot less subjective than "why should I choose this language" or "why is this language so great."
So.. what's wrong with C#?
To a lesser degree, C# has the same problem as Java, namely its verbosity (code bloat!). Although most features of newer versions explicitly address this weakness.
The most obvious weakness is perhaps its dependency on the .NET platform which still makes it kinda limited to Windows, although Mono is beginning to pull it over to Linux and OS X.
Compared to VB, I find it a weakness as well as a strength that there are two virtually equivalent languages. On the one hand this is great because it gives us more choice, on the other hand this means that within Microsoft there are two competing teams that often don't communicate well enough with one another and basically spend twice the resources that one team alone would consume.
From a language designer's point of view I find the choice of syntax poor because the only reason for it was habit and marketing strategies and not technical reasons.
There are a lot more minor weaknesses but all in all I think it can be concluded that C# is one of the better tools currently on the market, especially in combination with the surrounding ecosystem.
What's wrong with c# is it is from Microsoft. IMHO It's a very good language, but people just love bashing MS, it would get much better rep if it wasn't from microsoft.
I don't think that C# 3.0 gives you much to complain about, unless you dislike static typing and/or case sensitivity, but that's just a matter of personal taste, and even in the case of static typing, you have type inference to ease a lot of the pain. Recent additions to the language, such as LINQ, lambdas and so on, fill in a lot of gaps.
There are only a couple of things that niggle me about C# a bit. One is the fact that it is a compiled language. This means that the edit-compile-test loop can be a bit slow at times, especially when you are doing ASP.NET development and it can take up to a minute between making a change and seeing the effects of it in your browser. However, even then it's a trade-off -- you get a boost in speed, and a lot of syntax errors are trapped at compile time that might well slip through the net in an interpreted scripting language.
The other minor niggle is that it can be a bit over-strict in some cases. Covariance is an example -- you can't do this for instance:
List<object> myList = new List<string>();
I would say the following:
Don't get me wrong, I love .NET framework but sometimes I do non-GUI C# applications that could run also on Linux servers. Yes I could use Mono but that would mean give up C# 3.0 (expression trees, LINQ to objects, lambda expressions).
This is not as much problem of C# because it applies to whole .NET framework, but I would prefer to implement in some of my projects my own garbage collector or free the memory manually just like in C++. GC does things right most of the time but from time to time you deal with specific cases where you need more control than usually.
Some apply to the whole framework, not just C#
I concurr with the static typing being a bit of a drawback, though its not insurmountable. Also, its lack of optional parameters. Between those two doing things like automating office is a nightmare
A bit off topic, but anyway...
...you can't do this for instance:
List<object> myList = new List<string>();
No, because that doesn't make sense. That way you could add objects that aren't strings into the List<string>, like so:
List<string> strList = new List<string>();
List<object> objList = strList; // Both variables point to the same list
objList.Add(new object()); // Now you add a object into the strList
Update:
I just saw a talk by Anders Hejlsberg on the future of C#, where he says C# 4.0 will add safe co- and contra-variance. That is, in C# 4.0 you will be able to do this:
List<string> strList = new List<string>();
IEnumerable<object> objList = strList;
foreach (var o in objList) Console.WriteLine(o.ToString());
Konrad writes:
Compared to VB, I find it a weakness as well as a strength that there are two virtually equivalent languages. On the one hand this is great because it gives us more choice, on the other hand this means that within Microsoft there are two competing teams that often don't communicate well enough with one another and basically spend twice the resources that one team alone would consume.
Sorry, but I'm kind of getting tired of this Microsoft "criticism". VB and C# do have plenty of similarities... but plenty of differences too. Why should you care if they're "wasting resources" (your opinion)?
If C# and VB were implemented exactly as-is by two separate open source projects, everyone would be falling all over themselves praising their work. But let MS actually deliver choice on their own (bastards!) and they're just "dumb old MS". Sorry, this is boring.
On the other hand, if MS had never created, say, VB.NET and "only" offered C#, just watch the me-too crowd coming out of the woodwork complaining about MS not offering enough choice. Bah.
Microsoft deserves plenty of criticism... but the whining about "too many ways to do something" (smart clients, data access, MVC vs. WebForms, C# vs. VB.NET, etc. etc. etc. etc.) is getting absurd.
Before starting, let me express my surprise that the weakest and least interesting argument in my debate was so heavily attacked.
VB and C# do have plenty of similarities... but plenty of differences too. Why should you care if they're "wasting resources" (your opinion)?
It's the waste of intellectual resources that bothers me. I believe it was Stepanov who once said that when you learn a new language it should change your perception of concepts. If it doesn't, it's worthless. Since VB and C# are so similar, it's difficult to find C# concepts that aren't also in VB.
Furthermore, the two teams don't collaborate well enough. There's plenty of evidence for this. Paul Vick, chief VB developer recently wrote about introducing iterator methods into VB (the yield return feature from C#). He writes that the feature will probably not appear in the next version because it's a lot of work to do. What the hell? Why can't they copy the C# implementation from the people next door?
(Actually, it's a little more complicated because the planned VB feature is much more powerful than the current C# implementation but the argument remains the same.)
But let MS actually deliver choice on their own (bastards!) and they're just "dumb old MS". Sorry, this is boring.
That's not what I wrote, nor was it implied in any way. I even said that on the one hand it's great to have the choice.
On the other hand, if MS had never created, say, VB.NET and "only" offered C#, just watch the me-too crowd coming out of the woodwork complaining about MS not offering enough choice.
Obviously, it should have been “only VB” ;-) Offering C# was just a clever marketing trick to get the C and Java folks to bind themselves to the Microsoft platform. (And please don't take this too seriously!)
I've written about this a few times before: Why I like VB.Net VB.Net vs C#, Round 2
@lubos hasko
Don't get me wrong, I love .NET framework but sometimes I do non-GUI C# applications that could run also on Linux servers. Yes I could use Mono but that would mean give up C# 3.0 (expression trees, objects to LINQ, lambda expressions).
Check out the Mono 2.0 Preview Release, which implements everything you mentioned. It even supports Linq to XML in C#. It is scheduled to be released at the end of september.
If your going to put code by reference functionality into the language, why wouldn't you allow constant references?
Because it's complete nonsense. const& in C++ is an optimization that is used to prevent the compiler from making an unnecessary copy, nothing more. In C#, this is redundant as no copy is made during a method call at all for reference types. Furthermore, value types should be small enough to not benefit from pass by reference. ref passing in C# has the sole purpose of modifying the argument within the method and const would prevent this, thus negating the effect.
I actually find the syntactic similarity between VB.NET and C# to be refreshing.
It doesn't seem useful on the surface, but imagine two very different developers with very different histories:
Developer (A) has been working with informal training all of her life, mostly in VB6 due to its simpler learning curve and forgiving style. The style of C-based languages seems cryptic and even daunting to her.
Developer (B) has been rigorously brought up in C-style languages. She is at home with the style, and comfortable with both the benefits and limitations of this class of languages. She would consider the extra verbosity of VB to be a waste of her time.
However, since C# and VB.NET now share pretty much the same feature base (they share common syntax/Domain Language [if you consider "programming terms" as a domain]), and the style that is used to perform most tasks is now very similar between the two. Developer (A) can get her feet wet in a C-like environment while still working in relatively familiar territory. Developer (B) can continue to work in C# and trust that, gradually, Developer (A) will become less and less intimidated by her code as Developer (A) begins to realize the truly deep similarities between VB.NET (which Dev A is familiar with) and C# (which Dev A is now able to be exposed to in a more "get your feet wet" manner).
Yes, some will say Developer A should just jump in... but in the real world, I would venture to say that there's more of Developer A out there than Developer B. Having two very similar languages that come from very different backgrounds presents the opportunity for a merger of worlds: and maybe even an opportunity to help bring Developer A closer to the skills of Developer B as A begins to understand more of what B writes.
I've just thought of a real criticism. Not so much of the language itself but more of its creators.
The C# team has released some pretty polarizing coding guidelines (e.g. “never use var declarations except for the result of LINQ queries”). Unfortunately, most of these opinions are not justified in the least. It's hard to decide if there simply is no technical rationale behind the decisions or whether this rationale is nontrivial. If it is nontrivial, please provide it! It's important. And if it's subjective, tell us so. As it is, I ignore most .NET programming guidelines created by Microsoft because they're worse than useless in their current form.
To take up the above example, the C# team gives us a great feature to fight code bloat and then immediately takes it away from us. Surely there must be a better reason than arguable readability loss?
@mmattax:
it is used as a guarantee that a method can not alter the reference, it is not just a compiler optimization.
Right. I implied that in my posting, because if the programmer doesn't want the value modified, she can simply pass by value instead of by const-ref. The only reason to pass by const-ref instead of by value is to prevent an unnecessary copy.
I understand for reference types, but what about non-reference types, things such as arrays?
Arrays are actually reference types.
The coding guidelines for .NET programming tell you that only very small types should be value types and for very small types, passing by reference is not cheaper than passing by value. ref should never (!) be used for optimization but only if the value has to be modified.
i loathe sealed classes. it's OOP for cryin' out loud, let me inherit!
There are lots of things I'd like to add or fix in C# and which I think would be easy to add/fix. I think that's a different question though.
As for things that seem to be permanently wrong, or at least would be very hard for MS to fix now, there aren't many. Let's see...
Loop Variables and Lambdas - The loop variable in foreach should be captured as a copied value by anon-funcs/lambdas inside the loop statement/block. Instead it is treated as if it was declared outside the loop, which is not what you want in 99% of situations, leading to the well-known lambda-foreach bug as documented on a thousand blogs.
No Free Functions - It should be possible to declare a function in a namespace (called a free function in C++). Instead we are required to declare them as static class members. In practice this means that we are forced to put a . in the middle of our free function names. This is required by the CLS, but I think it's a rather outdated idea.
struct - I originally thought this was a superb improvement over Java, user-definable compound value types, because as a C++ user I was prejudiced against the idea of having to allocate everything from the GC heap. But in practice they are terrible things with inconsistent and surprising behaviour, and the GC heap performs brilliantly anyway. Structs would have been better if they were required to be immutable. Also there should be a way to make the default constructor private so that the compiler will stop you from using the struct in any context where the default constructor might be called, e.g. in an array.
void - if I have a function void Foo() why can't I say return Foo()? Should be fine from another void function. If this were so, we wouldn't need Action, just Func<void>. As we find more uses for functional style, the more we will encounter these situations where we have to write the same generic type twice with different names, to deal with this unnecessary asymmetry in the type system.
I also think when dynamic is added in version 4, that will be a largely unnecessary blot on an otherwise very carefully defined and evolved language. Maybe I'll feel differently when I try to use it, but I seriously doubt it.
It's becoming less and less simple to use. It seems like there's never a feature in another language that Microsoft doesn't feel it must add. So you end up with multiple ways to do the same thing.