468,771 Members | 1,892 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,771 developers. It's quick & easy.

Why did Microsoft Ruin Visual Basic?

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?
Jul 21 '05 #1
44 1804
BGD
I disagree. I have been using VB since the first beta was released more than
12 years ago and I love the changes and the fact that it is now a true
object oriented language. I also program in Java, C++ and Delphi, and I
always wished that VB had the object oriented features that the other
languages did, and now it does!

I do most of my programming in C# now and it is a great language. In most
programs C# and VB.NET perform about the same, but I have some application
where C# clearly performs better. It is a matter of chosing the right
tool/language for the right project...
"Truble" <an*******@discussions.microsoft.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?

Jul 21 '05 #2
I disagree too, VB is not ruined. If you now how to use the new features
(e.g. OO), you can write faster and produce better code in VB.NET.
--
Greetz,
Jan
__________________________________
Read my weblog: http://weblogs.asp.net/jan
"BGD" <tb******@hotmail.com> schreef in bericht
news:%2***************@tk2msftngp13.phx.gbl...
I disagree. I have been using VB since the first beta was released more than 12 years ago and I love the changes and the fact that it is now a true
object oriented language. I also program in Java, C++ and Delphi, and I
always wished that VB had the object oriented features that the other
languages did, and now it does!

I do most of my programming in C# now and it is a great language. In most
programs C# and VB.NET perform about the same, but I have some application
where C# clearly performs better. It is a matter of chosing the right
tool/language for the right project...
"Truble" <an*******@discussions.microsoft.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?


Jul 21 '05 #3
Sorry Mate, I don't agree. There's a lot of stuff that you can do in VB.net
with a single line of code that would take you a long time to achieve in VB6
(e.g. Inheritance)

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
default instance though), but for the most part VB.net is a lot more
powerful, if a bit daunting because of the size of the framework.

I don't think you should look at it from the point of view that Microsoft
have ruined VB. 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.

Thanks for your thoughts though.

Trev.
"Truble" <an*******@discussions.microsoft.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?

Jul 21 '05 #4
Truble <an*******@discussions.microsoft.com> wrote:
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?


You being able to write a VB6 app twice as fast as you can write the
equivalent in VB.NET doesn't mean that VB.NET isn't as efficient - it
may well just mean that you're more proficient in VB6.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jul 21 '05 #5
Why use .NET when you're not forced to. Personally speaking I wish MS had
not bothered converting VB into VB.NET :)

"Truble" <an*******@discussions.microsoft.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?

Jul 21 '05 #6
It's obvious that you haven't explored VB.NET enough yet to see the
tremendous improvements to the language. Yes, it is true that you may have
to write more code than in the past, but you have so much more control over
applications and classes that this is well worth it.
"Truble" <an*******@discussions.microsoft.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?

Jul 21 '05 #7
Well, that's really the thing...MS didn't "convert" anything:

VB.NET is not VB 7, it's a whole new programming language that shares some
of the coding constructs that VB 6 had.
ASP.NET is not "Classic ASP", the similarity in their names is about the
only thing they have in common.
VS.NET is not VS 7.0. While having some of the features of VS 6, VS.NET is
vastly improved and allows for a consitent approach to application
development.
"Adam" <ad**@nospam.com> wrote in message
news:un**************@tk2msftngp13.phx.gbl...
Why use .NET when you're not forced to. Personally speaking I wish MS had
not bothered converting VB into VB.NET :)

"Truble" <an*******@discussions.microsoft.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?


Jul 21 '05 #8
Actually VB.Net IS VB7 check your install directory.
"Scott M." <s-***@BADSPAMsnet.net> wrote in message
news:uS*************@TK2MSFTNGP11.phx.gbl...
Well, that's really the thing...MS didn't "convert" anything:

VB.NET is not VB 7, it's a whole new programming language that shares some
of the coding constructs that VB 6 had.
ASP.NET is not "Classic ASP", the similarity in their names is about the
only thing they have in common.
VS.NET is not VS 7.0. While having some of the features of VS 6, VS.NET is vastly improved and allows for a consitent approach to application
development.
"Adam" <ad**@nospam.com> wrote in message
news:un**************@tk2msftngp13.phx.gbl...
Why use .NET when you're not forced to. Personally speaking I wish MS had not bothered converting VB into VB.NET :)

