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.

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.

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.

If only the truth was a base class...

I was having a discussion with a friend of mine and, as fate would have it, we managed a brief stint over the theory of truth and lies...
"Lie" is such a strong word - to alleviate this burden some think it's better phrased as "extending the truth". Now if only there was some technical implementation of this.... hmmmm....

Fear not! I have done it. Here it is in all its glory...

The truth as a base class.

(in C#)

   1: public class ExtenedTruth : Truth

   2: {      

   3:     public override string TellTheTruth()      

   4:     {          

   5:         StringBuilder sb = new StringBuilder(base.TellTheTruth());          

   6:         sb.AppendLine(" and we extend over here... ");           

   7:         return sb.ToString();      

   8:     }

   9: }

Done! All this without any lies involved. What a pleasure... :D

P.S. please notice the use of the StringBuilder so that we can append loads onto the "truth" with as little of a performance hit as possible.
P.P.S. I am pretty sure this would compile on the Mono framework.
P.P.P.S I think I need to patent this.

I hate those Permanent Temporary Failures...

This is one of those things that make you laugh on your Monday morning...

Let me set the scene for you. A few days back, I was attempting to send a file via email (gmail) to various recipients. It would send, but never reach its destination. Frustrating to say the least, especially when you take into account that 12 previous attempts had already been made.

Now the more technically savvy among you may say: "Why not just use FTP? Email is notoriously bad for reliably sending files, especially when its important..."

Bottom line - I couldn't. Lets just leave it at that and be done with it. Below is a snippet of the delivery failure I got from Google (obviously I changed the email address and bolded the important parts...).

*snip*
...
subject:
Delivery Status Notification (Failure)

This is an automatically generated Delivery Status Notification
Delivery to the following recipient failed permanently:
names.changed.to@protect.the.guilty
Technical details of permanent failure:
TEMP_FAILURE: SMTP Error (state 16): 451 qq temporary problem (#4.3.0)
  ----- Original message -----
Received: by 10.100.212.14 with SMTP id k14mr997577ang.1193785829292;
...
*snip*

Well, I thought it was funny... a permanent failure with a temporary problem. Sweet.

P.S. what is also quite interesting that Google marks those failure notifications, from itself, as SPAM. I'm not complaining, just an interesting side note.

It seems Windows Live Writer has a problem with publishing...

any posting that has been assigned a category with an "!" in it.

For those of you who don't know, Windows Live Writer is a nifty little tool that allows us to blog away independent of the native blogging editors provided by the various different flavours of blogging software. I rather like it.

Aaaanyways...

I get the following little error notification when attempting to do so:

The software is still in beta, so little issues here and there are to be expected I suppose. The upside is that the software didn't crash and my post wasn't lost... just incase you were interested... ;)

When simple is just not enough...

We all have felt the pain at one time or another. Yes... you know it... its that warm fuzzy time when you have to maintain someone else's code.

Generally, its difficult enough to adapt your thought process/logic to that of someone else, however, the added fun comes when the person who actually created the masterpiece of code, did it with a complete disregard to any sort of afore mentioned logic.

Now please, don't get me wrong... I don't usually go around ragging on code that someone else has done to the best of his/her ability (in this particular case lets hope, for the sake of the creator, it was the result of something closer to an alcohol induced coma as opposed to a fair reflection of said ability), but sometimes, especially at 01:20 in the morning, having to sift through what can only be described as a waste of time, I am a little less in the forgiving mood...

I believe the following sums it up:

   1: CultureInfo cuInfo = CultureInfo.CurrentCulture;

   2: NumberFormatInfo numberFormatInfo = cuInfo.NumberFormat;

   3: string strNegativeSymbol = numberFormatInfo.NegativeSign;

   4: if ((dtbContract != null) && (dtbContract.Rows.Count > 0))

   5: {

   6:     decContracRate = Convert.ToDecimal(dtbContract.Rows[0]["PayoffAmount"],

   7:                        System.Globalization.CultureInfo.InvariantCulture);

   8: }

   9:  

  10: if ((decContracRate.ToString().IndexOf(strNegativeSymbol) > -1))

  11: {

  12:     btnPrintPayment.Enabled = false;

  13:     if (btnIsVoid.Enabled == true)

  14:     {

  15:         btnIsVoid.Enabled = false;

  16:     }

  17: }

  18: else

  19: {

  20:     btnPrintPayment.Enabled = true;

  21: }

Excluding all the other issues with this code snippet, unless I am missing something extremely sneaky - I am pretty sure the following would have done the trick:

   1: if( decContractRate < 0 )

   2: {

   3:     // oh look - its a negative

   4:     ...

   5: }

Yup... sometimes simple is just not enough...