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" <la**************@discussions.microsoft.com> wrote in
message news:F4**********************************@microsof t.com...
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?
