C# versus VB.Net

[Leon Lambert]

Following is an interesting article on the subject.

http://www.cmswire.com/cms/featured-articles/not-another-c-versus-vb-article-000591.php

Basically is says the VB.Net and C# are functionally equivalent now and
from a language standpoint there isn't much difference. The main
difference is the culture of the developers behind the language.
Basically VB developers are sloppy, less skilled and do not have good
design skills. The above is a long article but I found it very interesting.

 

[Tom Spink]

I meant that it is not what MS intended.

Hi Alan,

On the contrary,

Have you heard of the Rotor project? A shared-source project by Microsoft
which has a fully compliant CLI and compiler? I've never looked at it
because it would violate the rules of me developing on the Mono project,
but it's an initiative by Microsoft to get developers interested in the
workings of the CLI and ultimately giving rise to the CLI being developed
for different platforms.

 

[Emmett]

Following is an interesting article on the subject.

http://www.cmswire.com/cms/featured-articles/not-another-c-versus-vb-article-000591.php

Many thanks for all the replies. Apologies for bringing up a well worn
subject. The above article is exactly what I have been looking for.

 

[Chris Dunaway]

Basically VB developers are sloppy, less skilled and do not have good
design skills.

Thank you for insulting every VB developer on the planet. Until you
have examined the code of every VB programmer you cannot possibly
justify this statement. No matter what language you are talking about
there are good coders and bad coders.

 

[Thomas T. Veldhouse]

Thank you for insulting every VB developer on the planet. Until you
have examined the code of every VB programmer you cannot possibly
justify this statement. No matter what language you are talking about
there are good coders and bad coders.

Metaphorical generalizations will get your into political trouble every time.
The truth is irrellavent at that point.

 

[Scott M.]

Basically VB developers are sloppy, less skilled and do not have good

design skills.

A statement like that just tells us that you really don't have a clue as to
what is actually going on out in the real development community. I've seen
just as much bad and sloppy C# as I have VB.NET.

 

[Scott M.]

My point was that there is a way to separate static methods from instance
methods.

 

[Mark Rae]

Choose the one you like. It makes no difference.

Unless you need pointers / unmanaged code...

 

