What's New
Q & A
Tip Jar
C# Helper...
Follow VBHelper on Twitter
MSDN Visual Basic Community
  Book Review: VB.Net the Product  


By Fred Thorlin

Microsoft has released several Beta versions of its new developers' environment, Visual Studio.Net, VS.Net, now scheduled for a Feb. 13 release. It includes several new languages, e.g. C# and Visual Basic.Net, VB.Net. C# is being positioned as the best of C++ and VB combined -- a good description since every discussion I have seen involving the two languages has required the speaker to pause at least once to get straight which language he is discussing, reading or writing.

VB.Net introduces several new capabilities I am keen on using:

  • Multi-threading - The ability, with control, and without deceiving the environment, to have multiple execution streams in a single process.
  • Web Forms - The ability to create Internet web pages with VB.Net the way VB now creates forms.
  • Variable initialization in declarations
  • Improved error handling

With this release VB becomes a "truly Object Oriented language" by the addition of true inheritance. If you are a real programmer, this is sufficient grounds for you to drop this magazine and race out and buy a copy of Visual Studio.NET. Having acquired some experience with the system, I recommend a more measured pace. In the face of all of this wonderfulness though, you deserve an explanation of my apprehensions.

First, a little background is appropriate. At the end of 1990 I was developing a Windows application. C was the only Windows programming language then. The best available way to learn how to write programs for Windows was reading the 944 pages of Charles Petzold's Programming Windows: The Microsoft Guide to Writing Applications for Windows 3. After only a few hundred pages you could create. (The book has since grown to almost 1500 pages.) Sorry, Charles, but it was boring. I wanted to get a program out without having to suffer through the banalities of the inner workings of the operating system. I had been programming for 30 years and having to exert that much effort to get out a simple application was beyond digestion.

At the dawn of 1991 I was talking to an old friend and lamenting the situation. He suggested I try an unreleased product he had been working with called Thunder. It was instant true love. With Thunder I could produce the standard "Hello, World!" program in under a minute. I needed to do some study, but nothing like what I had been facing. A few months later Thunder was officially released under the name Visual Basic. I took the plunge big-time by starting a VB SIG and writing monthly columns on VB topics. I had a standard comeback to my C programming friends who disdained VB:

Question: "What is the speed difference between C and VB?"

Answer: "About six months!"

VB took off like a rocket. As I recall Microsoft's most recent statement on the subject was that they have sold six times as many copies of VB as they have of C and C++. As you can imagine the C developers felt frustrated by this. Doubtless they were insulted when their management suggested they become more VB like. They seemed to be going down this road... until .Net. It appears that Microsoft's academically correct, religiously object oriented, market disconnected, C++ language developers managed to bulldoze Microsoft's new CEO, Steve Ballmer, into merging VB into the more PC C++ path, aka C#. Their old CEO, Bill Gates, probably would have said "Hell, No! Look at the sales figures. VB must be doing something better than C."

For actual quotes, as well as the inside story on the inner politics of Microsoft product development, I recommend David Bank's recently released Breaking Windows. Investors and programmers will find the anecdotes, insights and quotes useful and enlightening. Two examples:

  • In discussing problems with getting managers to accept direction Gates remarks, "Something happens to a guy when his net worth passes $100 million.", pg. 78
  • In a discussion of the .Net strategy, "It was no joke that Gates was far from being the chief architect of the new strategy.", pg. 222.

I bring up these items because Bill was a driver of the original VB. Were he still in control, I don't believe he would have let this product get so far removed from its raison d'etre of convenience programming. Perhaps it is a sign of a "techie" company "maturing" from leadership by a Renaissance man to being led by a Music Man. VB.Net shows few signs of even being related to VB. It is no longer an unrepentant convenience programming language. It is not an evolutionary descendant of earlier versions of VB. It is a variant of C# and brings with it much of the same pains of developing I encountered while programming with Understanding Windows ten years ago.

I had a few more revelations while exploring the Visual Studio.Net plan:

  • It's different. I have taught several VB courses. As usual we would start with the Print "Hello, World!" program. In VB.Net it must be coded differently. Early in the class I spend a lot of time having students make changes to a simple single line program, Line -(X,Y), which draws a line on the initial form to the current mouse position. In VB.Net it doesn't work. The automatic VB6 to VB.Net utility chokes on the conversion. Working in VS.Net with an experienced C++ programmer it took about twenty minutes to create something similar to the original VB in VB.Net.
  • A little testing shows no serious optimization in the code. Benchmarking showed neither common sub expression elimination nor constant folding. When you ask Microsoft about this, they will insist that C#, VB.Net and the other VS languages all run at the same speed because they all use the same CLR, Common Language Runtime. This answer is not responsive to the question, (and it's wrong), and it is so uniformly delivered that it must have been taught.
  • VB.Net, as well as the rest of VS and the programs they create, do not run under Windows 98 or Windows Me. You mean you, your friends, your customers and your company haven't updated yet? They can run your programs as server-based applications though.
  • All programs created with VS.Net require the CLR that is primarily available with VS.Net or the server products. It is not included with Widows XP This execution library is so large that Microsoft does not encourage distributing it. It will be included in some TBD future version of the operating system. In other words don't write desktop resident applications to be sold or shared in this system now. Its function is to write server based applications. Isn't this the old "thin client" strategy advocated by Novell a few years ago and derided by Microsoft? Are we being nudged, or railroaded, down the path to server based application? Some day we'll be able to run Microsoft Office only across the Internet, while renting it by the month.
  • I've talked to some other people who have worked in VB6 and VB.Net, and the consensus is that VB.Net is harder, substantially harder. I get a lot of calls from people wanting to know if they should get into VB.Net. If you are already facile in VB6 and are looking for something to do with your free time in the evenings, go ahead; there are a lot of cool features there. If your customer wants it, why are you calling me? If you want to learn the latest and greatest and not waste your time on a soon-to-be-obsoleted, by Microsoft, language, or if you want to develop an application for market, answering gets more complicated.

VS.Net is an interesting product with many desirable features. Unfortunately it abandons the principles of convenience programming that made VB so popular in the first place. Microsoft is into self-deception judging by their protestations that VB.Net is on some natural development path from VB6. I hope that VB.Net doesn't mark the end of convenience programming from Microsoft, but it may provide an opening for a competitor to take over a proven, large market. Bill, where are you when we need you?

Fred Thorlin is a contract software developer with experience in compiler development now working with Visual Basic and Palm computer environments. He also writes columns on Visual Basic programming and computing on the road. He can be contacted at fredt@hal-pc.org.


Copyright © 1997-2010 Rocky Mountain Computer Consulting, Inc.   All rights reserved.