My Experiences With VB

This article was originally hosted by Apress, and it was written 06.15.2001. I found it archived here.

It all started in 1995 for me. I had just finished up my Master's thesis in multiple-precision arithmetic algorithms where all of the coding was done in C. I got a job with a publishing company in Wisconsin, where I was assigned to finish development on and maintain a program written in VB. Now a majority of my experience had been in C, and I really hadn't done a lot of other programming. I didn't want to be an electrical engineer—writing my thesis had given me a love for programming—so, needless to say, despite my enthusiasm, I realized I was heading into unknown territory.

That project, which was the focal point of my work life for the entire year and a half that I spent with the company, was extremely educational. I learned a lot about what you should and shouldn't do in software development such as:

• Don't call event procedures from other event procedures
• Avoid globals at all costs
• Be very careful when using the LostFocus() and Change() events in text boxes
• And, above everything else, spend time designing the application (those who maintain it will thank you for that)

But I also started using a tool that ended up being a big part of my career for five years. One day I would love VB - the next I'd hate it. Then I would love it again, with periods of frustration along the way. It was so easy to use - but it didn't have enough power. It would work flawlessly in some areas - and then it would crash in others. The biggest issue I had with the tool was upgrading our VB3 application to VB4, the 16-bit version. A hellish month later, we finally got the application in a stable state (group therapy also helped me get through this difficult part in my career). That taught me a big lesson: Never assume a new version is automatically better.

Later, I moved on to the consulting world, where I ended up using VB on a number of projects. I learned a lot of component-based development and how objects were used. I delved into the world of COM and how it permeated VB. I learned how the Win32 APIs could improve VB applicationscin fact, this interest eventually led me to writing my first programming book. Along the way, I fell in love with CreateThread() and used it in a VB5 NT service that I wrote. It was cool; it was hardcore programming - and it actually worked. Unfortunately, love is sometimes blind, and VB6 was a big wake-up call for me. Alas, that service never made it to VB6 due to my lack of knowledge about how VB uses thread-local storage, or TLS. Another lesson learned: If you want to open up the hood, be prepared to get dirty, and accept the fact that you're going to run into things that you never knew about.

Around 1999, I started to get antsy. The more I read about programming and development issues, the more features I wished VB had. Java was also becoming a big buzzword, and I wanted to get rid of the VB guy label. I wanted to get different perspectives. I wanted to learn other technologies. So I joined a consulting company that originally had a focus on learning technologies other than just VB. Eventually, the company focused exclusively on Java, so I ended up doing Java development for nearly a year.

This was also a big learning experience for me. I discovered how much I loved object-oriented development, something that VB lacked in areas. I learned how Java made it easy to get a lot of tasks accomplished. I found out that the Java IDEs really stunk—they either took up a lot of memory or they simply didn't work. I ended up using a text editor to get my Java coding done and realized that VB's IDE really had a lot going for it—it made me so much more productive. And I also found out that Java is simply another way to get applications written. It's not revolutionary, but it doesn't suck, either. Unfortunately, too many developers jumped on the Java bandwagon, and simply started developing without a lot of thought put into the architecture. Ultimately, the Java-based systems that I saw were rather ugly, but they probably would've been just as ugly if they had been written in C++ or VB. Again, another lesson learned: The language usually won't make or break a project—it's the architects and developers creating the code that will determine a project's success.

All that being said, I'm now looking forward to the release of .NET. I love it. It's great. The framework is extensive. I love the cryptography classes—if you've ever done development using the CryptoAPI, you'll never want to use it after you see what .NET has to offer. Emitting code at run-time is going to lead to a lot of amazing things. Interop will allow us to use what we've written into our .NET applications. We don't have to worry about GUIDs and IDL anymore. We can focus on the "real" problems. It's going to make Windows development easier—and I'm going to do it in C# if I can.

Personally, I'm not a language bigot. I'll use whatever language it takes to get a project done, be it C++, VB, or Java. But the love that I had for VB is gone. I have nothing against VB.NET—frankly, I haven't even looked at it. And VB.NET has a lot of things I've been longing for, such as threads and inheritance. However, given that most of my work has been in Java or C++ in the last year, it's easier for me to use C#. And to be totally honest, I don't like C-like languages that much. While I respect C++ developers and I personally find C++ a fine language for some applications, I've done enough in C++ that I hope to never use it again. But my real hope is that someone eventually comes out with a tool that allows you to define your own language for .NET, so you can view the .NET world any way you want, and so you can write them with a language with which you're comfortable. All those dreams aside, I really have no interest in VB.NET. To me, the writing's on the wall: C# was written for .NET. VB.NET wasn't.

I'm sure I'll have to use VB.NET on a project sometime in the future, and I'll learn how to use it. Apress has enough books coming out on VB.NET that will make this learning process very easy for me. But for now, the relationship has ended, and that's OK. As I mentioned in the previous paragraph, .NET really should be language-agnostic. C# shouldn't be the language of choice. IL is really the language of languages in .NET, but I'm not planning on writing applications in IL. Having a tool that makes custom languages would be great. Yes, writing in the same languages makes project development easier, but in reality, the language is really starting to lose its importance in my book, especially with .NET. My hope is that .NET ends the language wars (if there ever were any) and gets people to focus on solving problems. I'm really excited about the future of .NET.

I have to admit, though, VB changed the development world. Some loved it. Others hated it. But you simply couldn't ignore it. It made UI development in Windows a breeze. And if VB didn't have enough in the box, component vendors usually filled in the gaps. Whether VB.NET becomes a language of choice for millions of developers is unknown at this point, but there is no doubt in my mind that a lot of what made VB popular has made it into .NET. That alone makes .NET stronger.