[Jon Skeet [C# MVP]]

My point was that there is a way to separate static methods from instance
methods.

But that is entirely orthogonal to my point that VB.NET lets you write
confusing code for no reason other than (presumably) supporting legacy
code. I've seen plenty of people trying to make other threads sleep in
Java due to this exact same flaw (which fortunately many IDEs highlight
these days).

It's that kind of thing which I think I'd find confusing if I were
learning VB.NET and reading bad examples (which are everywhere, let's
face it).

 

[Tom Spink]

Unless you need pointers / unmanaged code...

Hi Mark,

;-) I'll assume you meant "unsafe" code, not "unmanaged" code.

I was waiting for that comment. VB .NET is equally expressive as C#, minus
that feature, but it's not often that unsafe code is used in everyday
applications, and the chances are, if you're coming _from_ VB .NET, then
you'll have little use for pointers anyway.

 

[Jon Skeet [C# MVP]]

Unless you need pointers / unmanaged code...

If you need unmanaged code, neither VB.NET nor C# will help you. C# has
unsafe code, but not unmanaged code.

 

[Lebesgue]

I guess he wrote VB, not VB.NET. The worst code the world has ever seen was
written in VB. And it's because VB was made so incredibly easy to learn that
every single idiot was able to learn the If Then Else syntax and work as a
contractor for some big venture delivering information systems and producing
code like you can see on thedailywtf.com. This is not true for languages
like C, which seem to attract much fewer idiots.

 

[Mark Rae]

;-) I'll assume you meant "unsafe" code, not "unmanaged" code.

LOL! Yes, you're quite right - my slightly drunken error...

I was waiting for that comment. VB .NET is equally expressive as C#,

No question.

minus that feature, but it's not often that unsafe code is used in
everyday
applications, and the chances are, if you're coming _from_ VB .NET, then
you'll have little use for pointers anyway.

Agreed.

 

[Scott M.]

But that is entirely orthogonal to my point that VB.NET lets you write
confusing code for no reason other than (presumably) supporting legacy
code.

Didn't someone say, "confusing is in the eyes of the beholder"? LOL. I
just mean that, as all in this thread agree, what's confusing and
non-intuitive to some, is perfectly logical and intuitive to others. It
depends on what angle your coming from.

 

[Jon Skeet [C# MVP]]

Didn't someone say, "confusing is in the eyes of the beholder"? LOL. I
just mean that, as all in this thread agree, what's confusing and
non-intuitive to some, is perfectly logical and intuitive to others. It
depends on what angle your coming from.

So who exactly is going to find it perfectly logical and intuitive that
if you appear to call Sleep on a specific thread, you actually make a
completely different thread (the current one) sleep? What is the
*possible* benefit in that?

Some things are indeed subjective, but we really shouldn't let that be
a catch-all excuse for things which just shouldn't be the way they are.

 

[allfyre]

I've worked extensively with both languages and functionally it doesn't
make a lick of difference one way or the other. C# has a few features
that you don't get in VB, mainly pertaining to the use of pointers and
"unmanaged" code which more or less manipulates memory directly.
You're probably not going to need to do it anyway.

Don't worry about the sale to management, they don't care what you use
one way or the other as long as they can get everything in
Excel/PowerPoint at the end of the day.

What you should do is discuss it with your team, discuss the merits and
pitfalls of working with either language and decide what you want to
use and tell management that you want to make the move to this language
or that because it's what your developers want to be working in.

As far as learning a new language goes, the important thing (and the
difficult thing) is learning the .NET framework and how to leverage it.
The languages themselves are easy. I think that VB.NET is more
different from VB6 than it is from C#. VB.NET even supports all the
same C/C++ operators now.

Also, there is no reason why you can't work in both languages as they
are completely interoperable. If you're working with VB.NET currently,
you could try a few small projects in C# and see how you like it. It
does take some getting used to coming from a VB background but
personally I prefer the C# syntax because it lets me write more concise
code, and because I like curly braces.

I've also worked on projects where both languages were employed. For
example a project where the ASP.NET page classes were written in VB.NET
and the middle tier and data access layers were done in C#.

 

[Mark Wilden]

I've worked extensively with both languages and functionally it doesn't
make a lick of difference one way or the other. [...]
What you should do is discuss it with your team, discuss the merits and
pitfalls of working with either language

But what -are- the merits and pitfalls, especially if there's no functional
difference?

///ark

 

[Mark Rae]

If you need unmanaged code, neither VB.NET nor C# will help you. C# has
unsafe code, but not unmanaged code.

Yes I know - another senior moment - apologies...

 

[allfyre]

Well, one example is that C# enforces strict type safety at all times
so you'll have to do a lot of casting & conversion operations that you
might not have had before, this is both a merit and a pitfall insofar
as that you may have to write some extra code, but that type safety is
ultimately a good thing.

Another example perhaps is that some people find C to be cryptic or
perhaps just difficult to read. This may be because the whole "C"
family substitutes symbols for a lot of words, I can't really tell
because I've been doing this for a while now, I've worked with a lot of
different languages and they pretty much all look the same to me now.
The tradeoff here is that C# code can be more concise, you can view
more C# code on screen at once because it's shorter.

One more thing to discuss is case-sensitivity. This makes VB
programmers especially nervous, but trust me it's not that bad and it
gives you more flexibility in choosing names for member variables.

In C#, you have to end each line of code (different from a line of
text) with a semicolon. So you have to type a lot of semicolons.
However, you can insert carriage returns in a line of code which can
make a lengthy call more readable. In VB.NET, you have to enter the
line continuation character '_' if you want to split lines.

So ask yourself, would I rather type a semicolon at the end of every
command? Or do I want to type an underscore every time I want a
command to span multiple lines.

In C# you also have more options for formatting in your code, this can
be a benefit or a curse as it can make code easier or harder ot read
depending one your perspective.

There are a few other technical differences but really nothing major.
I think if you are comfortable with VB.NET already you should be able
to get handy with C# in a couple of days with an ample supply of
coffee. The important thing, once again, is that you understand the
..NET framework.

There are other things to consider. Most modern languages, including
VB.NET and Java owe much of their lineage to C and it's progeny. It is
good to become familiar with the C-style syntax. Even a VB.NET
programmer is going to learn how to read C# eventually, so much of the
sample code you'll look at online is posted in both languages right
next to each other you're just going to absorb it naturally anyway so
you might as well take a direct approach and learn both.

If you learn C#, you should at least be able to read and understand
Java source code which is a useful skill for a developer these days
too.

Here's two examples, which one do you like better? Really, are they
even that different?

Sample VB.NET class:
Public Class VbNetClass

Private _alpha As String

Public Property Alpha()
Get
Return _alpha
End Get
Set(ByVal value)
_alpha = value
End Set
End Property

Public ReadOnly Property Beta()
Get
Return "Vb.Net is the best language. Semicolons are for fake-ass
hoes."
End Get
End Property

End Class

Sample C# Class:
public class CSharpClass
{
private string alpha;

public string Alpha
{
get { return alpha; }
set { alpha = value; }
}
public string Beta
{
get { return "You talk too much."; }
}
}

 

[Scott M.]

Well, one example is that C# enforces strict type safety at all times

so you'll have to do a lot of casting & conversion operations that you
might not have had before, this is both a merit and a pitfall insofar
as that you may have to write some extra code, but that type safety is
ultimately a good thing.

But, it is considered by most unthinkable to *not* turn Option Strict on in
VB.NET, which effectively makes VB.NET type-safe as well. This means that
the same casting and additional code would be needed in VB.NET as well as
C#. So the bottom line is that type safety isn't really something that
would/should tilt the scales in favor of any one language.