Since I've got some of the trolls blocked and can't respond to them
directly, I'll add this here:
http://www.google.com/url?q=http://...result&usg=AFQjCNE6dCe-oU9HY0Sn-dparQZWWzXw2Q
Now, keep in mind that this article/paper was written about the 1.0
framwork.
But, I really think the issue comes down to this.
VB 6 developers who want to move to .NET largely don't believe that they
have to spend the time to start all over and learn .NET from scratch because
they've seen VB .NET code and, at first glance, recognized many of the
language's keywords and come to the conclusion that VB .NET is just VB 6
with new stuff added.
Now, let me take a minute to qualify those statements. I am the
owner/operator of an IT training company and have been training folks from
all kinds of backgrounds (VB 6, COBOL, Java, new programmers) in .NET since
its inception. And, by the way, I myself, was a VB 6 developer/trainer
before .NET came out so I initially grappled with all this myself. I've
seen literally thousands of VB 6 developers move to .NET and honestly 90
somthing percent of them believe that they do not need any training in VB
..NET because of the VB 6 experience they already have.
This is very difficult to try to convince the VB 6 developer that, although
they may have many years of experience with classic VB, they really don't
know very much at all about .NET.
Now, here's where rumors and mis-information begins... Those VB 6 developers
who go off into the VB .NET world without proper instruction obviously start
by writing what they already know. The use MsgBox(), CStr, CLng, CDate, and
all the other code they've come to know and love. And you know what? That
code compiles, which reinforces that person's beliefs that they don't need
training in .NET because they are able to write functioning code.
Now, the next phase of this VB 6 developer's journey to .NET goes something
like this... The developer get's more adventurous and writes something
beyond a "Hello World" application and, much to their suprise the
application runs slowly. Slower, in fact, than it did in VB 6! Yet, since
the code they wrote compiled and does ultimately do the job, they believe
that they have coded the applicaiton correctly.
This is where posts in NG's that VB .NET sucks and runs slower than VB 6
come from. Developer's who haven't taken the time to learn about the
environment that they are working in and are uneducated as to how to code in
..NET properly.
I see this all the time and not just on the individual developer's part, but
with large Fortune 500 companies as well. I can't tell you how many times
I've been called in to figure out why a VB 6 application that was sent
off-shore to be "converted" to VB .NET came back running slower than when it
was sent out. The answer 100% of the time is that the applcation was only
converted to the point that it would compile. Older, antequated VB 6 code
that stull functions, but is not optimal was left in the application.
One of the simplest examples to illustrate this point is this:
[VB 6]
'Collect some data from the outside world
Dim age As Integer
age =CInt(txtAge.Text)
'Convert the data for internal program use
Dim agePlus100 As Long
agePlus100 = CLng(age) + 100
Now, to "convert" this code to VB .NET, you'd find that you don't have to do
anything at all. The code compiles and runs as is! But, the code is not
written properly to efficiently run in .NET. But, how would the VB 6
developer who is just plugging their way through VB .NET going to know that?
They won't. As far as they can tell, the code is correct because it compiles
and runs.
But, with a further understanding of how .NET works, we can see that this
code causes an unnecessary boxing and unboxing operation on the heap as well
as creating an unecessary object in memory.
Value types (Integers) are stored in .NET managed stack of memory, while
Reference types (objects and other class instances) are stored on the
managed heap.
The CLng() function accepts an "object" parameter in .NET, meaning that the
age parameter (which is already a value type of Integer and stored on the
stack with 4 bytes of memory) will be "boxed" up into an "object" type and
stored on the heap. This means that the data is now on the stack and the
heap and an extra object has been created in the process. But, wait it gets
better....
Now that the input (age) has been placed into an object on the heap, the
conversion can take place whcih results in a Long Integer being creaed on
the stack (8 bytes) and the data from the heap object is copied into it.
So, to get to the desired Long Integer, we have to create memory on the
heap, copy data over to it then copy data out of it and put the data into a
Long on the stack.
But, to do this properly and effectively in .NET, you shouldn't be using the
VB 6 conversion functions at all. You should write:
[Proper VB .NET]
'Collect some data from the outside world
Dim age As Integer
Dim result As Boolean = Integer.TryParse(txtAge.Text, age)
'Convert the data for internal program use
If result then
Dim agePlus100 As Long = Convert.ToInt64(age) + 100
End If
This is just one simple example of how applications written using VB 6
coding cause poor results and create a bad impression of how it performs.
There are MANY MANY other situations similar to this.
The fact is that, given proper instruction and understanding of how to code
agains the .NET Framework (not how to write VB .NET), you will create
efficient and effective code.
-Scott
