VB.NET vs C#, round two
I saw on Dan Appleman's blog that a new version of his Visual Basic.NET or C#…Which to Choose? is available, reflecting the latest changes in VS.NET 2005. I immediately bought a copy from Lockergnome, apparently the only vendor that allows instant eBook downloads after purchase.*
There are no dramatic reversals of fortune here. As usual, it's all about the runtime. However, I was disappointed that Dan didn't cover the way his prediction in the original eBook has come true-- as nonsensical as it may seem, C# developers are paid more than VB.Net developers to write the very same .NET framework code. This isn't conjecture. It's a fact. Well, at least we can console ourselves with the many dramatic improvements in VB.NET; the language is legitimately a first class citizen in VS.NET 2005. Microsoft finally rectified all those annoying, boneheaded oversights-- compiler warnings, Using, and XML comments anyone?
I'm also wondering if, despite protests to the contrary..
The focus on languages over the past couple of years has truly astonished me. For example: at technical conferences you still often see separate VB .NET and C# tracks. Publishers would publish one book on a general .NET topic in C#, then a "port" of the book to VB .NET (or vice versa). Bookstores still classify books by language.Don't get me wrong – it's not that the conference organizers and publishers were wrong to do this. They just deliver what they believe the market demands. Or, to put it bluntly, the existence of separate VB .NET and C# content is largely an indication that publishers, bookstores and conference organizers believe their customers are too stupid to realize the fundamental truth – that it's all about the framework. The language does not matter.
If you look at the total knowledge space of developing .NET applications in VB.NET or C#, about 95-99% of the information is identical between the two languages. This is a radical shift from the Visual Studio 6, where C++ programmers had MFC and ATL available -- two massive frameworks that VB6 programmers did not need to learn. At this point, the truth is that I could take the easy way out and simply say that the two languages are so similar that you should just choose whichever one you feel like -- it won't matter. But, this would be a cop-out -- like the kind of contests some schools do for kids where every participant wins a prize in order to build their self-esteem.
.. perhaps the choice of language is more significant than Dan realizes, due to his unusual dual C++ / VB background.
I, on the other hand, grew up with Basic. I don't enjoy parsing through C# code, and any C# code I plan to incorporate into my own projects, I always convert to VB.Net. I don't convert code because I feel morally obligated to; I do it because I feel like I don't really understand the code unless I've touched every line of it. I'm sure many C# developers who grew up with C or Java probably do the same thing. It's not that we can't use both languages interchangably, or understand each other, but the mental overhead of putting on different language hats sure as hell isn't helping us get work done.
In other ways, though, the choice of language really is a red herring. I'm starting to think the effectiveness of your IDE is more important than any language choice you can make. Here are the four items Dan lists as "significant issues" in choice of language:
- Background Compilation vs. Parser
- Migrating Existing Code
- Edit and Contine
- Refactoring
What do any of these things have to do with the languge? They smell like hardcore, low-level IDE features to me. The real money play is to invest in the IDE, not the languages. A kick-ass IDE will have a huge impact on your productivity compared to the utterly meaningless choice between editing VB.NET or C# in notepad.
* What is up with that? If I wanted to wait, I wouldn't be buying eBooks. Give me instant gratification, or give me death!