By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,984 Members | 1,423 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,984 IT Pros & Developers. It's quick & easy.

To VB or not to VB?

P: n/a
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?

Jan 5 '06
Share this Question
Share on Google+
62 Replies


P: n/a
"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:%2****************@TK2MSFTNGP09.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..
Jan 24 '06 #51

P: n/a
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..

Jan 24 '06 #52

P: n/a
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

Jan 24 '06 #53

P: n/a
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.

Jan 26 '06 #54

P: n/a
"John Hart [MSFT]" <Jo******@Online.Microsoft.com.> wrote in message
news:Lj**************@TK2MSFTNGXA02.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..
Jan 26 '06 #55

P: n/a
Hi Ken,

"Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:eQ*************@TK2MSFTNGP12.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 "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
Jan 27 '06 #56

P: n/a
"Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
"John Hart [MSFT]" <Jo******@Online.Microsoft.com.> wrote in message
news:Lj**************@TK2MSFTNGXA02.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..
Feb 3 '06 #57

P: n/a
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_Hotmail.com> wrote in message
news:u$**************@TK2MSFTNGP15.phx.gbl...
"Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
"John Hart [MSFT]" <Jo******@Online.Microsoft.com.> wrote in message
news:Lj**************@TK2MSFTNGXA02.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..

Feb 3 '06 #58

P: n/a
Hi Dan...

"Dan Barclay" <Da*@MVPs.org> wrote in message
news:O%****************@TK2MSFTNGP14.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..
Feb 3 '06 #59

P: n/a
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.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.

Feb 4 '06 #60

P: n/a
> <Ma***********@feedback.microsoft.com> wrote
Ease of migration is a huge, huge goal for us -- always has been, and will
continue to be.

Jonathan West wrote: I have to say the evidence for that hasn't been terribly clear. After all,
you allowed VB6 to go off mainstream support before you brought out VS2005,
which you say has migration as its primary mission.


Gotta say -- I love VB.Net as a language, as demonstrated in my
previous
post, but what Jonathan West wrote about migration is right on the
money.
Even the migration from 16-bit Visual Basic to 32-bit Visual Basic
wasn't
nearly as difficult as the migration from VB6 to VB.Net.

What people say about making VB.NET comparable to C# is
understandable. Not all, but most features of C++ and/or C# are
available in
some form in Visual Basic. Meanwhile, there are quite a few features
from
VB6 that are simply gone. For me, control arrays is the most difficult
loss...
some of my VB6 projects that didn't even need to use control arrays,
did
so because there was no reason not to. (For instance, why pick names
for every label on your form? Didn't even think about it until I had
to, when
converting to VB.NET...)

Overall, the language is better than it used to be. But conversion is
much
more important than the Microsoft VB Team seems to think it is, and you
guys dropped the ball on this one.

Feb 4 '06 #61

P: n/a

"Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.com> wrote in message

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!".
They don't understand, and they don't care.
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.


The real problem now is that even if they somehow created a "perfect"
wizard, how can I have confidence that they won't pull this same stunt again
in a release or two. They are NOT through cleaning up the language. They
still don't respect it.

It was a great ride. It's over.

Dan

Feb 4 '06 #62

P: n/a

<al*****@my-dejanews.com> wrote in message
news:11**********************@g47g2000cwa.googlegr oups.com...
: 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;
: }
Yes, as long as there aren't any mutliline statements. The following
statements are not equivalent

if(test == 1)
doThis();
doThat();

if(test == 1)
{
doThis();
doThat();
}
I personally find it irritating to read C# code (or Java or JavaScript) that
doesn't consistently use curly braces. From my perspective it allows for
bugs to be introduced because a programmer inadvertantly fails to allow for
the fact that both lines are to be constrained by the conditional, not just
the first line. When I write in C# (infrequently) or JavaScript (very
frequently), I always use curly braces for just that reason (even single
statements). If I need to add a new statement to an existing code block, I
already have defined the limits of the conditional. If in the example you
offer I needed to also include an additional function call inside for loop
once the second conditional has been evaluated, I'll need to make the
following changes
if(var1 == 1)
for(Index = 0; Index < 11; Index++)
{
if(var2 == Index)
DoThis();
else
switch(var3) {
case "A":
DoThisToo();
break;
case "B":
DoThisInstead();
break;
}
doThisforEachLoop();
}
To do this, I had to spend some effort figuring out just where exactly the
for loop and second conditional statements were finished. That is time
consuming and potentially error prone as I may misread the original code. If
the {} were all ready in placed, the change would have been much simpler and
more likely to be correct the first time out.
: > 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.
Agreed, if you are using intellisense. However, I sometimes bang out code in
a small module using notepad and the vbc or csc compilers. In C#, I have to
make sure I don't screw up my case statements. Further, intellisense only
goes so far and case errors do in fact creep in when using C# that would be
overlooked in VB.
: > 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.
Yes, I agree. In the end, it's what you are used to and comfortable with.
: > (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.
Yes. The different .net languages are very close to one another. I prefer
VB.net in part because I believe it is a better contruct but mostly because
I come vrom a VB6 background. Thanx for the input.
Ralf
--
--
----------------------------------------------------------
* ^~^ ^~^ *
* _ {~ ~} {~ ~} _ *
* /_``>*< >*<''_\ *
* (\--_)++) (++(_--/) *
----------------------------------------------------------
There are no advanced students in Aikido - there are only
competent beginners. There are no advanced techniques -
only the correct application of basic principles.
Feb 5 '06 #63

62 Replies

This discussion thread is closed

Replies have been disabled for this discussion.