To VB or not to VB?

[Ken Halter]

Another great feature would be one that replaces a predefined set of VB6
classes with dotNet classes that do exactly the same thing. For example, I

The more I think about this one, the more I like the idea. Since we're
focusing on code re-use (Right?!!!), I think it would be an excellent
feature. Sounds extremely simple too.

First Pass...
Scan project for known classes
If any are found, simply swap them with the matching dotNet class
and
mark that part of the project "done" to the wizard. No need for the
Wizard to rescan this part of the project.
Second Pass...
Run the wizard in "normal" mode, checking for classes replaced by the
first pass, so they can be skipped.

Done. Far fewer reported errors and warnings, true code reusability,
everyone wins. End of story <g>

 

[Ken Halter]

feature. Sounds extremely simple too.

Just as I thought <sigh>... Posting suggestions for dotNet from an "Actual
VB6 developer" is like talking into a vacuum. HUGE waste of time because the
direction dotNet's taking has already been set in stone so, as a VB6
developer, our "suggestions" are nothing more than something for the dotNet
product team to print out and use as toilet tissue.

The sudden drive to get VB6 devs to use B# is purely a marketting ploy to
get people to buy dotNet. What they do with it once they've shelled out the
money, is their problem. Code re-use.... HA! Wizard..... HA!

 

[Cor Ligthert [MVP]]

Ken,

Just as I thought <sigh>... Posting suggestions for dotNet from an "Actual
VB6 developer" is like talking into a vacuum. HUGE waste of time because
the direction dotNet's taking has already been set in stone so, as a VB6
developer, our "suggestions" are nothing more than something for the
dotNet product team to print out and use as toilet tissue.

I disagree this completely with you. In my opinion is there now to much in
VB.Net what would not be there if there was not that big VB6 advocacy, which
seems for me extremely stronger than the Linux one.

At least I am not very lucky with some of the so called improvements in
version 2005 which becomes because of this advocacy, which have helped to
improve VBNet with the at least not always logical behaviour of VB6, without
that they knew anything from VB.Net.

Every developer knows in advance what it the result of these kind of
improvements. However the VB6 avocacy is strong.

Just my opinion.

Cor

 

[Ken Halter]

Ken,


I disagree this completely with you. In my opinion is there now to much in
VB.Net what would not be there if there was not that big VB6 advocacy,
which seems for me extremely stronger than the Linux one.

At least I am not very lucky with some of the so called improvements in
version 2005 which becomes because of this advocacy, which have helped to
improve VBNet with the at least not always logical behaviour of VB6,
without that they knew anything from VB.Net.

Every developer knows in advance what it the result of these kind of
improvements. However the VB6 avocacy is strong.

Just my opinion.

Cor

Well... I can't count the number of times I've seen an MS employee say "post
your ideas" and, when we do, they're completely ignored. The problem with
most of the "improvements" as far as VB6 migration goes, since VB6 has
always been "just a toy" to MS and no one there used it for any reasonable
amount of time, they're implementing features they "assume" VB6 developers
want (can't seem to provide a decent immediate window or single procedure
view though).

So, what you're saying is, B# is getting worse as a result of these
"improvements" eh? That doesn't surprise me at all. VB6 compatibility isn't
just some band-aid you can simply paste on top of a framework to please VB6
developers. Personally, I have 10s of thousands of lines of code that are
instantly broken by dotNet. Since most of my projects include several
classes that perform the exact same thing, no matter what project they're
in, I thought it would be a good idea to feed those through the "wizard" and
never have to deal with them again. If that "wizard" found one of those
"pre-converted" classes, it could simply swap one file for another, instead
of parsing the class and reporting tons of errors every single freaking time
it comes across one of these exact same classes in a project.

Since B# is a completely new language, it should never have been called "VB"
in the first place. If only they'd have been honest, we wouldn't be having
these issues today, at all. VB6 support in B# could've been completely
dropped.

