I wrote the following article a long time ago on my main domain, but recently I had a reader send in a question that this article addresses. So I’m putting this article here so that it is easier for readers to find in the future….
In the past, when you selected a language, you were selecting an application programming interface (API) as well. So if you decided to use C++, you automatically were selecting the MFC class libraries as well as ATL and STL. You don’t really need to know what these initials stand for, just understand they represent a complete set of functionality that did not have to be written by the programmer.
If you selected VB, you got a complete set of functionality for that as well. Perl has its set, Pascal its set and so on.
When Microsoft initially introduced Windows 3.1, the attraction to it was the fact that Microsoft was not only going to supply a graphical user interface that we could all write programs for, but it was going to give us a common set of functions that every language could code against. So, you might be thinking, what happened?
Well, right after Windows 3.1 was released, object-oriented and object-based programming became popular and completely superseded what is known as the Win32 API.
Life has gone along with every language vendor creating their own API that wraps the Win32 API ever since. That is, up until .NET was released.
When Microsoft created .NET, they had several goals. One of those was to create a common programming platform that every language could use without having to wrap it in another layer of programming interfaces. To understand this, you have to understand what .NET is.
.NET is more than a programming environment. .NET is a common language runtime environment (CLR) that executes code in a Class library using a technology called Intermediate Language (IL or MSIL). Code written for .NET is compiled to Intermediate Language. IL is platform agnostic code. When it is first run, the CLR compiles the code down to binary code for the computer it is running on. This makes it possible to have code that has been optimized for whatever computer it is running on. It also makes it possible (though not completely supported right now) to have .NET code that runs on Linux, Mac, or Windows.
What Language is Best?
Ever since .NET was officially released, there has been an ongoing debate as to which of the two languages, VB.NET or CSharp, is the best. And frankly, it is my belief that an argument about which language is best is like asking if Coke or Pepsi is the better drink. Both languages have their place, but depending on the environment you are working in, one may be better than the other for you.
So let’s start by looking at the syntactical differences. VB.NET is a very wordy language. First you have to tell it what you are going to do and then you have to write code that does what you told it you were going to do. CSharp, on the other hand, is a context-sensitive language. That is, it does whatever you wrote. It assumes you are smart enough to mean what you say the first time. The advantage to using VB.NET is that is practically impossible to write an application that does not do what you expected only because you typed something incorrectly in the code. The disadvantage is that you have to write a lot of code. The truth of the matter is that when you use a language such as CSharp, there are enough built in protections with that language that, when combined with well thought out coding conventions, also make it hard to write bad code.
VB.NET is a case-insensitive language. This means that if I create a variable named m_firstName and then later on spell it as m_FirstName, the compiler will treat both the same. In point of fact, this rarely happens because the development environment will autocorrect the variable in the future based on how you spelled it the first time. The advantage here is that you can’t accidentally write code using two different variables when you mean for them to be the same. CSharp is a case-sensitive language. What this means is that each of the two variable names will create two separate variables. While this sounds like it may be a problem, most shops have coding standards for how variables will be named that include how they will be cased. As long as everyone follows the rules, you should be OK. Also, in CSharp, you can create a method named FirstName() and a variable named firstName and the compiler can deal with it. There are times when this is a very handy feature. In VB you’d have to break naming conventions to work around the case sensitivity issue. There are advantages and disadvantages to both.
Object Oriented Advantages
Both languages can write object-oriented code, but VB.NET will let you write procedural code if you want to. For you to understand why being able to write procedural code is a bad thing, you have to understand what is so good about writing object-oriented code.
In the past, when programmers sat down with clients to write applications using any kind of formal process, the process always involved the programmer trying to get the client to think like a programmer. Most people are at least familiar with flow charts, those diagrams with circles, diamonds and lines on them. The biggest problem with flow charts is that they are really programs that use pictures instead of words. Try to get your average client to look at one of those without going to sleep on you!
Another popular method, one that actually seemed to work for a while, was a method called Data Flow Diagrams. This method diagrammed how data flows through a system. This worked well in the early days of programming while we were still moving existing manual systems, like accounting processes, over to the computer. This is because we had data moving through the system. “I take this report over to Joe” represents data flowing.
But now we’ve moved way beyond converting manual systems. Most of the applications we create now have no existing manual counterpart. If data flows, the end user never sees it. So even if you are working with an existing system that is on the computer, the concept of data, let alone data flowing, tends to be completely lost on the client.
Enter object-oriented programming. In an object-oriented system, our main unit of code is the class and all classes are named with noun names. So when a developer is talking to a client about the system he is tasked to build, he’s just going to sit down and talk with that client about the client’s application. Every time the client says a noun (Invoice, Newsletter, Location Map, etc.) the developer can make a note of it as a possible class in the new system. When the developer needs to know more about how something works, he can go back to the client and say something like, “You said there was this thing called an ‘Invoice’ in the system. Could you tell me a bit more about how that works?” To which he would probably respond with something about a billing address, a shipping address, some line items, etc. This creates more nouns for your system and therefore more class possibilities. And not once did you have to say anything about code.
There are some other advantages for the programmer as well. By using concepts such as inheritance and polymorphism, the developer can reuse code to an extent he could only dream about using procedural methods. For example, using procedural code, I might write a function that worked real well. A few weeks later, I would realize that I need that exact same function except for one line of code. If I could just change that line of code, life would be grand. So what most programmers do in that situation is copy, paste, and modify. So now if the main code needs to be changed, I have two functions I have to modify. And we all know what the likelihood is that we are going to remember to change both functions when they need to be changed. The object-oriented concept of polymorphism addresses this issue in a way that you have all of the common code in one function and only the code that changes is in separate functions.
So when you are writing a .NET application, the ideal would be that you never write a line of procedural code. However, most programmers prefer to use what they know. Even if they are using a different tool, they want to make the new tool work like the old tool. The danger of using VB.NET is that the developer is likely to resort to what he knows best and will write procedural code in a VB module like he used to do in the old days. Just because he can, doesn’t mean he will. A programming shop that knows the difference will create a “No Modules” rule as part of their coding standards.
Back when the programming community was moving from C to C++ (procedural to object oriented) we had a similar problem. Microsoft introduced Visual C++ and all of the C programmers moved to it instantly. But, following the rule that programmers always want to use today’s tool like they used yesterday’s tool, only about 20% of the C programmers were really able to make the adjustment. Most programmers making the move were writing C code using C++ syntax. They didn’t understand object-oriented programming concepts and could not make the change. The really scary thing about all of this is that you can write code that works using procedural concepts and object-oriented languages. The real problems don’t show up until you try to fix bugs or add features six months later.
While it was true in the past that writing code in one language would give you better performance, the truth is that since both languages compile down to the same IL code, there is no performance advantage at all between VB.NET and CSharp.
In fact, from a purely technical perspective, there is absolutely no advantage to using either VB.NET or CSharp. They both allow you to write the same quality object-oriented code.
So, since both languages allow you to write equivalent code, the only reason for choosing one language over another is purely for practical reasons.
For example, CSharp looks a lot like C/C++ or Java. So if you already know those languages, you are going to be a lot more likely to use CSharp. This was the case when I learned .NET. I have a hard time remembering that the semicolon is not connected to the Enter key on the keyboard when I do write VB code.
On the other hand, if you already know VB6, you are probably going to be more comfortable with VB.NET. However, since I’ve used both VB6 and VB.NET I can tell you that there are enough differences between the two languages that if you decide to write your code in VB.NET, you are much better off thinking of VB.NET as a new language rather than thinking of it as VB7.
As a teacher for a training company, I have seen quite a few VB6 programmers come to my classroom for CSharp training. The most common reason given is that they realized that VB.NET was so different from VB6, they decided it would be better to learn a new language than it would be to try to break old habits.
The second most common reason for moving to CSharp even though they know VB6 is that they’ve looked around the web and discovered that most of the demos that are available are available in CSharp. And while some are available in both languages, if a demo is written in only one language, it is a lot more likely to be in CSharp than it is to be in VB.NET.
When .NET was first introduced I had a discussion with a business owner who was responsible for hiring consultants. He asked, “If you were going to hire a .NET programmer, who would you hire?” Remember the premise here is that he has no experience in .NET because, at the time, no one did. In my mind, the answer was easy. I’d first try to look for someone with prior C++ experience, and if I could not find a C++ programmer, I’d start looking for a Java programmer. Someone who knew both would be ideal. Why? Because these guys already, presumably, have learned how to program in an object-oriented world. All they need to learn is syntax.
While it is possible to write good object-oriented code in VB.NET, you are much more likely to write good object-oriented code if you use CSharp, not because the language is any better but because of the thought process it will encourage in the programmer. Since CSharp does not allow modules, CSharp demands that the programmer think in an object-oriented manner. Even though it is possible to write the same code in VB.NET, the VB.NET programmer could, when the going gets tough and deadlines have to be met, fall back to his old habits. It may take longer for him to be as productive as a guy using VB.NET, but he will avoid many of the pitfalls his peers will fall into by staying with VB, and in the long run he will be more productive not only during the development of initial products but, more importantly, while he is fixing bugs and implementing changes to the code.