Here is part 3 of the Java vs. C# series which should have been called "Why C# Is Better Than Java". I remind you to read part 0 in order to get familiar with the motivation behind the articles. Part 1 and part 2 are also recommended...

   C# has a lot of features that are kind of obscure but are really cool when you need them. When I was young and reckless I once declared one particular C# feature stupid and useless. Less than a week later I had to use this feature to avoid writing some ugly code and realized how useful and deep the feature was. Since then I have learned not to question Anders's (Hallowed be His name!) wisdom even when I do not understand it. A few days ago I was astonished to find a new use for another feature that I thought I fully understood. According to the C# designers when they evaluate a feature they favor features that have multiple uses over features that solve only one problem. It seems like I underestimated the C# team once again and by now I should have known better. The feature in question is explicit interface implementation...

    Lets end this once and for all! In .NET it is ID and not Id. I did not make this up. It is in the framework design guidelines despite the fact that the .NET Framework contains counterexamples. I have a proof:


I recommend seeing the full video if you are a .NET developer but the issue in question is described on the slide on 52:25.

   Here comes part 2 of the "Java vs C#" series. I still want to remind you to read part 0 and part 1 because they contain my motivation and important side notes but if you do not feel like reading them just remember that I only compare the C# and the Java language and claim that C# is better but do not compare the Java and .NET platforms and do not claim anything about the platforms as a whole (at least not in these articles). Read on to find out why Java's approach of letting methods be virtual by default is wrong...

   After I published part 0 I was criticized for being biased. I was told that the title suggested neutrality but the actual article is not neutral and "Why C# Is Better than Java" would have been a better title. In fact "Java vs. C#" was just a working title that I forgot to change and I agree that the suggested title would have been better. I was criticized for exaggerating the damage caused by the Java approach and overstating the benefits of the C# approach. While this may be true it should be clear that these are real problems and I am not making them up. I do not pretend to have discovered them. In fact I have read about most of the issues listed here in interviews and articles by both Java and C# designers. The reader is also advised to read part 0 where my motivation is clearly described.

   And now lets get into today's topic - generics...