Visual Basic.NET or C#…Which to Choose?
By Daniel Appleman
Sample Chapter
To purchase the entire book visit http://www.desaware.com/VBorCSharp.htm
Copyright © Daniel Appleman 2001
All rights reserved
Published by MightyWords, Inc. in cooperation with Apress LP
2550 Walsh Avenue
Santa Clara, CA 95051
www.mightywords.com
ISBN 0-7173-0612-7

Table of Contents
Introduction
Let the Comparison Begin
Data and Variables
Function Syntax
Object Syntax
Other Object Oriented Features
Events
VB Commands
Other Syntax Differences
Performance
Using or Imports
Unsafe Code
Assembly Organization
Case Sensitivity
XML Documentation
Beyond Syntax
Summary of Results
Which language should you choose?
Conclusion
Introduction
Visual Basic.NET represents a major change from previous versions of Visual Basic. From VB1 to VB5, Visual Basic programmers have been able to more or less run existing applications without modification on each subsequent version. While there were occasionally bugs or quirks in the upgrade process, to a remarkable degree each version of Visual Basic was backwards compatible with its predecessor. Even the transition from 16 to 32-bit code was remarkably smooth.
This backwards compatibility does not exist with VB.NET. Yes, Visual Studio.NET does attempt to convert VB6 code to VB.NET-and does a good job of it. But the changes to the language are so fundamental that the conversion is unlikely to be perfect for all but the simplest applications. Even if it reaches a 95% conversion accuracy, that would leave 500 lines in a 10000-line program that would have to be converted and tested by hand.
In my latest book, titled Moving to VB.NET: Strategies, Concepts, and Code, I discuss at length the strategic issues of moving to .NET, and the concepts that Visual Basic programmers must understand in order to successfully develop software under .NET. The book then moves on to the specifics of the Visual Basic.NET language.
I won't attempt to cover the material of that book here. It is still very early in the history of .NET, and my Moving to VB.NET is only just published, thus I realize that you may not yet be really familiar with VB.NET-even if you have experimented with the beta version. Don't let this worry you-you won't need to be a VB.NET or C# expert to read and understand this book.
There are, however, a few key ideas that you need to know before I begin. The reasoning behind them is discussed in depth in my Moving to VB.NET book. For now, I ask you to take them on faith.
.NET Basics
The .NET framework represents a major technological shift. It is based on an underlying architecture that is radically different from what Visual Basic programmers are accustomed to. Microsoft .NET promises some significant benefits to programmers:
" Memory and code management eliminates memory leaks, thus promising improvement in reliability and scalability.
" Code management offers vastly improved security.
" The Common Language Specification (CLS) ensures that CLS compliant languages can work seamlessly with each other. They can call methods and properties written in other languages directly without complex IDL, type library, or registry based schemes.
" The .NET framework class library provides a huge base of classes and objects that are available to all .NET languages.
There are other benefits to .NET, but I'm not on the payroll of the Microsoft marketing department and thus feel no need to try to sell you on this technology. This article is about language tradeoffs, so I'll focus on issues that relate purely to language features.
The features of the .NET framework, and requirements for a language to be CLS compliant, place certain demands on every .NET language. For example: Every CLS compliant language must support single inheritance. Every CLS compliant language must support multithreading (free threading).
These demands alone mean that Visual Basic.NET would have to undergo major changes from VB6. However, it turns out that Microsoft developers, realizing they had to change the language anyway, decided to go ahead and really clean up Visual Basic. In doing so they have made many changes that most software developers with formal computer science training will be delighted to see. Strict type checking and a more consistent syntax are just two examples. But these changes also resulted in changes to the language that eliminated backward compatibility.
Visual Basic.NET is a Visual Basic-but it is not the Visual Basic that you are familiar with from previous versions.
This means that every VB6 developer faces a significant learning curve in order to become a successful VB.NET programmer. By significant, I would estimate that we are talking months to truly understand the new concepts along with the myriad of required code changes, and to gain a basic familiarity with the new runtime classes.
Which leads to the question that inspired this article:
"Since I have to learn a new language anyway, why not go ahead and learn C# instead?"
Before answering this question, let me offer a question that I believe to be equally valid that could be addressed to both VB and C++ programmers:
C# is a new language. Since learning C# means learning a new language anyway, why not learn VB.NET instead?
It is important to understand the subtle attitude behind the first question. When VB6 programmers ask "why not learn C# instead of VB.NET?", many of them are really saying this:
"I know I can do great things in Visual Basic, but still the C++ programmers I know look down at me. They make more money. They say VB is a toy language-that it is not as fast or good or powerful as C++. They point out things that can be done in C++ that can't be done in VB. Now the C++ programmers are being told that C# is the best language for .NET development, and it looks enough like C++ and Java that there is no shame in programming in C#. Since VB.NET involves learning a great deal, why not invest a bit more time and learn C# so I can be a real programmer and make as much money as they do?"
We can't discuss the technological differences between VB.NET and C# without first addressing this important human factor.
So, here are three facts that you need to know:

