Why did Microsoft Ruin Visual Basic?

[Truble]

Visual Studio .NET is not more efficient to write than
VB6. I can write a VB6 App at least twice as fast as
in .NET. Why did Microsoft ruin the syntax advantage of
VB6 in .NET?

[Jon Skeet [C# MVP]]

Scott M. <s-***@BADSPAMsnet .net> wrote:

You are correct that one process can be running many threads within it. My
point was that since much of the "grunt" work of a .NET application is done
in its own thread, the main application is not encumbered by the Framework
doing its thing and in a VB 6 application, you would have everything
happening in one thread.

You give the impression that "the framework" is running in one thread,
and the application is done in another, why is entirely inaccurate.
*All* the threads in an app are running "the framework", other than
those which entirely run unmanaged code.

If you mean that the GUI thread is easily separated from worker
threads, I agree with you - but that's a very different matter.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Scott M.]

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

Scott M. <s-***@BADSPAMsnet .net> wrote:

You are correct that one process can be running many threads within it. My point was that since much of the "grunt" work of a .NET application is done in its own thread, the main application is not encumbered by the Framework doing its thing and in a VB 6 application, you would have everything
happening in one thread.
You give the impression that "the framework" is running in one thread,
and the application is done in another, why is entirely inaccurate.

Well no, not really. The GC for example runs within the framework and in a
different thread than the .NET application it services. This is beneficial
because when the GC kicks in to do its thing, it does not impede the thread
the main application is running in. This is one of the reasons not to
invoke the GC directly from within a .NET application. If you do, you will
bring the GC's processing into the main application's thread and possibly
reduce its performance.
*All* the threads in an app are running "the framework", other than
those which entirely run unmanaged code.

If you mean that the GUI thread is easily separated from worker
threads, I agree with you - but that's a very different matter.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Scott M. <s-***@BADSPAMsnet .net> wrote:

You give the impression that "the framework" is running in one thread,
and the application is done in another, why is entirely inaccurate.

Well no, not really. The GC for example runs within the framework and in a
different thread than the .NET application it services.

Well, potentially - depending on machine configuration - but that's
very different from giving the impression that the *whole* framework
runs in a different thread. There are *lots* of threads (potentially)
some of which may be running your own code, some of which may be
running "purely framework" code - but you're unlikely to get very far
in *any* thread without running "framework code".

Basically I'm not at all sure what your argument about comparing .NET
to VB is here, because it seems somewhat confused.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

One a single CPU, it makes a difference.

Why do so many people think Threads = concurrency on a single proc?`
Probably the worlds largest misconception
"Scott M." <s-***@BADSPAMsnet .net> wrote in message
news:#c******** ******@TK2MSFTN GP11.phx.gbl...

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

Scott M. <s-***@BADSPAMsnet .net> wrote:

You are correct that one process can be running many threads within

it.

My point was that since much of the "grunt" work of a .NET application is done in its own thread, the main application is not encumbered by the Framework doing its thing and in a VB 6 application, you would have everything
happening in one thread.
You give the impression that "the framework" is running in one thread,
and the application is done in another, why is entirely inaccurate.

Well no, not really. The GC for example runs within the framework and in

a different thread than the .NET application it services. This is beneficial because when the GC kicks in to do its thing, it does not impede the thread the main application is running in. This is one of the reasons not to
invoke the GC directly from within a .NET application. If you do, you will bring the GC's processing into the main application's thread and possibly
reduce its performance.

*All* the threads in an app are running "the framework", other than
those which entirely run unmanaged code.

If you mean that the GUI thread is easily separated from worker
threads, I agree with you - but that's a very different matter.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Codemonkey]

> Quite simple: They didn't.

Exactly. Microsoft didn't ruin VB6 at all. VB6 hasn't changed, and most
likley will not change - it will always be VB6 ;) If you don't like VB.net,
then Microsoft hasn't stopped you from using VB6 if you want to.

"Jerry Ham" <Ye************ ********@Not.co m> wrote in message
news:Of******** ******@tk2msftn gp13.phx.gbl...

Quite simple: They didn't.

"Truble" <an*******@disc ussions.microso ft.com> wrote in message
news:06******** *************** *****@phx.gbl.. .

Visual Studio .NET is not more efficient to write than
VB6. I can write a VB6 App at least twice as fast as
in .NET. Why did Microsoft ruin the syntax advantage of
VB6 in .NET?

[Jon Skeet [C# MVP]]

<di********@dis cussion.microso ft.com> wrote:

One a single CPU, it makes a difference.

Why do so many people think Threads = concurrency on a single proc?`
Probably the worlds largest misconception

Well, threads *do* make it easy *sort* of do two things at once, so
long as one of them is "waiting for something else to happen". Even on
a single processor, correct use of threads is enormously important.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Scott M.]

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

Scott M. <s-***@BADSPAMsnet .net> wrote:

You give the impression that "the framework" is running in one thread,
and the application is done in another, why is entirely inaccurate.
Well no, not really. The GC for example runs within the framework and in a different thread than the .NET application it services.

Well, potentially - depending on machine configuration - but that's
very different from giving the impression that the *whole* framework
runs in a different thread. There are *lots* of threads (potentially)
some of which may be running your own code, some of which may be
running "purely framework" code - but you're unlikely to get very far
in *any* thread without running "framework code".

Basically I'm not at all sure what your argument about comparing .NET
to VB is here, because it seems somewhat confused.

Jon, my point is very simple, but your too close to the fire to see the
flame. In a VB 6 application, you not only had to write code for your app
to work, but you also had to write additional code for "housekeepi ng"
purposes and all that code ran in a single thread (usually).

In .NET, there is a very distinct separation between what you have to write
and what is already written into the Framework. And, as is the case with the
GC, you have the ability to put different actions into different threads.

This is a very simple point, but you've been "picking" at the definition of
process and thread, which is useful to understand but not the point of the
original post.


--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Scott M. <s-***@BADSPAMsnet .net> wrote:

Basically I'm not at all sure what your argument about comparing .NET
to VB is here, because it seems somewhat confused.

Jon, my point is very simple, but your too close to the fire to see the
flame. In a VB 6 application, you not only had to write code for your app
to work, but you also had to write additional code for "housekeepi ng"
purposes and all that code ran in a single thread (usually).

In .NET, there is a very distinct separation between what you have to write
and what is already written into the Framework. And, as is the case with the
GC, you have the ability to put different actions into different threads.

This is a very simple point, but you've been "picking" at the definition of
process and thread, which is useful to understand but not the point of the
original post.

It strikes me you've got three points here:

1) .NET provides good multi-threading capabilities
2) .NET gives a good garbage collection system
3) .NET has a very extensive library which does a lot of things you may
have had to write yourself beforehand

