Will VB.NET be more stable than VB6?

[Jason]

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.

:-)

[Jason]

"Jay King" <nemopsj@aol.com> wrote:
>Every problem you listed was only experienced by people who dont have a
>clue. Esp the thing about the arrays, if you cant figure out hwo to use
>variant arrays you have issues.
>"Jason" <jason@hotmail.com> wrote in message news:3d8e8c8e$1@10.1.10.29...

These aren't "problems," they are "design flaws." If you started to design
a new language, you would not begin with the premise that you needed two
sorts of arrays with slightly different rules for each.

For new programmers, this, along with a whole bunch of other problems like
it, adds up to a lot of extra stuff to learn with absolutely no gain to productivity.


Every one of these design decisions was made for a good reason. But over
time, they all add a lot of complexity to the language.

Let me be more specific on some of these things:

Functions for manipulating strings:
Mid$
Left$
UCase$
LCaseS
StrConv

Functions for manipulating files:
Open
Close
Get
Put
Line Input
Input

Why are all these things functions? Because they were functions in Basic
20 years ago! My TRS80 Model 100 supports all these functions, using the
original version of Microsoft Basic.

Strings are objects. Files are objects. But in VB-classic, they are data
structures, or something that is not quite an object. Legacy.

As far as not knowing about how to use Variant Arrays - I know how to use
them very well. I also know most of the things about them that cause beginners
the most grief. Have you found any of these things yet, or are you still
learning the language?

[Jay King]

Every problem you listed was only experienced by people who dont have a
clue. Esp the thing about the arrays, if you cant figure out hwo to use
variant arrays you have issues.
"Jason" <jason@hotmail.com> wrote in message news:3d8e8c8e$1@10.1.10.29...
>
> 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.
>
> :-)

[Miha Markic]

Yeah, like threads support...

"Jay King" <nemopsj@aol.com> wrote in message news:3d8e904e$1@10.1.10.29...
> Every problem you listed was only experienced by people who dont have a
> clue.

[Jay King]

Obviously im not still learning the language..
"Jason" <jason@hotmail.com> wrote in message news:3d8e92ca$1@10.1.10.29...
>
> "Jay King" <nemopsj@aol.com> wrote:
> >Every problem you listed was only experienced by people who dont have a
> >clue. Esp the thing about the arrays, if you cant figure out hwo to use
> >variant arrays you have issues.
> >"Jason" <jason@hotmail.com> wrote in message
news:3d8e8c8e$1@10.1.10.29...
>
> These aren't "problems," they are "design flaws." If you started to
design
> a new language, you would not begin with the premise that you needed two
> sorts of arrays with slightly different rules for each.
>
> For new programmers, this, along with a whole bunch of other problems like
> it, adds up to a lot of extra stuff to learn with absolutely no gain to
productivity.
>
>
> Every one of these design decisions was made for a good reason. But over
> time, they all add a lot of complexity to the language.
>
> Let me be more specific on some of these things:
>
> Functions for manipulating strings:
> Mid$
> Left$
> UCase$
> LCaseS
> StrConv
>
> Functions for manipulating files:
> Open
> Close
> Get
> Put
> Line Input
> Input
>
> Why are all these things functions? Because they were functions in Basic
> 20 years ago! My TRS80 Model 100 supports all these functions, using the
> original version of Microsoft Basic.
>
> Strings are objects. Files are objects. But in VB-classic, they are data
> structures, or something that is not quite an object. Legacy.
>
> As far as not knowing about how to use Variant Arrays - I know how to use
> them very well. I also know most of the things about them that cause
beginners
> the most grief. Have you found any of these things yet, or are you still
> learning the language?

[Jay King]

Its called API
"Miha Markic" <miham@pleasenospam.spin.si> wrote in message
news:3d8ec488@10.1.10.29...
> Yeah, like threads support...
>
> "Jay King" <nemopsj@aol.com> wrote in message
news:3d8e904e$1@10.1.10.29...
> > Every problem you listed was only experienced by people who dont have a
> > clue.
>
>

[Vlad Ivanov]

Thanks for pointing out to me the true evil source of horrible problems that
warranted ****ing up the language so much as to make all my codebase absolute
to the point of forcing me to reconsider vendors.

There was ofcourse the possible route of gradually upgrading a popular and
powerful language through careful redesign, deprecation and such. By why
beat around the bush, right? Evil such as this listed here needs radical
measures.

>Let me be more specific on some of these things:
>
>Functions for manipulating strings:
> Mid$
> Left$
> UCase$
> LCaseS
> StrConv
>
>Functions for manipulating files:
> Open
> Close
> Get
> Put
> Line Input
> Input
>

[Eddie Burdak]

Jason,

<Mega snip .. sorry>

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

And there's the crux. In 10 years the code gets broken again. It makes
languages like COBOL and FORTRAN look good. Perhaps the hard core
routines needs to be written in these languages and compiled to DLL's
and the new .NEXT thingy used just as a front end.

Eddie

[Howard Kaikow]

Fortran has much changed over the years.

--
http://www.standards.com/; Programming and support for Word macros,
including converting from WordBasic to VBA; Technical reviewing; Standards;
Product functional/design/specifications
------------------------------------------------
"Eddie Burdak" <eburdak@pilatus-aircraft.com> wrote in message
news:3d8f2cd6$1@10.1.10.29...
> Jason,
>
> <Mega snip .. sorry>
>
> > 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.
>
> And there's the crux. In 10 years the code gets broken again. It makes
> languages like COBOL and FORTRAN look good. Perhaps the hard core
> routines needs to be written in these languages and compiled to DLL's
> and the new .NEXT thingy used just as a front end.
>
> Eddie
>

