Thursday, March 27, 2008

That's cute, but wrong...

It's not everyday I come across something as full of nonsense as this article. I'm quite surprised the author hasn't taken it down by now because of how wrong it turned out to be. Fine, he didn't write the original, but he's definitely hoping. Just taking a look around the site really goes to show the guy has some serious "short man virtual machine" syndrome. I use what I like. I don't like Java. I don't use it. Clearly, he doesn't like .NET. Its my very humble opinion that if you don't like it just don't use it. It shows a serious lack of maturity, in my mind, to come up with the usual sort of tabloid "101 Reasons why Java is better than .NET" rubbish.

I decided, with an open mind, I would take a look at some of the reasons. Here are two of them that I noted before I just decided to stop:

"26. Better Support for Peer to Peer Networks

Java is used extensively to build Peer to Peer (P2P) networks. There are open source java implementations of the gnutella protocol. JXTA is an emerging standard for P2P networks and uses Java as its prototype implementations. Limewire and Kazaa downloaded hundreds of millions of times are written in Java and are among the more popular P2P clients available to date."

Errm.... what? Thats like saying, use Microsoft Operating Systems because there is more software out there? To me, points like that obscure what should be the core reasoning of the argument. It should be about the language features/advantages. Java is better because the GC of the virtual machine is more advanced... or whatever.

... And ...

"47. Open Source Java Compilers and Parsers

There are several open source java compilers, many written also in java (i.e. Jikes, Eclipse, AspectJ, Kopi, Kiev) that make it easier to develop tools like Auditors, Metrics, Code Coverage and Refactoring. Furthermore, it makes is easier to develop embedded languages like SQLJ.

By contrast .NET's CodeDOM assembly isn't able to parse .NET languages like C# or VB. It can only generate code, however what real gain is that, when writing out strings will suffice?"

There is so much wrong with the last statement in his point, its not even funny. Again, another uninformed view of things. CodeDOM while not fantastic, can still be used to write (largely) language agnostic code that targets the .NET framework. Think Code Generators. You want to do that using strings. Good luck... let me know how that works out for you. He should have contrasted the shortcomings of CodeDOM vs. the other offering if he wants to make a debate of it. And he should certainly think twice about finishing off a point with utter bollocks. Even though he may have been 100% correct with the first part, you kind of loose the point, and you have to wonder just what other rubbish he is trying to spit out.

Sure, like I said, its a 2003 article, and sure, he has a little tongue-in-cheek stab at "I'm open for debate" with

"People who hate the list have also argued that some reasons are invalid because over time .NET will catch up.  All I can say to this line of argument is that this is a list about  "Today, the Here and Now".  We can always revisit the list a year from now, and just maybe, there may be less reasons why Java is better."

But the truth is, back then, he was/is trying to compare apples with oranges. To me that doesn't work. Compare things when they are on the same level.

All of this, however, is nothing when you read this article. I mean, goodness. Taking that last little bit into account, it seems he is worried that should there be better IDE tools that target the .NET framework (and we are not even talking about language enhancements), his beloved Java may get the shaft. You have to wonder that, if he thinks the release of a 3rd party tool becoming available on BOTH platforms, is a worrying thing, Java may not be "all that" he has built it up to be in the first place. He is/was clearly worried about something. And looking back it it now - he's had every reason to worry. .NET is flying fast and furious. And no, its not because now the IDE has built in code refractor support and/or JetBrains making swanky tools available for it.

Don't get me wrong - if you use Java good on you. If you enjoy it, even better. I didn't. I preferred .NET. Don't try and "convert" me, I wont try and "convert" you. And if you are going to try, do it with a proper discussion. I welcome it. I'm not rooted in one language, I'll use the right tool for the job. If that's Java, so be it.

Last word on the matter...

I really dislike idiot zealots.

Wednesday, March 5, 2008

Don't forget about string.IsNullOrEmpty() in .NET 2.0

I have noticed, in my travels though code written by others, that string.IsNullOrEmpty is simply being overlooked.

As most of you know by now, its much better practice, performance wise, to check if length of a string is less than or equal to zero, than comparing it to "" or string.Empty, when trying to determine if its an empty string or not. For those of you who didn't (yes you, in the back, I see you) here is a MSDN article that answers the question. Anyways, I digress and that's not the focus of this post.

The point is that in .NET 1.1 you did the classic:

if( someString == null || someString.Length <= 0 )
return;


Fantastic. However, typing that every time you want to do a "is the string empty check" gets old quite fast. Never fear - MS to the rescue of our ever precious keystrokes. It was decided that in .NET 2.0 that a static function, doing just the above, would become part of the public string interface and save us a little of the hassle.



Now the above code can be "simplified" as:

if( string.IsNullOrEmpty(someString) )
return;


It's a lot more expressive of intent, therefore more readable and as an added bonus, less of a pain to type (a massive 12 chars including white space ;P).



I have just noticed that a great deal of developers either don't now about it, simply don't use it or are still comparing strings to "", hence this post. Not exactly a "wow" or "this-going-to-change-my-life-forever-thank-you-so-much" post, but hopefully it will serve its purpose. It's just a little reminder to those who have made the move from 1.x to 2.0+ (or are just starting) that it's there... aching to be used.

Tuesday, March 4, 2008

The Object.Equals Gotcha

I haven't had the need to override the .Equals implementation on reference types all that much in my coding career. However, such a need sprang up earlier on today. While implementing it in the most rudimentary way, I just couldn't shake the feeling there was something that just didn't feel right. So I booted up Good 'ol Google and took a quick look at what was out there.

I came across this article that spells it out quite nicely (be sure to read the comments as well). Bottom line, if you are dealing with a reference type, its better to include an additional method on your public interface that will compare the contents for equality.

It's still a bit of a gray area for me. I am going to have to sit a while and mull over just what exactly the implications are, but these little bits of information are great to have stored in the back of your mind.