"Truble" <an*******@discussions.microsoft.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?



Jul 21 '05 #9
m
> Actually VB.Net IS VB7 check your install directory.

We all know that version numbers for major applications are nothing but a
marketing tool.

They could have called it ".Net Studio Version 1.0", but then they would
risk loosing the "Brand Name" of "Visual Studio"

The fact that it's called VB7 is trivial. Earlier versions of VB pretty much
had the same underpinnngs(ignoring the change from 16bit to 32bit). VB.Net
is a different product than VB6.
"solex" <so***@nowhere.com> wrote in message
news:%2******************@TK2MSFTNGP12.phx.gbl...
Actually VB.Net IS VB7 check your install directory.
"Scott M." <s-***@BADSPAMsnet.net> wrote in message
news:uS*************@TK2MSFTNGP11.phx.gbl...
Well, that's really the thing...MS didn't "convert" anything:

VB.NET is not VB 7, it's a whole new programming language that shares some
of the coding constructs that VB 6 had.
ASP.NET is not "Classic ASP", the similarity in their names is about the
only thing they have in common.
VS.NET is not VS 7.0. While having some of the features of VS 6, VS.NET

is
vastly improved and allows for a consitent approach to application
development.
"Adam" <ad**@nospam.com> wrote in message
news:un**************@tk2msftngp13.phx.gbl...
Why use .NET when you're not forced to. Personally speaking I wish MS

had not bothered converting VB into VB.NET :)

"Truble" <an*******@discussions.microsoft.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?



Jul 21 '05 #10
And I can write a VB.NET or C# app twice as fast as I can in VB6. Why?
Other than the fact that they are both much more productive and the IDE
Rules? Well, because I haven't used VB6 in 2 years and I use C# and VB.NET
every day.

You can't make that statement fairly unless you know .NET thoroughly and if
you did, you wouldn't make that claim.
"Truble" <an*******@discussions.microsoft.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?

Jul 21 '05 #11
Can you show me some of your multi-threaded VB6 code? I remember it being a
nightmare. It's a breeze in VB.NET.

What about Windows Services? Can you show me some of those that you wrote?
I seem to remember having to run to C++ for those.

What about Intellisense, attirbutes, Deployment (I don't remember Regsrvr32
being a whole lot of fun)?....

I think you need to use VB.NET some more before you make such wild claims.
"Truble" <an*******@discussions.microsoft.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?

Jul 21 '05 #12
Unless you live in a communist country, you aren't forced to do anything,
let alone code in a specifc langauge.

VB.NET and C# are vastly superior to VB6 that's is silly to even argue
about. Only a VB6, 5, 4, 3, 2, 1 Programmer scared to learn something new
could make that claim!
"Adam" <ad**@nospam.com> wrote in message
news:un**************@tk2msftngp13.phx.gbl...
Why use .NET when you're not forced to. Personally speaking I wish MS had
not bothered converting VB into VB.NET :)

"Truble" <an*******@discussions.microsoft.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?


Jul 21 '05 #13
Amen to that!
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Truble <an*******@discussions.microsoft.com> wrote:
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?


You being able to write a VB6 app twice as fast as you can write the
equivalent in VB.NET doesn't mean that VB.NET isn't as efficient - it
may well just mean that you're more proficient in VB6.

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

Jul 21 '05 #14
C# and VB.NET are virtually identical if Option Strict is on. Is your
VB.NET app compiled with Option Strict? Everythign I've read said the
differences aren't worth citing, but I'd be interested in finding out if
there are cases where they aren't? What type of app is it?
"BGD" <tb******@hotmail.com> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...
I disagree. I have been using VB since the first beta was released more than 12 years ago and I love the changes and the fact that it is now a true
object oriented language. I also program in Java, C++ and Delphi, and I
always wished that VB had the object oriented features that the other
languages did, and now it does!

I do most of my programming in C# now and it is a great language. In most
programs C# and VB.NET perform about the same, but I have some application
where C# clearly performs better. It is a matter of chosing the right
tool/language for the right project...
"Truble" <an*******@discussions.microsoft.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?


Jul 21 '05 #15
I think that it is great - but I wish the package and deployment wizard was there.
Jul 21 '05 #16
There is even somthing better than this wizard: Setup Projects! Just add a
new Setup project to your solution, and you can get the same result as the
Package and Deployment wizard (only better :-).