1. VB.NET is a fully CLS compliant language. This means it can take advantage of all of the features of the .NET runtime and environment.
2. C# offers very few language features that are not present in VB.NET, and those are unlikely to be important to the vast majority of VB programmers.
3. The fact that both languages are CLS compliant means that in the unlikely event you need a language features from C#, you can write that code in C# and use it seamlessly in your VB.NET project.
If you accept these facts, it becomes clear that it is no longer reasonable for VB programmers to feel any inferiority compared to C++ or C# programmers. In other words:

VB.NET is just as good as C# and in some ways better.
This, in turn, means that you can consider the real economic factors in choosing which language you are going to use.
Economic factors?
Yes. If the languages are technically almost the same, the economic factors become the most significant issues.

Economic Considerations in Evaluating Languages
As a professional software developer, you are almost certainly concerned with finding economic solutions to software development problems. In doing so, you consider the total life cycle cost of a software project. The following facts are always on your mind:
" Learning takes time and thus costs money.
" Using more than one language at a time requires a mental shift on the part of programmers that tends to slow coding slightly (more annoying than costly).
" It is always cheaper to correct code at development time than later in the software life cycle.
" Code that is easy to read and understand is cheaper to debug and support in the long term.
Let's consider each of these facts:
Learning takes time and thus costs money.
I think there is a presumption that it is faster for a VB6 programmer to learn VB.NET and a C++ programmer to learn C#. Personally, I spend my time divided roughly equally between VB6 and C++, so it is difficult for me to gauge. However, my sense is that this presumption is correct. This is especially true thanks to the excellent real time error checking performed by Visual Studio. In many cases it tells you exactly what to do to fix a syntax problem. This means that VB6 programmers who type in code that is familiar from VB6 will often receive specific instructions immediately on how to fix their code. The challenge for VB6 programmers moving to VB.NET is to keep in mind more subtle changes, such as integers being 32 bits and long variables 64 bits long (thus you generally prefer integers over longs), or that the default parameter passing type is ByVal instead of ByRef.
I believe that most VB6 programmers will find the VB.NET syntax faster and easier to learn than C#.
Using more than one language at a time requires a mental shift.
As accustomed as I am to using both VB6 and C++, I find myself frequently typing VB code in Visual Studio and C++ code in VB6 with obvious results. I have heard some already claim that the subtle shift between coding VB6 and VB.NET will be harder to deal with than the shift between VB6 and C# would be for those who will be using both languages at once. My own experience indicates that both are equally annoying.
It is always cheaper to correct code at development time than later in the software life cycle.
Which language does a better job of forcing you to write bug free code? Which one catches the most errors at coding and compile time? While it is certainly annoying to have to write extra code to tell the compiler that yes, you really do mean to convert from one type of variable to another, that effort has a small cost at development time, and eliminates potential bugs that could have significant costs later.
You'll find that VB.NET and C# are very similar in this area. This will be one of the criteria used to evaluate the languages as we proceed.
Code that is easy to read and understand is cheaper to debug and support in the long term.
I won't try to address this issue here. But it will be one of the major criteria used to evaluate the two languages through the rest of this article. Readability and clarity of code is strongly influenced by language syntax. In fact, given that VB.NET and C# are almost identical in terms of features, it turns out that readability and clarity become one of the single most important issues to consider when choosing between the two.