Datasheet

Another consequence of the IL is that a Visual Basic .NET application requires a 280MB run-time library.
Even in today’s environment of cheap hard drives, that’s a lot of disk space. More important, however, is
that downloading such a large library takes a long time. That will prevent many users with only casual
interest from downloading your application from the Internet, particularly users with slower network
connections. Once customers have installed one .NET application, the run-time library will already be
installed so they won’t need to download it again. However, the first installation can be painful.
Visual Basic’s interpreted nature also lets developers read IL code relatively easily. That makes it much
simpler to reverse-engineer Visual Basic or C# applications to either steal useful code or exploit weak-
nesses in the code. Obfusticators can make code much more difficult to read, but not as hard as truly
compiled code.
Finally, many C, C++, and C# developers complain about Visual Basic’s verbosity. You can reasonably
argue that this is a matter of personal preference, but I claim it’s something more. Extra verbosity makes
the language more readable, and that’s absolutely crucial for debugging and maintaining any complex
application. You can add extra comments to C++ or C# code to make it more maintainable, but Visual
Basic has extra help built in. That leads to the most important concept in this book:
Programs are written for people, not computers.
If you were writing only for the computer, you would use 0s and 1s, or at least some form of assembly
language rather than a high-level language. The computer doesn’t care what language you use. It’s all 0s
and 1s when the CPU executes it. The reason you use a high-level language is to make programming,
understanding, debugging, and maintaining the code easier for people. Any feature that makes the code
easier for a human to read and understand gives you an advantage that you should not lightly throw
away in the name of conciseness.
Taking all of these factors into account, you need to decide whether Visual Basic is the right language for
your application. Performance and capability are critical issues far less often than the ability of program-
mers to write, debug, and maintain the code, so Visual Basic makes an excellent choice.
Once you’ve picked a programming language, whether it is Visual Basic or something else, you’re still
not ready to start writing code. There are plenty of other tasks that you should perform before starting to
build any non-trivial application. Chapter 2, “Lifecycle Methodologies,” discusses different patterns for
bringing a project through to produce a finished application. The chapters after that one describe other
pre-coding design and development activities that you should study before you get down to the serious
business of programming. If you stint on these phases, you may start coding sooner, but you may later
pay a huge price when you need to debug and maintain the application.
13
Chapter 1: Language Selection
05_053416 ch01.qxd 1/2/07 6:28 PM Page 13