I know I shouldn't let this sort of thing bother me...

…but it does.

It’s crap like this that just further influences peoples negative view of a language they know nothing about. I’m all for freedom of speech/expression. I strongly believe people are entitled to their opinion. However, if this opinion is based on false information, I feel it is the responsibility of others to help deter this type of half-baked opinion from spreading among others that aren’t “in the know”. Some people come across as being an expert flaunting a certain level of confidence that suggests they know what they are talking about. So, since I feel it is my duty to do my part in this battle, lemme pick something completely random from the article. Really, there’s so much to choose from. Where do I start? How about…

“C# is one step ahead in language features, and probably will remain so. Currently C# supports operator overloading, which VB won’t support until the next release. The next version C# will support generics, anonymous methods and partial types. These will not all be in the next version of VB.”

Hmmm… that’s somewhat subjective. However, let’s dig in and break it down.

C# is one step ahead in language features, …

First, what exactly defines features that are “ahead”? Ummm… how about OO? Is there something that C# does that VB does a bit “better”? Let’s look at the following example:

public class ClassA
{
 public short SomeMethod(short value)
 {
   return 0;
 }
}

public class ClassB: ClassA
{
  public int SomeMethod(int value)
 {
   return -1;
 }
 public long SomeMethod(long value)
 {
   return 1;
 }
}

And use the following code to call upon SomeMethod in the derived class:

ClassB cb = new ClassB();
short v = 100;
Console.WriteLine(cb.SomeMethod(v).ToString());
Console.ReadLine();

First question: What value should be displayed in the console window upon completion, -1, 0 or 1?

Now, let’s look at the same code in VB.

Public Class ClassA
 Public Function SomeMethod(ByVal value As Short) As Short
   Return 0
 End Function
End Class

Public Class ClassB
  Inherits ClassA
  Public Overloads Function SomeMethod(ByVal value As Integer) As Integer
    Return -1
  End Function
  Public Overloads Function SomeMethod(ByVal value As Long) As Long
    Return 1
  End Function
End Class

Dim cb As New ClassB
Dim v As Short = 100
Console.WriteLine(cb.SomeMethod(v).ToString)
Console.ReadLine()

Now let’s look at “language features”. First, VB requires that you explicitly state that the derived classes SomeMethod is overloaded from the base class. The C# code doesn’t force this (although you could add it). To me, that makes it so it’s very clear that there’s something called SomeMethod in the base class that I should probably be concerned about. If you look at ClassB in C#, there’s nothing to indicate such. I’d consider that a language feature is is “more advanced” than C#. Next, I don’t have to repeat ClassB twice when I instantiate it. I could write it as:

Dim cb As ClassB = New ClassB()

But why should I have to? VB has TWO ways to do the same thing. Does that make it any less advanced? Giving choices to the developer allowing them to develop based on their own style and preference? Sounds somewhat advanced to me.

OK, now to the meat of this example. When you execute the VB version, something VERY different happens. The implementation of how overloaded methods are handled in derived classes between the two languages is very different from one another.

If you haven’t run either of these examples… the answer written to the console is -1 for the C# version and 0 for the VB version. But how can this be? The code is identical. VB took the approach of flattening the overloaded methods prior to comparing the signatures in order to identify which overload would be the most appropriate. C# took the easy way out (in my opinion) and compares the signature(s) in the derived class first. If it finds one that is acceptable (short fits inside of an int), then it will use the first one it finds. If it doesn’t find an acceptable one, it then will progress to the base class.

How does that make C# and it’s language features more advanced? To me, that sounds less advanced and doesn’t even do what you are expecting it to do.

Oh.. I hear what your thinking… that’s just one example. OK, how about another.

Rather than go into complete detail on this example, please read what Jason Bock points out in regards to interfaces:

“This is one feature of VB .NET that C# does not have in that you can have one method handle a number of interface definitions. So long as the parameters and return type are the same, it doesn’t matter what the name of the interface method is. Unfortunately, C# doesn’t do this, and when I translate this code via the Reflector+FileGenerator technique, you can see that the results yield code that does not compile:”

Like I said, this is just one random piece chosen from the “article”. But wait, there’s more. Let’s continue on with the quote.

“Currently C# supports operator overloading, which VB won’t support until the next release.”

This is true. With the current version of VB, you have to resort to using op_Addition style methods instead of leveraging the overloaded operator. VB 2005 is getting this feature and Beta 2 was released just this weekend.

“The next version C# will support generics, anonymous methods and partial types. These will not all be in the next version of VB.”

Now to be fair, the author does state that “will not all”, but the reader could easily misinterpret the message because the author is not clear as to what and, more importantly, will not be included in the next version of VB. The next version WILL have full support generics and partial types. Anonymous methods are cool, but really just don’t fit within the language design of VB (in my opinion). At least I don’t see how they fit. This doesn’t mean VB is any less advanced than C#.

How about something else random from the article:

“VB supports the legacy VB functions, with reference to Microsoft.VisualBasic.dll. Many of these functions are slow and should all be avoided in favor of the .NET framework. However many VB programmers still use them. In new VB projects, this dangerous namespace is included by default.”

Well, for my opinion on this subject, you can read more here. However, to quote someone from Microsoft:

“The .NET Framework class libraries contain functions and subroutines designed specifically for Visual Basic .NET programmers. These methods provide functionality not found in other places in the Framework, or they provide functionality that is compatible with previous versions of Visual Basic. Although they are designed for Visual Basic .NET programmers, they are usable by any language supported on the .NET Framework and are considered part of the Framework. They will always be available anywhere the .NET Framework is installed.” – Paul Vick, The Visual Basic .NET Programming Language

Now, Paul does state that some methods are there for reasons of compatibility with previous versions of VB. However, I don’t see a definitive list anywhere outline which ones are, and more importantly, are not there purely for the sake of compatibility. Why should they all be avoided? What defines something as being “slow”? I know of a methods that are actually faster than the System namespace counterparts. And what exactly makes using this namespace “dangerous”?

I could continue on with many, many, many more examples; but suffice to say this is the exact behavior that deters me from contributing anything worthwhile to CodeProject. CodeProject states they want to welcome the VB developer. Even their newsletter now puts VB.NET items at the top of the list. However, “articles” like this and the behavior of the users of the site are what turn me off. It wouldn’t be so bad if the information was factual. Not only does the author admit that it’s not factual (more of a sports writeup style of writing). What’s sad is that the premise of the article had promise, but quickly diminished into yet another anti-VB/pro-C# dribble full of misinformation and, dare I say, discrimination. But don’t take my word for it, go read it for yourself and suffer the pain I endured. ;-)