I am presently a user of classic vb6 and hang out on those newsgroups. Some
of you may be aware that there is a very anti MS and vb2005 feeling there. I
have tried to get them to tell me which features of vb2005 are actually
worse then vb6 in practice, and forget the philosophy of backward
compatibility for a moment.
I would now like to hear "the other side". Could *anyone who previously used
vb6* (only those pleased; I feel the others will not be able to make the
comparison) tell me if the move to dotnet was a good idea. Leave aside the
needs of your workplace, future proofing etc. and say whether you regret the
move or not, and the reasons for your answer.
Apologies if this is the wrong group. If it is, perhaps you'll tell me which
dotnet group is the best one. Oh, and which is the best one for beginners or
'converts'. Thanks v much
Hi Aalaan,
I started using Visual Basic with version 1.0. I've used every version
since then. I watched it go from its most basic version, which was
*extremely* rudimentary but enabled you to write very basic Windows
applications with no MDI support, to version 6.0, where you could
write ActiveX components, COM DLLs, and full-fledged Windows
applications. I watched the whole history. I was there for it all.
I approached .NET with a lot of enthusiasm--and a lot of baggage.
There were things that I wanted to be able to do in VB6 that I *simply
could not do.* Or, if I wanted to do them, the amount of code that I
had to write was enormous, and I had to invoke obscure API functions
which, if I was not very careful, crashed my program (or, in the worst
case scenario, the user's machine.
At first, moving to .NET was difficult. I had to unlearn a lot of
things. But in the long run, it proved to be a worthwhile investment.
I haven't looked back since. These days, I'm loathe to work with VB6
code, and dread having to maintain our legacy VB6 code. I'd rather
port it .NET because the .NET code is more stable, easier to document,
and more secure.
There were a few things that VB6 had going for it:
- It was a great prototyping platform. You could whip things up in a
jiffy. The problem was, too many prototypes became production
software. I'm not whipping that out of my butt. I watched it happen,
time and again. "We'll just do the UI prototype in VB." Next thing you
know, the "prototype" is the application. (To this day, I refuse to
use development software to prepare UI prototypes. I do them in
Visio.)
- It was a great tool for experimentation. If you wanted to figure out
how to do something, or whether or not something was feasible, without
having to build a full framework, you could do it in VB6 in a few
minutes, and determine its feasibility. Sometimes, that's a lot harder
to do in .NET (though that's not always the case). And there's still
that problem that classic VB applications tend to become production
applications.
- When you NEEDED to ignore the data type of a variable, you could.
All the religous arguments aside, the Variant served a discrete
purpose when it came into being. It was an intrinsic part of COM, and
COM was created to solve a certain set of problems. And for a while,
COM solved those problems very well. Unfortunately, COM's
effectiveness was short-lived; DLL Hell ruined it. COM's problems,
however, are one of the key issues that led to many of the design
decisions in .NET.
- There was a plethora of available 3rd party components for it. That
doesn't mean they were all worth what you paid for, but the chances
were very high that you could find what you were looking for. And if
you couldn't find one, and you had the time, you could roll your own
control with a little time and careful coding.
Others will have their opinions about things that made classic VB a
great platform. Things like the fact that it was so easy to learn, it
was pervasive, it was affordable, you could find books about it just
about anywhere, the language was built into the Office suite, and so
on. But even with all of that, there were some fairly serious
drawbacks to it:
- Classic Visual Basic was never a truly type-safe language. Type-
safety is a critical part of writing secure code. It ensures that my
code doesn't write over someone else's memory. .NET is fanatical about
type safety.
- As useful as the Variant was, it was sometimes difficult to debug,
because it tended to be overused. Its abuse wasn't always intentional.
A lot of developers were self-taught; they didn't understand the
importance of Option Strict, which was a relatively late addition to
the language. Consequently, the default data type for many variables
was a Variant. This meant that many variables became Variants by
default and their data types were subject to spontaneous changes as
the software ran. These types of defects are notoriously difficult to
debug.
- Classic VB was never truly object oriented. It supported the
*notion* of objects--and COM's notion of objects, at that--but it
didn't support implementation inheritance, polymorphism, overloading,
or overriding. You had to do all of that yourself through delegation.
This created massive code libraries where reams of code simply
forwarded function calls to other functions. And VB's objects didn't
support constructors.
- The error handling system in VB was always (in my personal opinion)
kludgy at best. You could either use On Error Resume Next or On Error
GoTo. And trying to nest error handlers quickly got messy. Anyone who
didn't know how to properly handle errors was in for a whole world of
hurt.
So, along comes VB.NET. I have yet to run into anything that I could
do in classic VB that I can't to in VB.NET. Further, my code is more
secure is because it's type-safe; I don't have to hand-code calls to
the Win32 API anymore; structured exception handling is far superior
to the error handling in classic VB; I get full support for all of the
OOP principles, including objects with overloadable constructors; and
I still have a burgeoning supply of available 3rd party components at
my disposal.
In it's day, VB6 was a great platform, and I loved it. I swore by it.
I could write just about anything I needed to do in it. But bigger and
better things have come along. I haven't regretted the move to .NET.
I hope I have answered your question.