[Patrick Troughton]

Just to avoid misunderstandings....most (if not all) of the aforementioned
functions are still in VB.NET. That is, you can still use Mid, Left, UCase,
etc.. The same goes for the I/O functions except some of them have been renamed
(Open is now FileOpen, Close is now FileClose, etc.).

/Pat
---------------------------
Get .NET, it's hella phat.
---------------------------

"Vlad Ivanov" <vb.@127.0.0.1> wrote:
>
>Thanks for pointing out to me the true evil source of horrible problems
that
>warranted ****ing up the language so much as to make all my codebase absolute
>to the point of forcing me to reconsider vendors.
>
>There was ofcourse the possible route of gradually upgrading a popular and
>powerful language through careful redesign, deprecation and such. By why
>beat around the bush, right? Evil such as this listed here needs radical
>measures.
>
>>Let me be more specific on some of these things:
>>
>>Functions for manipulating strings:
>> Mid$
>> Left$
>> UCase$
>> LCaseS
>> StrConv
>>
>>Functions for manipulating files:
>> Open
>> Close
>> Get
>> Put
>> Line Input
>> Input
>>

[Vlad Ivanov]

Thats really not the problem. Problem is that my project files simply don't
open in VB.Net (They are based around Usercontrols, i have described that
issue before).

I wonder - what is the delay?


"Patrick Troughton" <vb.@127.0.0.1> wrote:
>
>Just to avoid misunderstandings....most (if not all) of the aforementioned
>functions are still in VB.NET. That is, you can still use Mid, Left, UCase,
>etc.. The same goes for the I/O functions except some of them have been
renamed
>(Open is now FileOpen, Close is now FileClose, etc.).
>
>/Pat
>---------------------------
>Get .NET, it's hella phat.
>---------------------------
>
>"Vlad Ivanov" <vb.@127.0.0.1> wrote:
>>
>>Thanks for pointing out to me the true evil source of horrible problems
>that
>>warranted ****ing up the language so much as to make all my codebase absolute
>>to the point of forcing me to reconsider vendors.
>>
>>There was ofcourse the possible route of gradually upgrading a popular
and
>>powerful language through careful redesign, deprecation and such. By why
>>beat around the bush, right? Evil such as this listed here needs radical
>>measures.
>>
>>>Let me be more specific on some of these things:
>>>
>>>Functions for manipulating strings:
>>> Mid$
>>> Left$
>>> UCase$
>>> LCaseS
>>> StrConv
>>>
>>>Functions for manipulating files:
>>> Open
>>> Close
>>> Get
>>> Put
>>> Line Input
>>> Input
>>>
>

[Michael Bennett]

In article <3d8e8c8e$1@10.1.10.29>, jason@hotmail.com says...
> Hey, even C++ can't move to .NET without breaking compatibility.
Are you sure about this?
I read in CUJ that if you don't violate the One Definition Rule C++
compiles fine with the /CLR switch
Not a C/C++ programmer so I can't personally verify this.

Michael

[Dan Barclay]

Jason,

Sorry, but you don't seem to understand VB as a product, or Basic as a
language.

On 22 Sep 2002 20:37:50 -0700, "Jason" <jason@hotmail.com> wrote:

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

VB first? "Managed code" as it's known now was available with CP/M
versions of Basic.

>* Component model for reuse
>* Very nice GUI support, which is why it is relevant even today.

Yup, nice, but very important compared to a reusable code library.
Components and GUI can be reproduced from simple core libraries in a
matter of minutes.

>VB6, and all its predecessors, were so tied in to Windows that any major
>change to Windows broke the language.

You have *got* to be kidding!

> Look at VB4-16 to VB4-32. Out with
>the VBX, in with the OCX.

Absolutely wrong, with regard to most business code. What does VBX or
OCX have to do with Basic code? Nothing. Vendors that cared created
OCX's that worked the same way their VBX's worked such that zero
effort was required in VB to upgrade.

Most code is in raw Basic language syntax, using the various component
models for wrappers only. Moving from DOS to Win16, then Win16 to
Win32 was accomplished fairly easily. Code itself could be written in
the earlier version in a way that let it work in the later version.

The changes themselves had little or nothing to do with the OS
platform!

>WHICH GETS ME TO MY POINT:
>VB.NET is a redesign, made to fit into the new world - in a way that VB6
>cannot.

ROTFLMAO!

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

Oooowww... this is so funny it hurts! LOL!

Dan
Language Stability is a *feature* I wish VB had!
(#6)
Error 51
Error 3
Error 9
....

[Tom Shelton]

"Jay King" <nemopsj@aol.com> wrote in message news:3d8ec5b3$1@10.1.10.29...
> Its called API

Have you actually tried to use the API for this? It isn't as easy as you
would seem to state here. In VB.NET is a simple matter of:

Dim runner As New Thread(AddressOf MyThreadProc)
runner.Start()

In VB6, you need to do all kinds of nasty lowlevel work to make sure you can
even start the thread... VB.NET is much better to work with if you need to
use threads... Believe me, this comes from a very recent, bitter, and
continuing ****...

Tom Shelton

[Eddie Burdak]

Howard,
Howard Kaikow wrote:
> Fortran has much changed over the years.

Yes since 77 there has been 90/95 and now there are some .NET versions
flying around.

But the compilers will still happily let me mod my 77 code and
re-compile in the new compiler - unfortunately the same can't be said
of VB. Hence perhaps keeping the core in something that has been
around for a long time is not such a bad thing and use the .NEXT as a
front end

Eddie