--
Greetz,
Jan
__________________________________
Read my weblog: http://weblogs.asp.net/jan
"Scoooty" <an*******@discussions.microsoft.com> schreef in bericht
news:01**********************************@microsof t.com...
I think that it is great - but I wish the package and deployment wizard

was there.
Jul 21 '05 #17
Yeah, the excellent P&DW.
With so big drawbacks that it can be used on simple projects only.

--
Miha Markic - RightHand .NET consulting & development
miha at rthand com

"Scoooty" <an*******@discussions.microsoft.com> wrote in message
news:01**********************************@microsof t.com...
I think that it is great - but I wish the package and deployment wizard

was there.
Jul 21 '05 #18
Wait till homeland security kicks in ...

"William Ryan" <do********@comcast.nospam.net> wrote in message
news:eM**************@tk2msftngp13.phx.gbl...
Unless you live in a communist country, you aren't forced to do anything,
let alone code in a specifc langauge.


--
Miha Markic - RightHand .NET consulting & development
miha at rthand com
Jul 21 '05 #19

"Truble" <an*******@discussions.microsoft.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?


Because you're proficient in VB6, and not in VB.NET?
Am I sensing a little resistance to change here?
Bad place to be in the technology business. :-)
Jul 21 '05 #20

"Truble" <an*******@discussions.microsoft.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?


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
Jul 21 '05 #21
Sounds like we've got challenge on our hands (and too much time ;)

How about a stupid wee challenge then? You write a *small* app in VB6 and
I'll try and replicate it in VB .net.

For VB6 to be "better" than VB.net it must meet the following criteria:

1) It must demonstrate a clear performance advantage (i.e. > 20%)
2) It must be half the size of the .net version

I don't think these criteria ar harsh - after all, you claim that you can
write one that is twice as fast and 1/10th the size!

Best Regards,

Trev.
"Roger" <NO****@hotmail.com> wrote in message
news:ul**************@TK2MSFTNGP12.phx.gbl...

"Truble" <an*******@discussions.microsoft.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?


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

Jul 21 '05 #22

"Codemonkey" <hu*********@hotmail.com> wrote in message
news:eh**************@tk2msftngp13.phx.gbl...
Sounds like we've got challenge on our hands (and too much time ;)

How about a stupid wee challenge then? You write a *small* app in VB6 and
I'll try and replicate it in VB .net.

For VB6 to be "better" than VB.net it must meet the following criteria:

1) It must demonstrate a clear performance advantage (i.e. > 20%)
Win98/ 64 meg, OK :-)
2) It must be half the size of the .net version

I'm counting the runtime.
I don't think these criteria ar harsh - after all, you claim that you can
write one that is twice as fast and 1/10th the size!

Best Regards,

Trev.
Why is everyone picking on Truble? I dont actually use VB6 but somebody's
got to take his side.

HTH,

Roger


"Roger" <NO****@hotmail.com> wrote in message
news:ul**************@TK2MSFTNGP12.phx.gbl...

"Truble" <an*******@discussions.microsoft.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?


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


Jul 21 '05 #23

"Roger" <NO****@hotmail.com> wrote in message
news:ul**************@TK2MSFTNGP12.phx.gbl...

"Truble" <an*******@discussions.microsoft.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?
With some editing, the poster is correct:

Visual Studio .NET is not more efficient than VB6.


You can't make a blanket statement like that about anything. But out of
curiosity, why would you say this? VB 6.0 was NEVER known for its
performance or efficiency. Why do you think that MS made most of their apps
in C not VB?

I can write a VB6 App that is at least twice as fast as .NET. (: and 1/10 th the size :-)

This is not a measure of efficiency. The reason VB 6.0 does not requre as
much coding is because it was HDING a lot of cumbersome code in the
background. In some cases, this was helpful (ie. you don't have to worry
about creating an instance of your startup form - VB did it for you). In
many other cases, this is a detrement. What if you wanted to alter the way
VB 6.0 does something that it was HIDING from you? Tough luck, you had to
deal with it.

I'll give you a simple example of this....

If you created a form and placed numerous controls on the form and then at
some point wrote a loop that would iterate over the form's Controls
collection....

The order that the controls would be looked at in the loop would be the
order in which you created them on the form (not their sequential placement
on the form, the sequence was based on what control was CREATED first,
second, third, etc.).

