I normally don't get into these language dick-size wars, but this was amusing.

Responding to Andy Oliver's Why C# is better than Java, part one. 1-5

1. The Filesystem: This is, at worst, a very minor annoyance. I work in an IDE, so the base unit is the class anyway, not the file.
2. Case-sensitivity: In a world where you must interoperate with both case-sensitive and case-insensitive filesystems, being case-sensitive is the safest way to avoid major tangles later on. Such as when you MADETHEMBIG (as Oliver suggests), and then try to check them back into the case-sensitive CVS. Really Bad Move.
3. Hashtable syntax candy: Being able to overload [] is, I admit, pretty neat. But it's pretty mild syntactic sugar.
4. Less reluctance to change the VM: Big, big problem for C# and .NET in general. If Microsoft runs true to form, incompatible VM updates will be used as a goad to force upgrades (“Sorry, you need CLR 553 for that, which is only supported on Windows 2010”), and to keep projects like Mono chasing after a moving target.

   In addition, .NET is substantially younger than Java. When Java was the same age as .NET is now, it was making pretty big changes to the VM, for example introducing the concept of nested classes.

5. Spec of the Day The examples Oliver gives are stupid. Of course, email, MOM and XML messaging are different specs, they're totally different things. Why don't we use SMTP for middleware messaging? Oh, because e-mail is best-effort store and forward, while MOM is reliable pub-sub.

   On the other hand, any perusal of the JCP site will find a bunch of specs that should never have been proposed. Do we really need a standard Sun-mandated API for rules engines? Should Java Server Faces really exist when there's so much competition happening in the real world to try to create better web frameworks?

   Once again, C# is young. Think C# is going to avoid having spec-of-the-day disease? You're on crack. Microsoft is famous for it.

   Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET - All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That's probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can't spend writing new features. —Joel Spolsky, Fire and Motion