Why did Microsoft Ruin Visual Basic?

[Jon Skeet [C# MVP]]

Jon, you're right in what you say, but again, you are missing the point.
Look at the subject of this thread. I'm trying to point out the advantages
of VB.NET over VB 6.0.

Yes, but you're not being at *all* clear about them. Please look over
your posts again - if I can't see what you mean, and I know a fair bit
about .NET, how is someone who *doesn't* know about .NET meant to
understand you?

In today's world, it is not uncommon to work with more than one processor or
HyperThreaded processors. A VB 6.0 app would have a hard time taking
advantage of this. In .NET, this can be leveraged and is certainly ONE of
the many advantages of VB.NET.

Yup, and I never said that multi-threading *wasn't* a significant
advantage over VB6. It's just that the way you've put it, saying that
the framework runs in one thread and the app in another, is completely
misleading.

 

[Chris Dunaway]

I'll admit, it's a bit trickier to handle forms and stuff because there's no
default instances anymore (there's nothing to stop you creating a shared

This has been addressed in Whidbey with the addition of the "My"
namespaces.

In my humble opinion VB.net is *not* the next version of
VB6 - its a totally new language which just happens to share some syntax
with VB6.

Totally agree

 

[Codemonkey]

This has been addressed in Whidbey with the addition of the "My"

namespaces.

I've heard rumours about "My" and am a bit skeptical so far. Sorry for going
a bit off topic, but:

1) Why is it only available to VB and not C#? Surely Microsoft doesn't think
us VB programmers are dumber than the C# equivelent

2) Will the "My" namespace be customizable? I'd like to be able to fill the
"My" namespace with things that I personally would use the most, not what
Microsoft thinks I use the most.

Trev.

 

[Dan]

With some editing, the poster is correct:

Visual Studio .NET is not more efficient than
VB6. I can write a VB6 App that is at least twice as fast as
.NET. and 1/10 th the size

Roger

I wouldn't bet on that. For instance, strings are used all the time
in VB. The VB6 String type is immutable, meaning you can't change it,
let alone append to it. So something like...

for i=0 to 1000
string1 = string1 & string2
next i

is very inefficient since your going to create and destroy 1000 string
variables on every assignment. In contrast, .Net's string types can
grow. .Net also contains a special class called StringBuilder in
which you can even specify an initial size so as to minimize the
number of dynamic memory allocations. In addition, the incredibly
inefficient Variant type has been removed which many VB programmers
mistakeably use.

Most importantly, the thing to remember here is that computers are
running a helk of a lot faster these days since VB6 was unveiled.
Efficiency is not so much a factor these days as stability and
security have recently become. Although VB6 is a great system, it
really needed to be updated. Once a developer finds himself having to
visit the WinAPI just to paint to a window or handle mouse wheel
events, the usability and ease of use of VB sharply diminishes. At
which time, I usually find myself creating an MFC project.

 

[Scott M.]

"Roger" <[email protected]> wrote in message

I wouldn't bet on that. For instance, strings are used all the time
in VB. The VB6 String type is immutable, meaning you can't change it,
let alone append to it. So something like...

for i=0 to 1000
string1 = string1 & string2
next i

is very inefficient since your going to create and destroy 1000 string
variables on every assignment.
CORRECT!

In contrast, .Net's string types can grow.

INCORRECT! In. .NET a String is also immutable (as it was in VB 6.0).
Strings are Reference Types and therefore managed on the heap, unlike the
primitive data types (integer, date, boolean, decimal, etc.) which are Value
Types and managed on the Stack. However, .NET offers the StringBuilder to
use in circumstances like the one you describe above.