Which is better, C# or VB, and why?

G

Guest

i've been researching this issue for a while and can't come to any conclusive
answer, mostly it seems to be a preference over syntax, some saying c# is
elegant while vb is clunky, or that c# is geeky while vb is more naturally
legible. there dont seem to be many capabilities in one over the other, at
least with whidbey, so basically, is there anything c# can do that vb can't?
 
D

Daniel O'Connell [C# MVP]

lastusernameleft said:
i've been researching this issue for a while and can't come to any
conclusive
answer, mostly it seems to be a preference over syntax, some saying c# is
elegant while vb is clunky, or that c# is geeky while vb is more naturally
legible. there dont seem to be many capabilities in one over the other, at
least with whidbey, so basically, is there anything c# can do that vb
can't?

Each language has a few, little things different. In 1.x VB has its
dynamically bound mode when option strict is off and has access to a few
little things like parameterized properties(I believe) while C# has support
for pointers, unsigned tyupes, and operator overloading.

In whidbey, VB added operator overloading and direct supprot for unsigned
types as well as some other niceties(like OrElse and AndAlso, IIRC), but the
languages actually diverged just a little bit moreso than they were. Both
got generics and partial types, but much of the VB effort went into things
like Edit&Continue(C# basically hopped on that bandwagon pretty late), the
My namespace, and the things I mentioned before while C# added a few little
thigns like anonymous methods that are close to closures and iterators.

I think anon methods are the only thing I'd consider an advantage. Iterators
are nice but IEnumerable\IEnumerator implemetnations are not *that* hard to
write manually. Out side of that I don't see much advantage except for
personal preference or in very specific circumstnaces(C# for pointer ridden,
native code or VB for rich COM work, office automation for example)
 
T

Tom Dacon

C# can use the unsigned integer data types, and you can code 'unsafe' code
blocks. If you need these features, you already know it. Most people never
have a need for them.

VB.Net is better at late binding, which is sometimes very useful if you need
to interact with certain external applications such as MS Office. C# can do
it, of course, but it takes more code. If you turn Option Strict on in
VB.Net, as you should, it's just as good about insisting on data type
matching as C# is.

VB does background compiles and is quicker at showing you coding errors
(keep the task list window visible and you get immediate feedback). If you
have extremely large solutions and your processor isn't fast, this can
sometimes slow down editing responsiveness. C#, on the other hand, doesn't
show you most errors until you compile.

Performance will be the same (provided you avoid the
VisualBasic.Compatibility assembly, which is supplied as a crutch for people
trying to use the upgrade wizard in bringing code up from VB6). The wizard
is almost universally considered to be pretty much useless.

Other than that, there's not much else to choose between them. If you like
curly braces and case-sensitivity, you'll like C#. If you came from a VB 6
background and like not not having to match the case of variables and so
forth when you type, you'll like VB.Net. You still have to spell the names
correctly, but VB.Net is relaxed about matching case. The casing in the
declarations rules throughout the code, and the editor will correct the
casing for you after you edit past the line. VB.Net is a little more
verbose: Begin's, Then's, End If's, and so forth instead of curly braces,
but if you're a skilled touch typist this isn't much of a deal.

Some people seem to think that C# code looks 'cleaner', which is really an
issue of aesthetics. The compilers don't care, but there's no reason why you
shouldn't take that into account if you agree and have the freedom to make
your decision on that basis. I tend, myself, to agree with that sentiment,
but not to the extent that I let it limit my options.

There's a contingent of C# programmers who tend to look down their noses at
people who program in VB.Net. If this is going to bother you, and in my
opinion it's their problem, not that of the VB.Net programmers, you might
want to gravitate to C#. They can be a little savage, but mostly they rant
about it among themselves rather than taking it to the streets ;-)

There's seems to be a little evidence that on average C# programmers might
get slightly higher salaries. This is probably tied to a perceived notion
that C# programmers are somehow smarter or better than VB.Net programmers
(here, of course, I'm talking about professional programmers, not
hobbyists).

Whatever you do, learn both languages, regardless of which one you decide to
use (or have decided for you by someone else). Someone with a computer
science background should be able to pick up a new language in no more than
three days or so. Mastering the framework class library will be the biggest
hurdle you have to face, and that effort will be the same no matter which
language you settle on.

Where do I come down on this personally? I was a happy C/C++ programmer long
before VB came out in 1991. Over the years I moved into VB programming,
starting with VB 1.0 and going up through VB 6, writing less and less helper
code in the C language family as VB grew up. When I moved into .Net, I
started out programming in both, leveraging my familiarity with both
language families. If I happened to pick up a code sample that exercised
something in the framework I wanted to learn about, I just continued in the
language of the sample. If I start a new project from scratch, I usually
start it out in C#.

The company I'm working for now made the decision, before I joined them,
that they would develop in VB.Net, so that's what I use, without complaint,
when I'm programming for them.

HTH,
Tom Dacon
Dacon Software Consulting



lastusernameleft said:
i've been researching this issue for a while and can't come to any conclusive
answer, mostly it seems to be a preference over syntax, some saying c# is
elegant while vb is clunky, or that c# is geeky while vb is more naturally
legible. there dont seem to be many capabilities in one over the other, at
least with whidbey, so basically, is there anything c# can do that vb
can't?
 
G

Guest

Off the top of my head:

C# allows:
- 'unsafe' pointer code if you're inclined that way.
- assignments within expressions (e.g., while ((i = s.IndexOf(y)) > -1))
- allows anonymous methods - I don't believe VB will include that in 2005.

VB allows:
- types within interfaces.
- the "With" construct (but it's value is debatable).
- a shorthand for array resizing while preserving contents (ReDim Preserve),
but you can do it in C# also with 4 lines of code.
- this is pretty trivial, but VB has the "When" clause for Catch statments,
which has no elegant C# equivalent.

David Anton
www.tangiblesoftwaresolutions.com
Home of:
Instant C#: VB.NET to C# Converter
Instant VB: C# to VB.NET Converter
Instant J#: VB.NET to J# Converter
 
C

Cor Ligthert

David,

Because you are name them, in that row has to be as well in my opinion

VBNet has a very elegant Switch statement (select case)

Cor
 
B

BravesCharm

Another thing C# gives you is XML documenting. I hope VB.NET will give
you this sooner or later!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top