To VB or not to VB?

[zacks]

A co-worker where I work is proposing all future code devopment be done
in Visual C#. Here is his assessment of VB:

VB.NET is hack as far as the CLR(Common Language Runtime) goes. It was
retrofited into the .Net framework for those people who simply don't,
and do not care to, understand object oriented programming. Quite a
few of it's (features) were forced into the language through very ugly
means to make it easier for the VB guys to bring in their code. Things
like "static" veriables and functions are called "shared" in VB.NET,
because the keyword static was already used in VB6. VB.NET is loaded
with these kinds of little idiocies.

Any comment?

[Ken Halter]

"Cor Ligthert [MVP]" <no************ @planet.nl> wrote in message
news:%2******** ********@TK2MSF TNGP09.phx.gbl. ..

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.

--
Ken Halter - MS-MVP-VB (visiting from VB6 world) - http://www.vbsight.com
Please keep all discussions in the groups..

[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

Ken Halter - MS-MVP-VB (visiting from VB6 world) - http://www.vbsight.com
Please keep all discussions in the groups..

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

--
This posting is provided "AS IS" with no warranties, and confers no rights.

[Ken Halter]

"John Hart [MSFT]" <Jo******@Onlin e.Microsoft.com .> wrote in message
news:Lj******** ******@TK2MSFTN GXA02.phx.gbl.. .

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.)
--
This posting is provided "AS IS" with no warranties, and confers no
rights.

--
Ken Halter - MS-MVP-VB (visiting from VB6 world) - http://www.vbsight.com
Please keep all discussions in the groups..

[Dan Barclay]

Hi Ken,

"Ken Halter" <Ken_Halter@Use _Sparingly_Hotm ail.com> wrote in message
news:%2******** ********@TK2MSF TNGP10.phx.gbl. ..

"Herfried K. Wagner [MVP]" <hi************ ***@gmx.at> wrote in message
news:eQ******** *****@TK2MSFTNG P12.phx.gbl...

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.

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 "proprietar y" 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]

"Ken Halter" <Ken_Halter@Use _Sparingly_Hotm ail.com> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..

"John Hart [MSFT]" <Jo******@Onlin e.Microsoft.com .> wrote in message
news:Lj******** ******@TK2MSFTN GXA02.phx.gbl.. .

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

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

--
Ken Halter - MS-MVP-VB (visiting from VB6 world) - http://www.vbsight.com
Please keep all discussions in the groups..

[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" <Ken_Halter@Use _Sparingly_Hotm ail.com> wrote in message
news:u$******** ******@TK2MSFTN GP15.phx.gbl...

"Ken Halter" <Ken_Halter@Use _Sparingly_Hotm ail.com> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..

"John Hart [MSFT]" <Jo******@Onlin e.Microsoft.com .> wrote in message
news:Lj******** ******@TK2MSFTN GXA02.phx.gbl.. .

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

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

--
Ken Halter - MS-MVP-VB (visiting from VB6 world) - http://www.vbsight.com
Please keep all discussions in the groups..

[Ken Halter]

Hi Dan...

"Dan Barclay" <Da*@MVPs.org > wrote in message
news:O%******** ********@TK2MSF TNGP14.phx.gbl. ..

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
uses those? <g> In its current condition, I'd classify it as a "Snip
converter" and not much more.
Dan

--
Ken Halter - MS-MVP-VB (visiting from VB6 world) - http://www.vbsight.com
Please keep all discussions in the groups..

[allan_w]

Just to be fair...

_AnonCoward wrote:

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.WriteLI ne instead of Console.WriteLi ne - 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.