NET Software Legend Juval Lowy agrees with that too, saying the only thing
VB6 has in common with VB.Net is the letters "V" and "B" in their names. You
can hear that in the following podcast....

VB6 Glass Ceiling
http://blogs.duncanmackenzie.net/duncanma/archive/2005/10/28/3148.aspx

 

[Herfried K. Wagner [MVP]]

Cor,

I disagree this completely with you. In my opinion is there now to much in
VB.Net what would not be there if there was not that big VB6 advocacy,
which seems for me extremely stronger than the Linux one.

At least I am not very lucky with some of the so called improvements in
version 2005 which becomes because of this advocacy, which have helped to
improve VBNet with the at least not always logical behaviour of VB6,
without that they knew anything from VB.Net.

Unfortunately that's not what people were asking for. There are only very
few (mainly in the VB.NET team) who think that faking VB6 in VB.NET by
introducing some phantom features is a good idea. Personally I think that
VB6 must have a future -- managed or not -- and VB.NET should not be
crippled by introducing features known from VB6 such as referring to default
instances using a form's class name. The latter won't solve the migration
problem. It's a bait for former VB6 developers and managers who are made
think that VB 2005 is the new VB6. Even dropping the ".NET" from the
programming language's name perfectly fits into this schema.

 

[Jonathan West]

Hi John,

I'd be grateful if you could respond to my last reply to Matt Getz in this
thread, and carry on with the questions he felt unable to answer.

 

[Ken Halter]

Unfortunately that's not what people were asking for. There are only very
few (mainly in the VB.NET team) who think that faking VB6 in VB.NET by
introducing some phantom features is a good idea. Personally I think that
VB6 must have a future -- managed or not -- and VB.NET should not be
crippled by introducing features known from VB6 such as referring to
default instances using a form's class name. The latter won't solve the
migration problem. It's a bait for former VB6 developers and managers who
are made think that VB 2005 is the new VB6. Even dropping the ".NET" from
the programming language's name perfectly fits into this schema.

I agree 100%. B# could've just taken off in it's own direction if it were
called anything other than "VB". It would've been better for everyone
involved. MS could still sell dotNet with its "super duper version of
'basic'" and VB6 users could be running VB6 with bug fixes in place.

 

[Cor Ligthert [MVP]]

Ken,

You have often written in this newsgroup VB.Net is not VB6.

Although I don't agree that completely with you, have I always agreed in the
context as you wrote this and given no comments.

Let I try an analogy.

English is a complex of languages that inherits most from North Sea
languages. Therefore it is a Germanic language. However it has implemented a
lot from other languages but mostly French. Other members of those North
Sea languages are Danish, Dutch and Fries, however you probably cannot speak
one of those languages.

In my idea is VB.Net is an apart member from the family of VB languages.

However just my idea.

Cor

 

[Cor Ligthert [MVP]]

Herfried,

Unfortunately that's not what people were asking for. There are only very
few (mainly in the VB.NET team) who think that faking VB6 in VB.NET by
introducing some phantom features is a good idea. Personally I think that
VB6 must have a future -- managed or not -- and VB.NET should not be
crippled by introducing features known from VB6 such as referring to
default instances using a form's class name. The latter won't solve the
migration problem. It's a bait for former VB6 developers and managers who
are made think that VB 2005 is the new VB6. Even dropping the ".NET" from
the programming language's name perfectly fits into this schema.

We agree for 100% in this.

Cor

 

[Ken Halter]

Ken,

You have often written in this newsgroup VB.Net is not VB6.

Although I don't agree that completely with you, have I always agreed in
the context as you wrote this and given no comments.

Let I try an analogy.

English is a complex of languages that inherits most from North Sea
languages. Therefore it is a Germanic language. However it has implemented
a lot from other languages but mostly French. Other members of those
North Sea languages are Danish, Dutch and Fries, however you probably
cannot speak one of those languages.