All those three things are true, but you seem to be conflating them
when they are very separate things.

(In terms of GC occurring in separate threads, I believe the "normal"
CLR actually has a stop-the-world GC - it's finalization that occurs in
another thread. A different CLR typically used on multi-processor
machines has a concurrent GC.)

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

One a single CPU does it bloody matter , its stop the world anyway. Geez.
"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** @msnews.microso ft.com...

Scott M. <s-***@BADSPAMsnet .net> wrote:

Basically I'm not at all sure what your argument about comparing .NET
to VB is here, because it seems somewhat confused.

Jon, my point is very simple, but your too close to the fire to see the
flame. In a VB 6 application, you not only had to write code for your app to work, but you also had to write additional code for "housekeepi ng"
purposes and all that code ran in a single thread (usually).

In .NET, there is a very distinct separation between what you have to write and what is already written into the Framework. And, as is the case with the GC, you have the ability to put different actions into different threads.
This is a very simple point, but you've been "picking" at the definition of process and thread, which is useful to understand but not the point of the original post.

It strikes me you've got three points here:

1) .NET provides good multi-threading capabilities
2) .NET gives a good garbage collection system
3) .NET has a very extensive library which does a lot of things you may
have had to write yourself beforehand

All those three things are true, but you seem to be conflating them
when they are very separate things.

(In terms of GC occurring in separate threads, I believe the "normal"
CLR actually has a stop-the-world GC - it's finalization that occurs in
another thread. A different CLR typically used on multi-processor
machines has a concurrent GC.)

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Scott M.]

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.

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.
"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** @msnews.microso ft.com...

Scott M. <s-***@BADSPAMsnet .net> wrote:

Basically I'm not at all sure what your argument about comparing .NET
to VB is here, because it seems somewhat confused.

Jon, my point is very simple, but your too close to the fire to see the
flame. In a VB 6 application, you not only had to write code for your app to work, but you also had to write additional code for "housekeepi ng"
purposes and all that code ran in a single thread (usually).

In .NET, there is a very distinct separation between what you have to write and what is already written into the Framework. And, as is the case with the GC, you have the ability to put different actions into different threads.
This is a very simple point, but you've been "picking" at the definition of process and thread, which is useful to understand but not the point of the original post.

It strikes me you've got three points here:

1) .NET provides good multi-threading capabilities
2) .NET gives a good garbage collection system
3) .NET has a very extensive library which does a lot of things you may
have had to write yourself beforehand

All those three things are true, but you seem to be conflating them
when they are very separate things.

(In terms of GC occurring in separate threads, I believe the "normal"
CLR actually has a stop-the-world GC - it's finalization that occurs in
another thread. A different CLR typically used on multi-processor
machines has a concurrent GC.)

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too