Which to use VB.NET or C#?

[Guest]

I also get some of the key words mixed-up between languages myself.

Most .NET books I have only have one language in them. Wish they did have
both. Seems they like having 2 different books Why? Will some by both? Just
more publishing hassles it seems to me...

I still think the IDE is better for VB. You may not notice them as much for
small book projects, you may need to play closer attention. Anyway I deal in
real-world projects mostly.

Seems C# always wants you to press the CTRL and SPACE where VB just knows
when to help, most help due to the VB syntax I think.

The Auto complete is better: look at places where you use enumerations. VB
pops them up for you. C# even makes you type the true/false when VB does not..

C# always wants the () when calling subroutines, even tells you they are
missing, but is too lazy to add them for you. But VB does it for you.

Case sensitive is a waste, promotes bugs, and has no real value. I like
watching VB redo my case to match my declares, confirms my memory.

Auto complete and formatting in VB is nice, I even hear C# developers say
this. In fact you can get VS Addins to improve this in C#.

Background compiler is great with multiple projects. I can change a property
and see the errors in the other projects, in C# it seems like I'm always
compiling then again if I get the order wrong.

If you are missing a {} somewhere the Syntax checker gets all screwed up in
C# and context help may no-longer work until fixed. The {} are just not as
clear a read as For Next End IF to me it really bugs me when they are close
together.

C# requires the object constructor be named the same as the class. So when I
rename a class I need to redo all my constructors. VB has New().

Select case is better and simpler.

Events in C# are a pain, if you remove the event sub, you then need to go
all the way to the top to remove the designer added code for the handler. In
VB I just remove the subroutine.

C# I must go to the property tab to auto-generate an event stub. In VB I can
do it right inside the code window dropdowns.

Navigation for Interfaces, methods sticks in C#, always goes to wrong
interface or wrong overload method.

The syntax for Inherited classes and implemented Interfaces is bad. Unless
you name them in correctly it can be confusing. Also calling base methods is
weird.

A lot of the project properties screens in the IDE have small differences
also, don’t remember my issues there right now.

VB allows developer to create any overrides by using the dropdowns in the
code window, similar to the way done for events. Save the trouble knowing the
exact syntax for the method.

C# does not enforce CLS compliant code as a default. Also find it annoying
to find objects with public and privates different only by case.

Maybe there are ways to solve these little things in C#, if so someone tell
me! Anyway why can’t they both do all these things? Seems a lot of the
differences a pointless.


http://support.microsoft.com/?kbid=308470
http://www.harding.edu/USER/fmccown/WWW/vbnet_csharp_comparison.html


Eric Schneider

 

[Kevin Spencer]

I always thought this is one of many typical sites for twenty somethings,

a nerdy type only, not for daddy types. Why are you still messing around
here at your age ? I projected myself to pickup newspaper to read when I
get to your age, every day... walk to McDonald have a coffee and reading
morning paper. Possibly go fishing....

At the age of 20, you have had 20 years of life experience, and have no
ability to predict with any accuracy what to expect at age 25 (which will be
1/4 of your current life span), much less age 50. 50 years old seems ancient
to you, as you see life from a current perspective of an entire lifetime
less than half that span of years. Therefore, while a 50-year-old can
certainly make predictions regarding probablities for a person of your age,
and with some 50 years worth of life experience and knowledge to add to the
precision of such predicions. In other words, your "always" didn't even
exist when Jesse was 29 years old, and your "always" represents less than
half of Jesse's life time and experience.

I will be 50 in 5 months, and still have a lot to learn, even though I've
always been ravenous for knowledge, and fed myself as much as I could
throughout my lifetime. But I have learned a few things. The average human
lifetime is a very long time, and the average human goes through an
incredible number of changes internally and externally in that span of time.
Nothing is certain, and trying to imagine what one's life will be like in
just 5 or ten years is an exercise in futility.

At the age of 20, a 50-year-old seems like a codger to many young people,
perhaps. But most humans don't really come into their personal place of real
power until around that age. The first 30 or so years of one's life is
merely preparation. Garaduating from high school is the beginning of one's
formal education. Graduating from college is merely the end of one's formal
education. The real school starts when one begins to participlate in the
world. And anyone in their 20s is basically a freshman in that school.

The average age of a Sentor, or President is in the 50's. The average age of
a CEO or CTO is in the 50's. The average age of anyone successful is in the
50's. Bill Gates is 50. Steve Balmer is somewhere around 50. In other words,
the people that run the world you've just started to play in are in their
50s. It is something to look forward to, and work towards, that is, if you
don't want to end up sitting in a McDonalds somewhere and drinking a cup of
coffee. Or fishing.

And remember that fruit is always at its sweetest and ripest shortly before
it falls.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.

 

[Jon S via DotNetMonster.com]

WELL SAID! and I'm in my early 20's.

 

[Jon S via DotNetMonster.com]

And to add I'm glad Jesse passes his wealth of experience (via books which
I've got) to freshman like me.

 

[Kevin Spencer]

Well, d**n, Jon, I wish I had that kind of wisdom when I was in MY 20's! :-D

--

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.

 

[Jesse Liberty]

You too? I just thought I was getting old. Really, it would be great if the
next VS had a feature to fix that for you.

 

[Jesse Liberty]

I have two very impolite words in response.



--

 

[Brendan Reynolds]

It's the concatenation operator that keeps tripping me up - I'm constantly
trying to write "a string" & " of text" in C#! :-(

BTW: I'm just five years behind you!

 

[Jesse Liberty]

I can answer some of your (rhetorical?) questions from personal experience,
though I'm worried this is turning into a religious rahter than a technical
debate.

