Thursday, August 18, 2005

.NET blows

When I'm not busy being an entrepreneur, I spend my days as a programmer. And over the past couple week or so, I've been fiddling with C#, .NET 2.0, and Visual Studio 2005. Specifically, I've been trying to make NHibernate and Spring.NET play nice. Let me just say that it has been... shitty.

This isn't my first experience with .NET. I spent a glorious 5 months working in a .NET shop in Dall-ass about 3 years ago. At the time I even thought it was an improvement over Java (generally speaking). I'm not so sure anymore.

But before I get all nit-picky, let me give credit where it is due. Even with my limited .NET experience, I have found a number of things where MS got it right:
  • Properties - not a huge deal, but certainly better than the getter/setter bullshit of Java Beans.
  • Boxing/Unboxing - Java introduced it in 1.5, but most developers are constrained by other (read: business) considerations and can't instantly move to it.
  • foreach - Again, Java caught up with 1.5.
  • Delegates - Using interfaces as a function pointers gets tiresome.
  • using - Not the declaration of namespaces at the top (the using directive), but ability to clean up an IDisposable without a try/finally block (the using statement).
  • Generics - New to both Java and .NET, but erasure in Java is incredibly stupid.
Again, I'm no .NET guru, so there are probably others. That being said, .NET has a number of issues.
  • Collections - Knock, knock. Who's there? The ISet interface. The ISet interface who? (that was the punch line)
  • Visual Studio - I can remember when MS had the best IDE around - it was in a time we like to call the late '90s. Since then, Eclipse and IntelliJ IDEA have blown VS out of the water. MS has always been known for their tools, so what happened?
  • non-virtual methods - All methods are non-virtual by default in C#. Do you have any idea how ridiculous this is? Seriously, this might even be dumber than erasure. Take today for example - I was trying to customize Spring to handle a few peculiar ways we will be using it, but was thwarted several times because I couldn't override certain methods. I seriously had 3 or 4 different solutions that would have been better than what I ultimately implemented, but each was futile because the guys who wrote Spring didn't declare everything virtual. I don't even blame them, they're just following the .NET paradigm. (And please spare me any bullshit arguments about the cost of virtual table lookup. If we were that worried about performance, we wouldn't be running byte code against a virtual machine.)
All this might not seem like much, but it was enough to annoy the shit out of me today. And apparently, I have even more headaches to look forward to.

1 Comments:

Anonymous Anonymous said...

About non virtual by default.

The idea is not the cost of method calls, the idea is the promises you make when you're marking a method as virtual. This mean that the test matrix for that method grows since you need to take into account that the method can be overriden by a sub class.

MS' approach to this is not to make promises that the are not going to keep.
See all those (override and call the base class method - or watch your code die.) examples

5:09 AM  

Post a Comment

<< Home