Datasheet
and plenty of Visual Basic developers who will tell you at length what’s wrong with C# and C++. When
you use a language extensively, that’s the one you find most natural, and anything else seems strange.
If you speak to developers who have used several languages extensively, you’ll generally get a very dif-
ferent response. These developers tend to say that most languages do pretty much the same thing, just in
different ways, and the choice isn’t that big a deal. In particular, I know a lot of programmers who have
used both Visual Basic and C# for several years and they agree that the languages are practically identi-
cal. Many have a personal preference, but very few people with a lot of experience claim that one lan-
guage is clearly superior to all others in all situations.
During my career, I’ve used quite a few languages, including Pascal, assembly, FORTRAN, C, C++, Delphi,
PostScript (many developers don’t even know it’s a programming language), some graphics programming
languages, various flavors of BASIC, and an assortment of Visual Basic versions such as VBA, VBScript,
and Visual Basic versions 3 through 2005. Each of these languages has its strengths and weaknesses.
Disadvantages
The following section describes some of the most common objections raised against Visual Basic and
explains whether these are real, significant objections; a problem that is easy to work around; or merely a
matter of perception.
Interpreted, Not Compiled
Visual Basic does not produce a compiled executable. Instead it produces Intermediate Language (IL)
code that is interpreted at run-time by the Command Language Runtime (CLR). This has a couple of
important consequences.
First, interpreting code reduces execution speed. Visual Basic uses a just-in-time (JIT) compiler so after a
program has executed a piece of code, it should be compiled and run at faster speeds later. However,
running the code the first time will still be a bit slower than it will be in a truly compiled language.
Second, a computer must have the CLR and the .NET Framework installed to interpret the Visual Basic
program’s IL code. These not only increase the installation complexity, but they are also quite large
and getting larger with each new release. Whereas the Visual Basic 6 run-time libraries took about
1MB compressed, the .NET Framework 2.0 needed to run Visual Basic 2005 programs weighs in at
22.4MB compressed, and expands to 280MB of disk space when installed (610MB if you’re running
64-bit Windows).
Third, IL code is relatively easy to read, so even distributed as an “executable,” a Visual Basic or C#
application is relatively easy to reverse-engineer. Code obfuscators that rearrange code, rename variables
so they are harder to understand, and so forth are available, but the result is still easier to read than a
compiled executable.
Lutz Roeder’s excellent “Reflector for .NET” program allows you to easily view IL code for .NET
assemblies written in Visual Basic, C#, C++, IL, Delphi, and Chrome. It will even display code in those
4
Part I: Design
05_053416 ch01.qxd 1/2/07 6:28 PM Page 4