In many cases, developers would use this technique for validating user input
on the form. But it's not very nice if the first control validated is the
6th one down on the form.

In VB 6.0, once the Controls collection is populated, that's it, you can't
alter the sequence of them (unless you delete all the controls and re-create
them or make a control array out of them and re-sequence their Indexes).

In VB.NET all you have to do to change the sequence of the controls is to
look at the line of generated code that adds the controls to the controls
collection (Controls.Add control1, control2, etc.) and re-order the
sequence on that line!

This is but one small example of how, in VB.NET, their may be more code to
deal with, but in return, you get MUCH more control over what is happening
and therefore you can fine tune an application MUCH BETTER than you ever
could before, which results is MUCH BETTER performance.

Also, by having certain general housekeeping functions running in the .NET
Framework, rather than your application (ie. Garbage Collection), your
application doesn't have to have that code in it, which results in more
streamlined programs (the .NET Framework runs in a different thread from the
application you built).

Give .NET a chance. I am a former VB 6.0 / Classic ASP person and I felt
like you did for about 6 months until the "light bulb" went off in my head
and I "got it".

..NET is by leaps and bounds far superior in almost all respects to VB 6.0.

Scott M.

Roger

Jul 21 '05 #24
> Win98/ 64 meg, OK :-)

Shouldn't be too much a problem for a small App. VB6 will have an inital
advantage because of the smaller memory footprint, but once the .net has
been fully JITted, there shouldn't be much difference. Certinly not twice as
slow.
I'm counting the runtime.
And what size are all the VB6 support files when you add them together?
(MSVBVM60.dll etc., etc.) Not as big as the .net framework, but imagine you
had to include all the different support files for simple tasks such as
network communication, database access, graphics, remoting etc. etc.
Granted, not all apps use these features, but it's nice to know that they're
already on a machine if you have to change your application to include them.
Why is everyone picking on Truble? I dont actually use VB6
but somebody's got to take his side.
Nobody's picking on Truble. I'm disagreeing with Truble's point of view ;)
Truble shouldn't make such bold statements without expecting someone else to
disagree and make their own bold statements ;)

Trev.

"Roger" <NO****@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
"Codemonkey" <hu*********@hotmail.com> wrote in message
news:eh**************@tk2msftngp13.phx.gbl...
Sounds like we've got challenge on our hands (and too much time ;)

How about a stupid wee challenge then? You write a *small* app in VB6 and I'll try and replicate it in VB .net.

For VB6 to be "better" than VB.net it must meet the following criteria:

1) It must demonstrate a clear performance advantage (i.e. > 20%)


Win98/ 64 meg, OK :-)
2) It must be half the size of the .net version


I'm counting the runtime.
I don't think these criteria ar harsh - after all, you claim that you can write one that is twice as fast and 1/10th the size!

Best Regards,

Trev.


Why is everyone picking on Truble? I dont actually use VB6 but somebody's
got to take his side.

HTH,

Roger


"Roger" <NO****@hotmail.com> wrote in message
news:ul**************@TK2MSFTNGP12.phx.gbl...

"Truble" <an*******@discussions.microsoft.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?

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



Jul 21 '05 #25
Roger <NO****@hotmail.com> wrote:
1) It must demonstrate a clear performance advantage (i.e. > 20%)


Win98/ 64 meg, OK :-)
2) It must be half the size of the .net version


I'm counting the runtime.


In that case, are you including the VB runtime and anything that links
against in turn? Are you including the operating system itself, and if
so how much of it? It would make sense to do so, given that a lot of
the .NET framework is a load of libraries which most applications won't
use. (Each application will use some of the framework, very few
applications will directly use most of it.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jul 21 '05 #26

"Roger" <NO****@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

"Codemonkey" <hu*********@hotmail.com> wrote in message
news:eh**************@tk2msftngp13.phx.gbl...
Sounds like we've got challenge on our hands (and too much time ;)

How about a stupid wee challenge then? You write a *small* app in VB6 and I'll try and replicate it in VB .net.

For VB6 to be "better" than VB.net it must meet the following criteria:

1) It must demonstrate a clear performance advantage (i.e. > 20%)
Win98/ 64 meg, OK :-)
2) It must be half the size of the .net version


I'm counting the runtime.


