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
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.