Most .NET books I have only have one language in them. Wish they did have
both. Seems they like having 2 different books Why? Will some by both?
Just
more publishing hassles it seems to me...

Some readers really liked that we did two books in both VB and C#, many
others complained that it bloated the book, and we've moved away from doing
so.

Anyway I deal in real-world projects mostly.

Not me, I deal in virtual world projects <smile>. I spend 90% of my time in
real world projects and have just not run into your experience, but that is
why they make chocolate and vanilla.

Seems C# always wants you to press the CTRL and SPACE where VB just knows
when to help, most help due to the VB syntax I think.

Sorry, don't know what you mean? Ctrl-space?

The Auto complete is better: look at places where you use enumerations. VB
pops them up for you. C# even makes you type the true/false when VB does
not..

Not my experience; Intellisense in C# does know about enumerations (though
you must use the enumeration name and then it pops up the possible values,
and that is how it should work) and when a Boolean is possible, it offers a
menu of true/false.

C# always wants the () when calling subroutines, even tells you they are
missing, but is too lazy to add them for you. But VB does it for you.

I think we're getting into trifles here, but the advantage of not putting
them in for you is if you've overloaded the method, you could well be
introducing a bug by assuming you want the one with no arguments.

Case sensitive is a waste, promotes bugs, and has no real value. I like
watching VB redo my case to match my declares, confirms my memory.

I agree. I'd like to see an option (defaulting to off) in VS that treats
case fixing in C# the way it does in VB, but there are some advantages to
case sensitivity, specifically the construct

class foo
{
int myAge;
public int MyAge { get { return myAge; } set { myAge = value; } }
}

And note that properties are much better in C#, they look to the client like
fields, to the developer like methods which is just how it should be. (My
aren't we squabbling over trivialities).

Auto complete and formatting in VB is nice, I even hear C# developers say
this. In fact you can get VS Addins to improve this in C#.

In fact, both are in VS 2005 for C#

Some folks like braces (easier to type) some folks like the more verbose VB
style. My point is that there is no objective reason to prefer one over the
other; it is a personal, aesthetic decision.

-j

 

[Jesse Liberty]

Ah, I can solve that for you; I believe + works in both!


Sub Main()
Dim word1 As String = "Hello "
Dim word2 As String = "World"
Dim word3 As String = word1 + word2
Console.WriteLine(word3)
End Sub

 

[Kevin Spencer]

C# always wants the () when calling subroutines, even tells you they are

I think we're getting into trifles here, but the advantage of not putting
them in for you is if you've overloaded the method, you could well be
introducing a bug by assuming you want the one with no arguments.

This is not a trifle as far as I'm concerned. One of my pet peeves about
VB.net is Optional parameters. Now, you and I both know that such things do
not exist, but you can create them in VB.Net. Then, when you want to write
an overload, you can get into serious trouble, because of the Optional
parameters in the method you're trying to overload..

I have had on occasion to completely rewrite VB.Net methods with optional
parameters to overloaded methods in order to be able to add overloads to
them. And that's a waste of my time.

I agree. I'd like to see an option (defaulting to off) in VS that treats
case fixing in C# the way it does in VB, but there are some advantages to
case sensitivity, specifically the construct

class foo
{
int myAge;
public int MyAge { get { return myAge; } set { myAge = value; } }
}

This is a problem, but making C# non-case-sensitive isn't the solution, for
reasons too many to enumerate (you can probably imagine at least some of
them). If you've had a look at VS.Net 2005, you can see Microsoft's
solution, which is to make the IDE auto-correct your capitalization for you
when it can discern that there is not a similar token with different case. I
think this is a good compromise. At least I can live with it.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.

 

[Brendan Reynolds]

I know, but a ten-year-old habit is hard to break!

 

[Guest]

I can answer some of your (rhetorical?) questions from personal experience,
though I'm worried this is turning into a religious rahter than a technical
debate.


Some readers really liked that we did two books in both VB and C#, many
others complained that it bloated the book, and we've moved away from doing
so.


Not me, I deal in virtual world projects <smile>. I spend 90% of my time in
real world projects and have just not run into your experience, but that is
why they make chocolate and vanilla.


Sorry, don't know what you mean? Ctrl-space?


Not my experience; Intellisense in C# does know about enumerations (though
you must use the enumeration name and then it pops up the possible values,

In VB I don't need to type the enum name.

and that is how it should work) and when a Boolean is possible, it offers a
menu of true/false.


I think we're getting into trifles here, but the advantage of not putting
them in for you is if you've overloaded the method, you could well be
introducing a bug by assuming you want the one with no arguments.

Good point here.

I agree. I'd like to see an option (defaulting to off) in VS that treats
case fixing in C# the way it does in VB, but there are some advantages to
case sensitivity, specifically the construct

class foo
{
int myAge;
public int MyAge { get { return myAge; } set { myAge = value; } }
}

I hate this style myself .

And note that properties are much better in C#, they look to the client like
fields, to the developer like methods which is just how it should be. (My
aren't we squabbling over trivialities).

Also not context help does not tell you if a property is read only or write
only, infact you will not see the error untill you compile.

In fact, both are in VS 2005 for C#

Some folks like braces (easier to type) some folks like the more verbose VB
style. My point is that there is no objective reason to prefer one over the
other; it is a personal, aesthetic decision.

No, End if tell you its completion of an if block. Next tells you its a
completion of a for loop. } does not specify.

I do agree that It look pretty...

-j

Seems you skipped over a few, is that beacause you agree?

Anyway I enjoyed the debate...

Thanks,

Schneider

 

[Alex D.]

I agree with you...besides VI is not a "simple" text editor....notepad is
simple.
I used to use papel and pencil for pseudo-code and algorithms... but I think
it's stupid not using the IDE to take care of the silly details.