In my idea is VB.Net is an apart member from the family of VB languages.

However just my idea.

Cor

You're 100% right about the fact that I can't speak any of those languages.
Thing is, no one's trying to sell Dutch as an upgrade to the English
language ;-) Since Dutch (and the rest) are completely different (including
their names), I'd expect completely different rules to apply. Wouldn't want
English to suddenly become "no longer supported"

 

[Ken Halter]

Ken,

You have often written in this newsgroup VB.Net is not VB6.

Although I don't agree that completely with you, have I always agreed in
the context as you wrote this and given no comments.

Cor....

btw... I'm not a troll. I really don't come here looking for "anti dotNet"
ammo. You might be surprised at the number of snips I've picked up here that
have been tucked away for later. It's just that some of the posts I read
here are just so darned frustrating and I've read so many in a row that I
can't resist "lashing out" at one or two once in a while. I wouldn't be
surprised if it were a 1/1000 ratio for "complaints" vs "posts read". I
dunno... maybe it's the redneck in me or something <g>.. and, if anyone's
wondering why I never post questions, that's easy. Google Advanced Groups
Search. Which also explains why no one sees me post questions in the VB6
groups. Out of the 25k (after google cleaned house) posts I've authored,
only one or two are questions.... and, iirc they remained unanswered.

I'm doing to VB2005 what I did to VB3/5 back when I started using those
languages.... which is... read as many posts as I can, tuck everything away
that looks useful (whether I think I'll ever need it or not) and,
eventually, start answering questions. Trying to answer questions must be
one of the best learning tools there is. Some of them take you to places you
would never have gone and you end up grabbing completely unrelated, but very
useful links along the way. The lessons learned are even more valuable when
you consider that the problem you're trying to solve is a "Real World"
problem that someone really has, opposed to some lab experiment in a class
room.

Still.... I'd like to see comment on the wizard idea. Seems that I have a
gift when it comes to killing a thread involving anyone from MS. If the
ideas I provide are stupid, let me know, for pete's sake, and I'll stop
submitting ideas. There is a substantial time penalty involved with my
typing, especially when it's spent talking into a vacuum. I still want a
real immediate window and single proc view... thinking of making that part
of my sig here ;-) ... heck... at this point, I'd settle for any window in
the IDE (besides a code window) that would accept a block of text (and leave
it as a block of text, untouched). Now, I have UltraEdit open at all times
just to give me what I need. What a P.I.T.A that is.

 

[Cor Ligthert [MVP]]

Ken,

You're 100% right about the fact that I can't speak any of those
languages. Thing is, no one's trying to sell Dutch as an upgrade to the
English language ;-) Since Dutch (and the rest) are completely different
(including their names), I'd expect completely different rules to apply.
Wouldn't want English to suddenly become "no longer supported"

--

Strong reply. After writing my message I saw that it included, that I did
agree in a way with the petition, for which I was against. Now I am thinking
about it because of your comments about the upgrader. I can not speak about
it. I found the 2002 version trash, than I got the 2003 which was much
better and expected that the 2005 one would be even more better. I am now in
doubt because of your comments.



Dutch is absolute not completely different from English. That is different
with languages as Chinese and even French.

Cor

 

[Cor Ligthert [MVP]]

Ken,

I know what you write and surely don't see you as a troll, I know what you
stend for and that gives me forever respect for another.

You don't see often comments from me on your messages, while I do that on
others what I wrote see as VB6 advocacy messages.

Still.... I'd like to see comment on the wizard idea. Seems that I have a
gift when it comes to killing a thread involving anyone from MS. If the
ideas I provide are stupid, let me know, for pete's sake, and I'll stop
submitting ideas. There is a substantial time penalty involved with my
typing, especially when it's spent talking into a vacuum. I still want a
real immediate window and single proc view... thinking of making that part
of my sig here ;-) ... heck... at this point, I'd settle for any window in
the IDE (besides a code window) that would accept a block of text (and
leave it as a block of text, untouched). Now, I have UltraEdit open at all
times just to give me what I need. What a P.I.T.A that is.

