More talking points:
VB.NET lacks C#'s "using () {}" code block, which I find -- ahem --
indispensable for dealing with IDispoable objects. I really miss it when I
have to code in VB.NET.
C# is case sensitive, whereas VB is case-insensitive. There are endless
religious debates about which is better. I came to C# from a
case-insensitive language (Visual FoxPro) and at first found case
sensitivity a slight annoyance, but quickly adapted. After being thrust
recently into a VB.NET project two years later, I am finding case
insensitivity to be *more* of an annoyance (though still not a huge deal).
Your mileage may vary.
There are two things that VB.NET has over C# that I rather like. One is
With / End With -- some C# people think this is evil incarnate, but I
personally like this syntax sugar (and yes, we had it in VFP too). That
said, in C# it's no big deal to achieve all the performance advantages of
With / End With, if not 100% of the compactness, by simply assigning a
lengthy hierarchical reference to a short variable name and using that going
forward.
The other thing that VB.NET has that C# lacks is optional parameters.
Again, you can acheive almost the same things in C# with overloading, but
optional parameters really makes some Interop work -- especially ActiveX
Automation -- much less tedious and error-prone to code.
Since I haven't had the need for it yet, for me the jury is still out on
VB.NET and Option Strict Off (support for late binding that does a lot of
tedious calls into System.Reflection on your behalf). In theory this should
make some late binding work easier, but I haven't actually had to do it yet
and wonder if it's one of those features where I'd end up doing it myself it
I wanted it done right.
Which brings us to the ethos of VB.NET, which is to try to do as much detail
work for you as possible by default, vs C#, which tends to make fewer
assumptions about what you are trying to accomplish. Both approaches can
get in the way of getting things done, depending on the context. Again, in
my view, really a wash, but I moderately favor C#'s hands-off approach; I
don't like to be second-guessed.
There is always the religious debate about verbosity / clunkiness of VB.NET
vs the terseness / elegance of C#. I personally have a distinct preference
for C-style syntax, at least of the Java or C# persuasion as opposed to the
underscore and macro infested crap that a lot of C++ code appears to be.
But, although coding in VB.NET makes me grimace a little from time to time,
it's not that big of a deal. It is what it is.
VB.NET has some legacy baggage to support VB6 and prior, that C# was able to
avoid. For example if you are an old VB6 warhorse you would probably use
CInt(obj) or CType(obj,Integer) rather than Convert.ToInt32(), and if you
are a multi-language .NET developer you would probably favor the inverse.
Though this does create some extra learning curve if you don't have a VB
background, it is in fact once again a minor deal. And after a couple more
releases, C# will have legacy baggage of its own anyway, so its lead in this
division of the elegant / clean competition is fairly temporary.
Two final deciding factors in favor of C# for me:
1) While MSFT is clearly committed to VB.NET, C# is just as clearly MSFT's
favored child. It was created specifically for .NET, and although things
have gotten better lately, there was an early tendency for the best examples
and newest toys to be C#-only. Indeed, new features have been promised for
C# first, and for VB.NET at some undefined future date; for a long time it
was not promised or certain that generics would make their way into VB.NET
with version 2.0. Ultimately it did, but the fact that the VB community had
to agitate for it is telling. So I like C# because it seems to have a
moderately favored status with its maker (although some third party vendors
favor VB.NET; for example IronSpeed Designer only generated VB.NET code
until recently).
2) Politics. There is a 99% bogus, yet persistent, perception abroad in the
world that VB.NET is a "toy" language and/or that it is not for "serious"
projects (whatever precisely those might be) and/or tends to attract less
skilled developers. Conversely there is a 99% bogus, yet persistent,
perception abroad in the world that C# is an "adult" language and/or that it
is more elegant / faster / better / grows hair on your chest and/or attracts
the better developers. I call it the Curly Brace Effect ("my God, Edna, if
he can read that stuff he *must* be a genius!"). No one ever kicks sand
into your face for being a C programmer (be it Java, C#, or especially C++).
On the other hand you can be fairly readily dismissed for being a VB
programmer. Unfair, but true. So for pure marketability to pointy-haired
bosses who think the language is the key to everything, I position myself as
a C# developer.
Of course in reality no one is a C# or VB.NET or Eiffel.NET developer; we
are all .NET framework developers with a favorite language.
--Bob
"Samuel R. Neff" <bl****@newsgroup.nospam> wrote in message
news:9q********************************@4ax.com...
Debugging is easier in C# beause C# provides an $exception variable on
unhandled exceptions. In VB.NET you ahve to catch the exception to
inspect exception details. This poses a problem as catching the
exception also means the scope is changed from where the exception
actually occured to now be where the exception is caught, leaving
local variables and general object state information unavailable. I
haven't seen this problem discussed at all and when I brought it up in
the VB.NET group it was brushed off as a non-issue. To me this is
enough of a reason to use C#.
Another advantage is the availability of unsafe code blocks in C#. If
you don't use them, then they're not an advantage though.
VB.NET also has serious problems with binary serialization of objects
that have events since attributes can not be applied to the
compiler-generated event fields. The only work-around is to have the
events declared in a separate object, possibly implying use of memento
for serialization. This is fixed in .NET 2.0 but the fix requires a
significant amount of code (20-30 lines) whereas only 1 line is needed
in C# (the attribute).
There are also lots of stylistic, syntax, and IDE differences but they
pose no real problems and are simply a matter of personal preference.
HTH,
Sam
