A
Arsalan
Is there any advantage in C# over VB.NET ? Or the difference is only syntax
? Can anything done in C# which cannot be done in VB.NET?
? Can anything done in C# which cannot be done in VB.NET?
S
Samuel R. Neff
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
B-Line is now hiring one Washington D.C. area VB.NET
developer for WinForms + WebServices position.
Seaking mid to senior level developer. For
information or to apply e-mail resume to
sam_blinex_com.
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
B-Line is now hiring one Washington D.C. area VB.NET
developer for WinForms + WebServices position.
Seaking mid to senior level developer. For
information or to apply e-mail resume to
sam_blinex_com.
B
Bob Grommes
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
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
A
Arsalan
Thanks for everyone for posting their opinion
J
Jon Skeet [C# MVP]
Bob Grommes said:
I would argue that there are a number of ways in which C# genuinely
*is* more elegant, mostly because it doesn't have the baggage you
mentioned earlier. (And while I agree that going forward it will end up
having "earlier version baggage" I don't think there'll be nearly as
much - partly because VB is a much larger language than C#.)
I'm thinking of things like the way that C# doesn't let you access a
static member via a variable - so while in VB I could create a new
thread and call:
t.Sleep(5000)
C# would disallow this, forcing you to write
Thread.Sleep(5000) instead.
The VB.NET version is unclear - if you didn't know the framework well,
you might think it's telling the other thread to sleep for 5 seconds,
rather than the current thread.
The ability in VB.NET to pass properties by reference, which generates
"copy into temporary variable, pass temp variable by reference, copy
out of temp variable" code is another example - it's just *nasty* to
hide things like that and make it look like passing a property by
reference is the same as passing a variable by reference, when they end
up having very different semantics.
While there are certainly flaws, C# is a very, very elegant language in
general. I think it really is reasonable to say it's more elegant than
VB.NET. (The "attracts the better developers" idea is an interesting
one. I have no idea whether that's true or not, and I suspect no-one
else does either. It would be interesting to know though.)
C
Cor Ligthert
Aralan,
Asking this question in this newsgroup is asking to somebody who rides a
BMW, if there advantages from a BMW above a Mercedes.
What do you think that the answer will be?
Cor
Asking this question in this newsgroup is asking to somebody who rides a
BMW, if there advantages from a BMW above a Mercedes.
What do you think that the answer will be?
Cor
A
Arsalan
Good question, but you cant disagree, VB.NET lacks feature according the
reply to this thread.
Most VB users are not 'Pro' programmer, where as ppl who r using C# r those
ppl who've migrated from VC or Java.
reply to this thread.
Most VB users are not 'Pro' programmer, where as ppl who r using C# r those
ppl who've migrated from VC or Java.
G
Gerry O'Brien
Seriously WRONG statement! "Most VB users are not 'Pro' programmers,"?
What are you basing that statement on?
I know plenty of 'Pro' Vb programmers both VB6 and VB.NET.
I program in both VB.NET and C# and the apps we generate are professional
level and mission critical in both languages.
Just because C# has some features that VB doesn't have, does not a better
language make. VB.NET also has features that C# does not have.
Remember one thing when asking the question you posted originally here;
C# programmers are not old school C# programmers. They are C, C++ or Java
programmers who have switched to C#. There will always be a bias towards C
based languages on their part.
That question has been discussed at length so many times in the past and can
only be answered in a simple manner. The best language is one that will do
what you want it to do. Neither is 'best'. They are both programming
languages that allow you to develop software for execution on a computer.
What are you basing that statement on?
I know plenty of 'Pro' Vb programmers both VB6 and VB.NET.
I program in both VB.NET and C# and the apps we generate are professional
level and mission critical in both languages.
Just because C# has some features that VB doesn't have, does not a better
language make. VB.NET also has features that C# does not have.
Remember one thing when asking the question you posted originally here;
C# programmers are not old school C# programmers. They are C, C++ or Java
programmers who have switched to C#. There will always be a bias towards C
based languages on their part.
That question has been discussed at length so many times in the past and can
only be answered in a simple manner. The best language is one that will do
what you want it to do. Neither is 'best'. They are both programming
languages that allow you to develop software for execution on a computer.
C
Cor Ligthert
Gerry,
It is probably a true statement.
"Most VB users are not 'Pro' programmers,"?
Read it again.
However there are many VB users and that are not only 'Pro' programmers.
It is not impossible that there are more 'Pro' programmers who use VB (every
dialect) than there are 'Pro' programmers who don't use that.
However, I think as well that it was not what the OP was meaning
Cor
It is probably a true statement.
"Most VB users are not 'Pro' programmers,"?
Read it again.
However there are many VB users and that are not only 'Pro' programmers.
It is not impossible that there are more 'Pro' programmers who use VB (every
dialect) than there are 'Pro' programmers who don't use that.
However, I think as well that it was not what the OP was meaning
Cor
G
Gerry O'Brien
I don't even remember the number of VB programmers world wide so it will be
hard to determine percentages.
Another question might be, "How do you determine if a programmer is Pro"?
hard to determine percentages.
Another question might be, "How do you determine if a programmer is Pro"?
A
Arsalan
Not meant to offend anyone. Looks like VB guys r on FIRE
A
Arsalan
Man you're the Boss, whatever you say is right, I'm wrong, r u happy now.
G
Gerry O'Brien
I'm just tired of people putting down VB due to a lack of knowledge of the
language. If the VB people don't set the other straight, how people like
yourself know the difference?
If you are new to programming, the VB.NET and C# share the same learning
curve. Therefore the language chosen will more than likely be based on
questions like the OP asked. Which is better?
My answer at the end of my response is valid and true.
I said you were wrong quite simply because your statement sounds so much
like someone who knows very little about how VB.NET is being used. Your
statement is the same as that made by C and C++ programmers so many times.
VB is a toy language for hobby programmers and you can't do any serious
development with it. That is the reputation that VB has and it is wrong to
continue that. I'm merely pointing that out.
Gerry
language. If the VB people don't set the other straight, how people like
yourself know the difference?
If you are new to programming, the VB.NET and C# share the same learning
curve. Therefore the language chosen will more than likely be based on
questions like the OP asked. Which is better?
My answer at the end of my response is valid and true.
I said you were wrong quite simply because your statement sounds so much
like someone who knows very little about how VB.NET is being used. Your
statement is the same as that made by C and C++ programmers so many times.
VB is a toy language for hobby programmers and you can't do any serious
development with it. That is the reputation that VB has and it is wrong to
continue that. I'm merely pointing that out.
Gerry
G
Gerry O'Brien
No, we're just always this way because we have to defend our language.
Gerry
Gerry