The fact that you would say this clearly indicates that you don't yet fully
understand .NET. The .NET Framework (what you call the runtime) is quite
large, but it contains much of what you would have (in VB 6) had to build
into your application.

Now, in VB 6, when you build all that into your application, it would all
need to execute in the same process (thread) and that was always one of VB
6's biggest drawbacks.

The .NET Framework runs in its own process and allows your application to
run in its own process, so it can execute faster. The fact that the
Framework is 24MB isn't relevant, since much of it is the vast class
libraries that are defined there. By the way, you wouldn't have references
to all those libraries anyway, so you can't count the full 24MB of the
Framework in your little experiment. You'd have to find a way to determine
the size of the libraries that you are using.


I don't think these criteria ar harsh - after all, you claim that you can write one that is twice as fast and 1/10th the size!

Best Regards,

Trev.


Why is everyone picking on Truble? I dont actually use VB6 but somebody's
got to take his side.

HTH,

Roger


"Roger" <NO****@hotmail.com> wrote in message
news:ul**************@TK2MSFTNGP12.phx.gbl...

"Truble" <an*******@discussions.microsoft.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?

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



Jul 21 '05 #27
Scott M. <s-***@BADSPAMsnet.net> wrote:
Now, in VB 6, when you build all that into your application, it would all
need to execute in the same process (thread) and that was always one of VB
6's biggest drawbacks.
<snip>
The .NET Framework runs in its own process and allows your application to
run in its own process, so it can execute faster.


Hang on a sec - you need to be very clear on the difference between a
process and a thread. They're quite different things...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jul 21 '05 #28
Quite simple: They didn't.

"Truble" <an*******@discussions.microsoft.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?

Jul 21 '05 #29
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.


"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP***********************@msnews.microsoft.co m...
Scott M. <s-***@BADSPAMsnet.net> wrote:
Now, in VB 6, when you build all that into your application, it would all need to execute in the same process (thread) and that was always one of VB 6's biggest drawbacks.


<snip>
The .NET Framework runs in its own process and allows your application to run in its own process, so it can execute faster.


Hang on a sec - you need to be very clear on the difference between a
process and a thread. They're quite different things...

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

Jul 21 '05 #30
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.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jul 21 '05 #31

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
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.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #32
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.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jul 21 '05 #33
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**************@TK2MSFTNGP11.phx.gbl...

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
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.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too


Jul 21 '05 #34
> 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.com> wrote in message
news:Of**************@tk2msftngp13.phx.gbl...
Quite simple: They didn't.

"Truble" <an*******@discussions.microsoft.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?


Jul 21 '05 #35
<di********@discussion.microsoft.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.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jul 21 '05 #36

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
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 "housekeeping"
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.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #37
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 "housekeeping"
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.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jul 21 '05 #38
One a single CPU does it bloody matter , its stop the world anyway. Geez.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP***********************@msnews.microsoft.co m...
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 "housekeeping"
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.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #39
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.com> wrote in message
news:MP***********************@msnews.microsoft.co m...
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 "housekeeping"
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.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #40
Scott M. <s-***@BADSPAMsnet.net> wrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jul 21 '05 #41
On Fri, 5 Dec 2003 17:39:46 -0000, Codemonkey wrote:
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

--
Chris

To send me an E-mail, remove the underscores and lunchmeat from my E-Mail
address.
Jul 21 '05 #42
> 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.
"Chris Dunaway" <dunawayc@_lunchmeat_sbcglobal.net> wrote in message
news:1u*******************************@40tude.net. .. On Fri, 5 Dec 2003 17:39:46 -0000, Codemonkey wrote:
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

--
Chris

To send me an E-mail, remove the underscores and lunchmeat from my E-Mail
address.

Jul 21 '05 #43
Dan
"Roger" <NO****@hotmail.com> wrote in message news:<ul**************@TK2MSFTNGP12.phx.gbl>...
"Truble" <an*******@discussions.microsoft.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?


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.
Jul 21 '05 #44

"Dan" <da****@sourcekid.com> wrote in message
news:cb**************************@posting.google.c om...
"Roger" <NO****@hotmail.com> wrote in message news:<ul**************@TK2MSFTNGP12.phx.gbl>...
"Truble" <an*******@discussions.microsoft.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?


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.


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

Jul 21 '05 #45

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.