I think that you would write it more in this way, without consequently
telling that VB6 is better, what guys who use VBNet absolutely disagree with
you so general written. Maybe you mean it only for parts, we (at least I)
get the idea that persons who write this tell that VB6 is completely better
than VBNet.

Cor

 

[John Hart [MSFT]]

Sorry Ken I'm not ignoring your ideas or anyone else that has an idea on
how we can improve the Upgrade Wizard.

I just have not had a chance to come back out here for a few days.

I do like your idea of having the Wizard interact with the user during the
upgrade. I will say the current architecture of the tool makes it difficult
for us to easily accomplish that.

If we were able to create these snippets of replacement code samples would
that be a step in the right direction?

Also currently we do have a few items in our compatibility library
(including Control Arrays) that we upgrade to. Is this the type of .Net
classes that you're thinking about?

Please keep your ideas coming! I really apperciate it. I'm not going to
ignore them - really.

 

[Ken Halter]

Sorry Ken I'm not ignoring your ideas or anyone else that has an idea on
how we can improve the Upgrade Wizard.

I just have not had a chance to come back out here for a few days.

I do like your idea of having the Wizard interact with the user during the
upgrade. I will say the current architecture of the tool makes it
difficult
for us to easily accomplish that.

I guess we need a "Next Generation" or "Pro Version" tool ;-)

If we were able to create these snippets of replacement code samples would
that be a step in the right direction?
Definitely.

Also currently we do have a few items in our compatibility library
(including Control Arrays) that we upgrade to. Is this the type of .Net
classes that you're thinking about?

Well.. the way we structure things around here is... for just about
everything we do, we have a DLL (or 50 <g>) that exposes classes that do the
work. That makes it easy for us to (for example) communicate with another
app. All the "base" app knows is that it is using a class named XYZ that
exposes certain methods that allow apps to communicate. The underlying code
is where "the magic" takes place so, the "base" app couldn't care less
whether the app we need to communicate with is on the local PC or somewhere
around the world, using named pipes, TCP-IP, Serial, whatever, the "base"
app couldn't care less..

So, since we've been working on this codebase since VB3 was released, we
have a huge library of these DLLs (and quite a few "drag and drop" type
classes).

What I'd like to see is....

We'd run one of those DLLs through the migration wizard and fix all
problems. Now we have a .Net compatible version of that library.

The next time we try to run a project through the wizard (project ABC), and
that project references a DLL we've already converted (XYZ.dll to
XYZ.Net.dll), "somehow" we tell the wizard to replace all references to
XYZ.dll with references to XYZ.Net.dll... and since the wizard "knows" that
XYZ.Net.dll is already debugged and ready for use, instead of doing alot of
extra work, trying to setup interop with the old COM dll we'll never use in
..Net and show a bunch of errors and warnings, it spends that time elsewhere
in the project. When it's done, the new warnings would simply show the
syntax differences between the new/old dlls (things like.... attempting to
cast to the wrong type, too many arguments, not as many as needed, etc, etc,
just like a line of code calling into the framework that's not structured
correctly). At that point, we'd fix those lines, and any new warnings
resulting from the new migration attempt (project ABC), and, hopefully,
we'd be off and running.

Basically the same thing applies to "drag and drop" classes. We might be
able to get away with "snips" to replace those. As long as there was a way
to tell the Wizard that A) the snip exists and B) the snip is supposed to
replace all reference to the "drag and drop" class it replaces.

