If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Threaded View

Will VB.NET be more stable than VB6?

This question was asked in an earlier post, and I thought it was interesting,
so I am giving it its own topic.

MY OPINION:
Yes.

WHY?
I've been programming VB for a long time (since 1993). In that time, I have
been able to compare it to other mainstream languages like C++ and Java.

VB had many firsts:
* Pointerless
* Garbage collection
* Component model for reuse
* Very nice GUI support, which is why it is relevant even today.

But it was not a complete idea when it was introduced. Here is a list of
some of the problems:
* Variant Arrays versus SafeArrays.
* Nasty API call syntax.
* Object models that are WAY past their prime:
* Menu support
* Forms (all controls are public, etc.)
* Relies on functions for many things that should be methods on objects.
* Poor support for threaded applications.
* Many last minute additions that became "legacy" once they had shipped.

The problem with VB6 was that in order to fix it, you had to break it. It
was saddled with so much legacy that there was just no way to go forward
with the modern Computer Science ideas, that include:
* a different form of garbage collection
* Just-In-Time compilation (important for security)
* redesigned frameworks (that cover a lot more than old VB ever did)

VB6, and all its predecessors, were so tied in to Windows that any major
change to Windows broke the language. Look at VB4-16 to VB4-32. Out with
the VBX, in with the OCX.

Yes, things have been relatively stable since then, but Microsoft is again
moving Windows in a different direction.

With .NET, DLLs are a thing of the past. It supports them, but does not
use them natively. COM is supported for legacy purposes, but .NET does not
use COM internally. Obviously, .NET calls Windows APIs, but they are buried
pretty deep inside the framework. .NET is a whole new ballgame.

WHICH GETS ME TO MY POINT:
VB.NET is a redesign, made to fit into the new world - in a way that VB6
cannot. This may well give VB.NET a new lease on life. It is certainly
easier for new programmers to pick up - you know, the ones who learned nothing
but Java in college? It does not have all the little rules to remember and
gotchas to work around that you find in classic VB. It is a prettier, simpler
language.

BUT ALSO, VB.NET compiles to IL, which is most likely going to be supported
at this level in all future versions of the CLR. That means that even if
you never get another version of the language, you can still compile and
run on the latest CLR.

If Microsoft introduces another version of VB.NET that is incompatible with
this one, language-wise, you will still be able to use the two languages
together in an application. They are both .NET languages.

But even so, I believe that the latest version of VB.NET, sans the compatibility
features - YUCK - is a pretty clean language. That means that it can be
extended and expanded quite a bit before it gets ugly.

VB-classic, in contrast, started ugly (no OO features), and then just got
uglier from there. Right now, to anyone who knows Java, or Perl, of just
about any other language, VB-classic is scary-ugly.

BUT AS LONG AS MICROSOFT SUPPORTS THE .NET CLR, VB.NET WILL CONTINUE TO BE
A VIABLE LANGUAGE, and Microsoft will be able to support it with full backward
compatibility.

What happens when another paradigm shift comes along (like 16-bit --> 32-bit
--> JIT)??? Hey, even C++ can't move to .NET without breaking compatibility.
The next big paradigm shift will probably break backward compatibility as
well. Nothing you can do about it, since no one knows what the new ideas
will be, so they can't plan for them.

When will that be? 5 years? 10 years? Who knows? But I do believe that
as long as .NET exists, VB.NET will be supported, enhanced, and backward
compatible.