A few days ago I read an article which claimed that Visual Basic is a bad language and that C# is a good language. I also read a response. I should link to the two articles but I won’t for two reasons. First, I would have to hunt them down again. And second, I would hate anyone to believe the rubbish that was in the first article. But it isn’t too hard to find articles of this nature, just Google VB vs C# and look at the results.
The first thing to realise about both VB.NET and C# is that neither of these languages are compiled into native machine code. When you run the compiler it produces an exe file but if the .NET framework is not installed on the target machine then these programs will not run. That is because the compilers for both languages compile to what Microsoft calls Intermediate Language (IL) code. It is this IL code that is run by the by .NET framework. In this case, the framework is known as the Common Language Runtime (CLR). The reason for this is that the IL code is machine independent and will run on any device which supports the CLR.
In most cases, and I mean most with very, very few exceptions, a program written in VB.NET or C# will produce identical IL. Not similar, not almost the same, but identical. The .NET framework SDK comes with a utility called ILDASM.EXE which allows you to look inside an assembly written in any .NET language. A look inside an assembly written in VB or C# shows that they are exactly the same.
So why is there the continual war between VB and C# developers? One reason is historical. VB was, in its early days, considered by many to be a toy langauge. This despite the fact that thousands of commercial applications have been written with it. C#, which owes its origins to C, C++ and Java, is considered to be more suitable for serious programmers.
Which is best? I would like to say VB because that’s what I use. But that wouldn’t be the truth. The best language is the one that gets the job done most efficiently for the user. If you can write well in VB, then use it. If you come from a C or Java background then use C#.
One of the most compelling arguments I have read is from a developer who said he has never had a helpdesk query which complained about the language the application was written in. When a user complains it is because the program crashes, or produces incorrect results. No one complains to a telephone company about the composition of the plastic in the telephone handset. We complain when we can’t make a call.
Software developers need to remember that we are in the business of producing a product. Two words here are important. First we are in a business, so we need to adopt a business approach to producing software. That means using the tool which works best for the job. There is no point using, say, C++ if it is going to take twice as long to build and then not be able to sell it at a reasonable price just so that we can sound smug when we talk to our fellow geeks.
Second, we are marketing a product. No one, absolutely no one, cares how you built it. They only care if it works. Sometimes when I have resolved a particularly thorny issue I want to tell someone how clever I am. I can’t tell the client. He’s been flat out all day solving his own problems. I occasionally start telling my wife but very quickly her eyes glaze over and she either falls asleep or wanders off to another room. Not even my nearest and dearest care. And why should they?
But now to some specific issues. Some of these remind me of Gulliver and the problems he had in Lilliput with the Big Endians the Little Endians. The Big Endian always broke their eggs at the big end, while the Little Endians, following the decree of the Emperor broke theirs at the little end. A number of rebellions broke out over this serious matter.
C#, like all C-based languages, is case-sensitive. VB, like all Basic languages is not. Who gives a rats? Personally, I follow a naming convention which would make my variable names acceptable in either language. But I don’t do it because I get browny points for doing so. It is merely habit. But when I program in Prolog I have to follow a completely different set of rules. If I wrote in German I would capitalise nouns. So what?
Visual Basic doesn’t enforce variable declaration. This is true. However, there is an option which can be set as a default, or on a project basis, called Option Explicit. When it is on, then variables must be declared before they are used. When it is off, they need not. In earlier versions of VB the default was off. In VB.NET the default is on. My own view is that it is better to have Option Explicit on. But not because the computer scientists say so. The real reason for using Option Explicit is so that bugs become apparent at compile time rather than run time. It is usually, make that always, easier to deal with a bug if you find it at compile time. After more than 20 years of programming, and always declaring variables (when the language allows me to) then this has become a non-issue for me. But I am grateful that the compiler shows me the errors, rather than having to find them at run time.
A more thorny issue is Strict Type Checking. VB.NET has another Option and that is Option Strict. The default for this is off. One of the complaints of the C# programmers is that in VB you can perform what is known as late binding. That means that you can declare a variable, as you must if Option Explicit is turned on, but you needn’t state what type of variable it is. You may be declaring a variable which will hold an integer value, but if you don’t declare it As Integer then it is created as type object. This is known as late binding. The compiler is quite happy creating a variable of type object and it is not until run time that the general object becomes a more specific type of integer.
Some people like late binding. I avoid it at all costs. Turning Option Strict on means that all variable must be declared as a type. Like Option Explicit, even more so, this results in bugs being found at compile time rather than run time. It also takes more work. For example, when converting data types which require a narrowing conversion, for example from double to integer, a specific cast is required. You may have a variable of type double which holds an integer value. Even though a variable of type integer could hold this value you still need to cast the value to type integer, using, for example the Cint or Ctype operators.
The C programmers are correct in that it is easier to write bad code with VB than with C#, but that doesn’t mean that VB, of itself, or VB programmers, of themselves, produce sloppy code.
One of the easiest mistakes to make, at least to my mind, and some programmers may not consider it a mistake, is in the use of shared members in classes. In C languages shared functions are known as static. I am also referring here to VB subroutines, which in C languages are void functions, that is they don’t have a return value. Sometimes we create a class which has a function which we wish to use without creating an instance of the class. For example, I recently wrote a program which had to generate receipts. When a new receipt was required a function within the Receipt class generated the next receipt number. I didn’t want to use an auto-increment number for a few reasons which are not relevant here. I also wanted to generate the number before saving the data for that receipt. I created a function that produced the next receipt number within the Receipt class but called it a shared function (in C# it would have been a static function.) In C# if I had created an object and then called the static function I would have received a compile error. In VB I would not. It is easy to forget that a function you have created is shared and that it should therefore be accessed by the class not by an instance. However, I think it is good practice to access all shared members, including functions, by the class.
Finally, C#, and other programmers of the C type languages, have a reputation for getting down and dirty with the operating system in a way that VB programmers have not. There is some truth in that. Systems programming lends itself to C. I suppose that C++ is the language of choice for most systems programmers. I would not consider writing a compiler in VB. I would not consider writing a compiler at all.
But even in the VB world we use to get our hands dirty. From the time I started programming in Visual Basic back in the Version 3 days, right through to VB6, I regularly used Windows API calls. I don’t know anyone who wrote anything with any degree of complexity who didn’t. There were some things that API calls did so much better than could be accomplished with standard VB functions. And some things could only be done using the API.
Since moving to .NET I have not written one API call. I suppose one day I might have to, but so far, because VB.NET is a much richer language than previous versions I haven’t needed to. I know that some people avoided API calls like the plague. I don’t know why. They were simple enough. You look them up, type in the right declaration and you are done. But I don’t miss them. Every version of Windows has a different set of APIs. Sure there are some that stay the same, but some don’t. I no longer have to worry about that.
And C programmers no longer have to worry about memory management. VB programmers never did. I don’t think you find too many C# programmers complaining that memory management has been taken out of their hands.
So where does that leave us? As I said earlier, we are writing software to solve the problems that someone else is experiencing. So use the language which best solves the problem as efficiently as possible. As to the future – who knows. It all depends upon the paths taken by Microsoft. Where will Windows go? The newest version, previously called Longhorn and now called Vista has been released as a beta to some testers. There are mixed reactions to it. And after that, no one knows. Visual Studio 2005 has been released in beta and so far it seems that the situation regarding choice of language hasn’t changed. But again, future developments in both VB and C# could change this.
My skills in C# are not up to scratch. I can write in C# but not as profficiently as in VB. I think that I should rectify this. I am not likely to make the change to all C#, but I think it would be a good idea to become more fluent in the language. I have a small project that I need to get started on. I think I might write it in C# and see how it goes.
For those of you who are thinking of getting a program written don’t make your choice on the language used by the developer. Your criteria should be the same as when you buy any other product. Who gan get it to me the quickest, and the cheapest, but still have it perform as I want.