I have to say, if we were talking about a VB3 to VB6 migration wizard that
had this functionality, I could write it myself. Since I'm not familiar with
the framework and it would mean I'd have to start from scratch and build my
own wizard (since I can't add to the one that's shipped with VSnet), it
would take many months to create. If it were some wizard that replaces VB6
dll references and classes with an alternate set of VB6 dll references and
classes, I could probably knock it out in a few days or a couple of weeks at
the most. In fact, I've written a "bare bones" app that does just that, and
we used it when we went from VB5 to VB6. It worked almost exactly like the
V5 to V6 common controls replacement wizard we ran to update common controls
5 to common controls 6 (article link below... link to actual utility is
broken)... which basically replaces references and leaves it up to you to
worry about the specific syntax... which wasn't really an issue from VB5 to
VB6.

PRB: Upgrade Project to Use New VB6 Controls
http://support.microsoft.com/kb/190952/en-us

Please keep your ideas coming! I really apperciate it. I'm not going to
ignore them - really.

Now, I'm off to see why I can't get anything to run in VS'05 (I'm pretty
sure it's just a config issue... but which one? Oh well.)

 

[Dan Barclay]

Hi Ken,

I agree 100%. B# could've just taken off in it's own direction if it were
called anything other than "VB". It would've been better for everyone
involved. MS could still sell dotNet with its "super duper version of
'basic'" and VB6 users could be running VB6 with bug fixes in place.

I disagree with that.

MS sold us VB (and the DOS Basic products before that) as tools for
development of serious products. We bought into that, despite the fact that
it clearly was a "proprietary" language. For many years, with some
glitches, they delivered.

The problem is *not* what "other" languages they put on .Net. The problem
is that there is no ClassicVB on .Net. They could have B# there, and called
something else, or even *nothing* there and it would be the same.

MS has erected a barrier in front of the largest number of developers they
have in any segment. That is the core problem.

Now, having painted "screw you" on the wall by the VB.Net team didn't help
anything for sure. But, that' s NOT the core problem.

It is, in fact, easier to move much existing code to Delphi. I'm not here
to sell you on doing that but that's what we're doing, and when we do get
ready to deploy .Net apps we'll be using the same code in both native and
..net environments so we can continue our native apps and libs.

I want to scream (or cry) when I think of what VB *could have been*.

Later,
Dan

 

[Ken Halter]

Well.... the cobwebs are really getting thick on this thread. I guess that,
once again, I've managed to kill a thread involving an MS employee. My new
sig should be "Thread Terminator".

 

[Dan Barclay]

Nope, it's not you. Just looking at the dates I think maybe I previously
had the last post.

The real problem is that they can't answer simple questions because the
answers they have don't make any sense. They act like they're going to
provide some important insight into this issue, then they just disappear in
a puff of smoke.

Dan

 

[Ken Halter]

Hi Dan...

Nope, it's not you. Just looking at the dates I think maybe I previously
had the last post.

Whew <g> I was starting to get a complex here <g> Reading your last post, I
have to say, I wish I had a choice when it comes to programming environments
we use here at work. I'm a lone survivor in the VB dev dept here. There were
7 when I started. All other devs here are "C guys" and have fallen in love
with the C# language (they love the language itself, the platform and the
way it's implemented is still up in the air, as far as opinions go).

The real problem is that they can't answer simple questions because the
answers they have don't make any sense. They act like they're going to
provide some important insight into this issue, then they just disappear
in a puff of smoke.

One quote from John struck me....

<quote>
I do like your idea of having the Wizard interact with the user during the
upgrade. I will say the current architecture of the tool makes it difficult
for us to easily accomplish that.
</quote>

I have to say, I don't have much sympathy for keeping "the current
architecture". I mean, sheesh.... look at the amount of work it takes >us<
to migrate a simple app. The man hours spent on a decent migration tool is
time well spent, no matter how you look at it. If it takes a year to
re-write... but saves the end user a "man century" in their migration
attempt, I'd say "Go for it!".

I guess the wizard does "Ok" for the "Out of the box" code/controls but who

 

[allan_w]

Just to be fair...

