Dan Appleman is president of Desaware, the author of several Visual Basic books, including the popular Visual Basic Programmer’s Guide to the Windows API series, and a frequent speaker at Visual Basic developers’ conferences. He has been involved in the Visual Basic world since the language was first introduced in 1991, and he quickly become the prototypical VB guru. I had a chance to speak with Dan recently about VB.NET and his new book, Moving to VB.NET: Strategies, Concepts and Code, which is aimed squarely at developers who are in the same situation he found himself in when first confronted with VB.NET: staring directly at a huge change in the way applications are developed.

Dan on VB.NOT
Builder.com: I understand that you’ve been using VB since its early days. What is it about the language that initially attracted you to it?
Dan: At the time, I was developing applications for Windows using traditional C techniques. This was before MFC [Microsoft Foundation Classes], ATL [Active Template Libraries], or even, as I recall, before Microsoft had a version of C++. I installed the beta for VB 1.0 and was able to create in a few minutes an application that would have taken literally hours using existing technology.

Builder.com: So you’d consider development efficiency to be the strongest feature of the language, then?
Dan: Yes. You can’t laugh off that kind of efficiency. Even with the development of MFC and ATL, VB remained far more effective as an application development platform. With the use of API calls and selected C++ components, I didn’t have to give up the lower-level capabilities of C++. In fact, I created my company, Desaware, specifically to provide that kind of low-level access to VB programmers.

Builder.com: What’s the worst or most annoying VB feature?
Dan: Annoying? In VB6 and earlier, it would be the dialog box that comes up every time you have a syntax error in a line. The worst feature has been, without [a] doubt, the lack of strong type checking. Option Explicit was a step in the right direction. Option Strict in VB.NET finally resolves the problem, and it really should be the default for new projects. (Hear that Microsoft?)

The strong, silent type
Builder.com: You talk about weak type checking in your book, but could you elaborate a bit on why it’s such a problem?
Dan: It’s simple. Strong typing requires the programmer to make explicit any type conversion where there is the potential of a runtime error or loss of data. Presumably, this means that any time you do a conversion in your code, you are either certain that it will be successful or you add some error handling.

Without it, a responsible programmer has to figure out every place a conversion might take place and add error handling. Sometimes, a conversion can be very subtle, especially when variants or default properties are involved. It’s easy to miss conversions and, well…some programmers are less than responsible on this score.

In other words, strong typing, like Option Strict gives you, results in fewer untrapped runtime errors, which reduces the total cost of the software. Remember, the later an error is fixed, the more it costs to fix. In the case of VB.NET, where you have a choice between loose and strict type checking, you should always choose strict type checking.

Builder.com: That’s a good point, but there are many other languages in use that are more loosely typed than VB, and loose typing is usually not cited as a negative of these languages. Take Python, for example, which actually stresses loose typing as an advantageous feature. Isn’t strict typing really just a question of style?
Dan: It’s not a question of style so much as a question of economics. Loose typing does lead to subtle bugs that do not occur in strongly typed languages. These bugs may not be caught until the testing stage, or even the release stage, and the cost to fix a bug rises dramatically the further you are in the development cycle. The cost of having your developer type in a variable declaration or explicit conversion is tiny compared to the cost of testing, tracking, fixing, and verifying the fix of a bug after the initial coding.

I’m not very familiar with Python, but I just took a look at a tutorial on it and found exactly what you said: Loose type checking is stressed as an advantage. At the same time, there are all sorts of warnings about subtle, hard to find bugs that can result from typographical or conversion errors.

Now, this is not to say that VB.NET or Java is better than Python. It is possible that the total cost to develop in Python is less than those two because it has other features that outweigh the costs of loose type checking. VB6 is loosely typed compared to C++, but it’s still a better choice in most cases because the benefits of rapid development far exceed the cost of fixing and tracking the bugs that result from loose type checking.

On the journey to VB.NET
Builder.com: It’s been said before that there’s more operating VB code on the planet than any other language—a testament to its popularity (or at least to Microsoft’s marketing). What do you think is in the future for “classic” VB? Is there a potential for some kind of maintenance market?
Dan: Most people underestimate the magnitude of the transition to .NET. We’re talking about a transition that is similar in magnitude to that from DOS to Windows, or [from] 16-bit to 32-bit Windows. The cost to upgrade your software from VB6 to VB.NET will be nothing compared to the cost of training your staff on the new technology. I expect not only maintenance but new programming to take place using VB6 for at least a year or two, maybe more. Maintenance will continue for many years after that because it makes no economic sense in most cases to port existing code to .NET.

Builder.com: About that transition, the research firm Gartner has said it anticipates that as many as 33 percent of today’s VB programmers won’t be able to make the change to VB.NET for a variety of reasons. You’ve made that pilgrimage yourself. What’s your take on that statistic?
Dan: VB.NET has all the power and capability available to a .NET language, which also means that it’s just about as difficult to learn and use as any other .NET language. So there’s no doubt that there is a substantial learning curve facing VB6 programmers, and some won’t be able to make that transition, but how many is hard to say. It’s not as if there is a good alternative at this time.

One of the things that made Visual Basic so successful originally is that it made it easy to do Windows programming. Now there is a need for a truly easy language that does for .NET what VB1 did for Windows programming. Consider that a challenge to your readers.

Builder.com: What advice would you give to developers who are looking at making that change to VB.NET?
Dan: Three words: Read my book. Seriously, though, when an author writes a book, he has, or at least should have, an overriding vision of what he is trying to accomplish. My vision for Moving to VB.NET: Strategies, Concepts and Code was exactly that: What advice do I want to give developers who are moving from VB6 to .NET? What are the key things they need to know?

They need the strategies (when to switch, how to switch), the concepts (what ideas are new to VB.NET and different from VB6), and the code (specific directions on how to perform tasks in VB.NET).

Builder.com: From what I’ve seen of it so far, you are pretty close to the mark. What new things can we expect from Desaware in the near future?
Dan: The first thing you can expect is .NET-compatible versions of our current products. We’re already shipping SpyWorks 6.3 with support for subclassing and hooks with .NET. We’ll ship compliant versions of StorageTools and VersionStamper about the time of .NET’s release. Beyond that, we’re working on some cool projects but aren’t ready to announce them yet.