Why I like VB.Net over C#

... and why maybe I should switch to C# after all.

Technical people are known for their 'religious wars': Windows vs linux, Emacs vs vi, and of course C vs VB.  I am a rarity among programmers:  one who has switched sides from the C curly brace camp to the VB.Net camp.  I hear about the reverse situation all the time: VB6 programmers who were forced to learn C# when .Net came along and never looked back.  That doesn't even take into account the countless programmers who learn one style first and continue to prefer that style for their entire careers.  But I started out with C++, and in the end decided I like the VB-ish syntax.  Why?  Here are a few of the reasons I feel more comfortable with VB today:

1. Case Sensitivity.  VB is not case sensitive.  I will never have to worry about a mis-placed shift key breaking my program.  This isn't to say that VB is not case-aware.  If that were true I would probably prefer C#.  Instead the compiler takes note of the case used when you create a variable and will automatically format any further use of the variable to match that case.  This helps spot typos as you write code, and is a real help for someone like me who makes typos frequently.  To clarify, it's not that I prefer case-insensitive code.  What I like is that IDE removes the need to care about case at all.
2. That brings me to the next feature:  Background Compilation.  This really annoys some people, but I like it a lot.  It provides instant feedback on what you're working on.  I think perhaps this feature has to work with your coding style. It would be annoying indeed if you tend to write a lot of code that's just wrong until you add the final curly brace at the last moment.  But that isn't me.
3. Declaring new objects.  In C#, if you want to declare and instantiate a new object you have to key the type name twice:
   LongTypeName myVariable = new LongTypeName();
   It's even worse if there's a namespace in there, which leads C# programmers to import a dozen namespaces at the top of each code file, even if they're only using one instance of one class in the namespace.   I rarely need more than three of four namespaces, myself.  VB's "Dim" is annoying at times, but for this scenario it results in much cleaner syntax.
4. Implicit Casting.  There's a fine line to walk with this one.  I don't like implicit casting from one type to another.  But I do like implicit casting from child or parent objects to the actual type.  In otherwords, if you could use DirectCast() in VB, the implicit cast is probably okay.  The usually implies the target of the cast is part of the same inheritance tree as the source of the cast.  An important addition to that general rule is implicitly calling an object's .ToString() method, which VB will also do for you automatically.
5. End vs }.  When I was learning C++, } was just another part of the language.  You never even notice it.  Even when I first learned VB.Net I didn't really know what was I missing at first.  But it's just like getting a bigger monitor or a scroll wheel for your mouse.  You don't notice the improvement until you've used it for a while, and then also need to go back to a system without the new feature.  Only then will you be painfully aware of the short-coming.  Many C-style programmers actually scoff at End If, End While, End Sub, and so on.  But they've never used it.  Give it a chance, and trust me, it will grow on you.  I think there are two reasons I prefer this.  One is that it many curly-brace programmers give the opening brace a line to itself, meaning the End-style syntax saves you a line of code.  That's not really a big deal, but the other is that the End style syntax specifies the type of block that is ending and the compiler enforces it.  This makes matching the opening and closing of blocks much simpler and less error-prone.
6. Optional Parameters.  This one is real simple.  C++ has optional parameters.  Heck, even C has them (of a sort).  Why doesn't C#?
   

So there you have it.  Six reasons I prefer VB.Net over C#.  But let's take a closer look.  Two are IDE features rather than language features. One goes away completely in .Net 3.  Another can be mostly fixed by just adding a quick comment (though not quite). The only items here that C# won't address to some degree is implicit casting and optional parameters, and if you want to use Option Explicit (which in many cases I do) the casting issue isn't relevant at all.  Let me elaborate on each of the others:

Case-awareness as I described it is a service provided by the IDE, not a feature of the language.  I could write VB code in notepad with mis-matched cases and it would still compile.  I can envision an equally useful feature for C# that allows me to type in all lower case, and if it recognizes that I've typed a variable or class name with the wrong case it corrects if for me.  If there's a more than one variable with that name (ie, they differ only by the case of the letters), then it prompts me with a list.  I would prefer that even over VB's style.  Visual Studio almost already does this for C#, but in my opinion it doesn't get the implementation quite right.  There's also no reason Visual Studio couldn't implement a background compilation method for C# that simply doesn't report certain errors until the programmer has a chance to fix it (like later adding the ending brace or semi-colon, etc).  So this, too, is more a service provided by the IDE than truly a part of the language.

C# 3.0 adds a new var keyword that works like VB's Dim for easier object declarations.  Don't be confused though; var is really a misnomer in C#-- it's not a variant type at all.  It's just a promise to the compiler that, "Yes, I will give this variable a type.  I just don't want to yet."  The type of a C# var is fixed by the compiler; it's just not fixed until you actually assign an object to it.  So now you can have code that looks like this, with no requirement to double-enter the type name:
var myVariable = new LongTypeName();
The disassembly for that code is identical to my earlier example.  Doesn't that look a lot like VB?

This leaves implicit casting and the End syntax.  I've already touched on implicit casting, and you can partially emulate End syntax by adding a comment to lines with a closing brace.  The compiler still won't enforce the type of block, and you still have to deal with Visual Studio automatically creating files with about 5 ending braces all together by default, but once the code and comments are correct it's an improvement to anyone who tries to read it later.  

So should I switch?  Well, that depends.  Let's look at what I would gain.  For my trouble, I'd get yield break/yield return and anonymous delegates.  I'd also get access to unsafe code, and maybe a few other things as well that I don't really care that much about.  On the other hand, I'd be giving up a few things I like.  Note that there's no fix in C# at all for the the case-awareness feature yet.  There are no optional parameters either, but since my VB code often ends up in a library that might be called by a C# program I need to avoid those anyway.  Even what I'd gain mostly isn't available in .Net 2.0, which we'll be using where I work for some time to come.  Hopefully a hypothetical Visual Studio 2010 will address my remaining concerns, and maybe the office will actually switch to it.  I look forward to that day.

Until then, I'm happy with VB.Net.