If var1 = 1 Then
For Index = 0 to 10
If var2 = Index Then
DoThis
Else
Select Case var3
Case "A"
DoThisToo
Case "B"
DoThisInstead
End Select
End If
Next
End If

compared to:

if(var1 == 1){
for(Index = 0; Index < 11; Index++){
if(var2 == Index){
DoThis();
}else{
switch(var3){
case "A":
DoThisToo();
break;
case "B":
DoThisInstead();
break;
}
}
}
}


I personally like the VB examples as being cleaner and easier to read - the
curly braces in particular can be very confusing when you have deeply nested
logic. VB isn't without its difficulties in this respect, but at least you
can more quickly know if you're looking at the close of an IF-THEN block or
a SELECT-CASE block.

But in C# most of those braces are optional. You could just as easily
have written

if(var1 == 1)
for(Index = 0; Index < 11; Index++)
if(var2 == Index)
DoThis();
else
switch(var3) {
case "A":
DoThisToo();
break;
case "B":
DoThisInstead();
break;
}

But of course that is a purely subjective opinion based
on years of experience with VB versus C or its derivatives. C++ or Java
programmers would likely prefer the C# examples.

Yes, I agree.

Further, the VB compiler is tolerant of the occasional wrong use of case
(e.g.: for Index as integer = 0 to 100 complies without issue, just as it
should). Sometimes, knocking out some quick code as a test is helpful. You
can dispense with worrying about caps in VB - but C# (and C/C++ and Java)
throw a fit if you type Console.WriteLIne instead of Console.WriteLine - how
ridiculous is that?

But Intellisense makes this unlikely... in either language, you'd type
Console.W, and use the up-and-down arrows to select WriteLine.

Another problem with case sensitivity is that it can lead to the
introduction of hard to find bugs. For example, say you have two variables
myVar and myvar in a C# function. It is easy to accidentally type myvar when
you meant myVar (and vice versa) and locating the inappropriate variable
name can waste time that a VB coder doesn't have to worry about.

Sure, but the opposite problem exists with VB... if I try to declare
two variables myVar and myvar in VB, I get an error:
Local variable is already declared in the current block.
It's all a matter of mindset. To be a good VB programmer, you have
to think in VB; to be a good C# programmer, you have to think in
C#. If a VB programmer thinks in C#, then even after all of the syntax
and logic errors have been fixed, the code will "look" wrong... and
vice-versa.

(And let's
not even discuss how many times using = instead of == in logical compares
causes hours of wasted man hours trying to figure out why a function isn't
working correctly...)

Yeah, that can be a problem.

When all is said and done, VB.net and C# are just languages - each do pretty
much the same things. Both languages bring strengths and weaknesses to the
table and neither is inherently better than the other - it usually comes
down to personal preference as to which language is used.
Yes.

Frankly, it sounds like your co-worker is a language bigot.

But this is nothing new. Ever since there were two "high-level
languages" (COBOL and Fortran), there have been people sneering
at others who used the "wrong" language. They were wrong then,
too.

Back in the days of Visual Basic 3, the choice between the two
languages was much more fundamental. There was a basic
tradeoff -- VB was considered by most knowledgable people to
be the "Rapid Development" system because it was easy to
throw a few controls onto a form and wire them together. But
VB programs loaded and executed much more slowly. If your
program had to load and run quickly or use fewer resources,
or if you wanted to accomplish things that couldn't be done in
VB, then C++ was the way to go. On the other hand, it usually
took a lot longer to get a C++ program written and debugged.

This distinction is gone now. Almost every significant
capability in either language has been added to the other,
and they now have the same back-end (.NET). There are
probably a few exceptions, but for most business programs,
developers knowledgable in either language should take
about the same amount of time to develop and debug the
program, and they should be virtually identical when running.
This is excellent for managers -- they can now pick a language
based on what type of talent they have available, rather than
having to do research about which development environment
is more appropriate and then searching for someone competent
in that language.