C# versus VB.Net

[Emmett]

I am working with a .NET development team and I am looking for reasons,
that I can present to management, as to why we should develop our
software using C# rather than VB.NET.

 

[Scott M.]

This has been asked & answered thousands of times in various places.

There is no clear reason to prefer ANY .NET language over another.

It comes down to preference. In a corporate environment, the language
decision usually gets made based on the esiting skill sets that are already
in-house. Java and C/C++ developers are going to have a bit of an easier
time going to C#, because the language syntax is very similiar. VB 6.0
developers and those with little or no programming experience might prefer
going to VB.NET.

All .NET languages work off of a Common Language Specification and a Common
Type System. They all compile to the same Intermediate Language and the all
have (more or less) the same performance and capabilities.

-Scott

 

[Tom Spink]

I am working with a .NET development team and I am looking for reasons,
that I can present to management, as to why we should develop our
software using C# rather than VB.NET.

Hi Emmett,

Do you like coding in C#, or do you like coding in VB .NET?

Choose the one you like. It makes no difference.

 

[Scott M.]

Just curious though...Why do you *want* to talk management into C#?

 

[chanmm]

Exactly Scott, what does management to do with what programming language to
use. The software architect should.Yet, if the software architect does not
know about why C# and VB.NET I bet you really can ask the management to fire
him/her.

chanmm

 

[Guest]

as far as I know they are similiar in output <> in sysntax. I have been
working on VB my whole life and starting with vb.net 2003 there is nothing
related to windows that I could not achieve....
If no previous exprience in C, I would recommend VB.NET becuase it is so
much easy to learn and Microsoft is commited to it, so do nt be afraid to go
for it.

 

[Scott M.]

True, but not really my point. The OP said he *wanted* to present to
management reasont to use C# over VB.NET. Sounds like the OP has some
reason in mind for this. I was interested to know what it was.

As for management being involved. I can see a few factors that are
managerial and not technical for choosing a programming language....

Cost to train developers in a new programming language and loss of
productivity while they are in training and get ramped up.

Ditto for developer support personnel.

Also, if current developers and support people have to have a new language
in their skill set, it not only means getting those people trained, but it
means that future people hired for those positions will need to have skills
in more than one programming language. That could mean that these positions
must pay more than they may pay now.

But I do agree that management doesn't see things from a technical point of
view, the see things from a "bottom line" point of view.

 

[Scott M.]

But, let's just be clear and impartial here....

as far as I know they are similiar in output <> in sysntax.

This only applies when you are talking about ASP.NET. For client and
componenet development, this statement doesn't have any meaning.

I have been working on VB my whole life and starting with vb.net 2003
there is nothing
related to windows that I could not achieve....
If no previous exprience in C, I would recommend VB.NET becuase it is so
much easy to learn

Well, I happen to personally agree with you, but there are those that
disagree and think that VB.NET is too verbose and cumbersome. There are
many that believe that C# is more "elegant" and simple. Remember, you did
say that you've worked with VB for quite a while, so you are biased towards
it. I am too .

and Microsoft is commited to it, so do nt be afraid to go for it.

Microsoft is committed to C# as well. In fact, many of the major changes to
the VB lanaguage you are now learning in VB.NET have to do with making VB
more C/C#/Java - like. That is one feather in the cap of knowing C#. The
syntax is very similar to C amd Java. Can't say that for VB.NET.

 

[Jon Skeet [C# MVP]]

Well, I happen to personally agree with you, but there are those that
disagree and think that VB.NET is too verbose and cumbersome. There are
many that believe that C# is more "elegant" and simple. Remember, you did
say that you've worked with VB for quite a while, so you are biased towards
it. I am too .

I would say that it's not the verbosity of VB.NET which in my view
makes it harder to learn than C# - it's all the "extras" which are part
of it: the odd nature of Nothing when applied to String (where Is and =
do different things for legacy reasons); the way that you can call
static methods as if they were instance methods; the numerous functions
which are mostly there for backwards compatibility, but which you'll
need to have a grip on if you're going to read other people's code
(etc).

C# had a definite advantage in being a new language. It has a few
things left over from C which I'm not too happy with (particularly
regarding switch) but mostly it was able to form a clean break with the
past.

It also doesn't help that VB.NET uses different terminology to what
most other languages use for various things (Nothing instead of null,
shared instead of static, MustInherit instead of abstract, etc). You
need to know the VB.NET terminology in order to write VB.NET, but you
need to know the .NET terminology in order to communicate with anyone
who doesn't use VB.NET.

 

[Jonathan Wood]

Well, as others have pointed out, it's a matter of preference. Some things
to consider:

- C# was built from the ground up to be a modern .NET language. VB.NET,
while a completely new language, has some leftover baggage from VB.
- C# has had more involvment with standards comittees than VB.NET. This
could suggest that C# will be a more stable language.
- C# is closer to C/C++. <g>

Perhaps others have more items they can add.

Then you might ask a similar question about VB.NET in the VB.NET groups.

That's probably the most objective approach.

 

[Scott M.]

Agreed. But, with regard to:

"the way that you can call static methods as if they were instance methods"

We would make these static (shared in VB.NET) inside of a sealed
(NotInheritable with a Private constructor) class to avoid this problem.

 

[Guest]

No body has to use old constructs of VB. However, they are there for
compatibilty....Remmeber that all .NET are compiled into CLR, so there is no
differene at the end.

 

[Jonathan Wood]

No body has to use old constructs of VB. However, they are there for

compatibilty....Remmeber that all .NET are compiled into CLR, so there is
no
differene at the end.

The fact remains that VB.NET has some degree of baggage left over from VB. I
know first hand because I was involved up at Microsoft in discussions with
the developers on how VB.NET could be more compatible with VB. And this
includes constructs that are virtually unavoidable (for example, logical and
bitwise operators, etc).

I know it's all the same in the end. But the OP was asking about comparing
the two, and the language makes a difference.

 

[Guest]

The idea is VB is now as powerful as c# and Microsoft is as committed to it.
The only point that I find C# more powerful in it is the Mono project on
Linux.....Whatever is the case, I agree with you that it is a matter of
preference.

 

[Scott M.]

The only point that I find C# more powerful in it is the Mono project on

Linux.....

But that's not true .NET.

 

[Tom Spink]

But that's not true .NET.

The Mono project is fully CLI compliant. What's not true about it? In
fact, I use the Mono C# Compiler GMCS, because I don't own Windows or
VS .NET. I get to use the IDE at University, but my late-night coding is
done by the light of Debian and GMCS.

 

[Jon Skeet [C# MVP]]

Agreed. But, with regard to:

"the way that you can call static methods as if they were instance methods"

We would make these static (shared in VB.NET) inside of a sealed
(NotInheritable with a Private constructor) class to avoid this
problem.

That doesn't solve the problem at all. For one thing, it doesn't do
anything about static methods which exist in other classes. For a
second thing, it severely limits your options - if you can't have any
static methods on classes where you *can* have an instance, you've
really limited yourself artificially.

I'm not sure we're talking about the same thing. I'm talking about the
ability to call Thread.Sleep "on" a different thread, even though it
ends up making the currently executing thread sleep. In C# you couldn't
do:

// Will not compile!
Thread t = new Thread (someThreadStart);
t.Start();
t.Sleep(1000); // Error! Thread.Sleep is static!

The equivalent VB.NET code would compile. Fortunately this is
(optionally) a warning in VS 2005, but I can't see the usefulness of it
being allowed at all - unless it's for legacy reasons.

 

[Jon Skeet [C# MVP]]

No body has to use old constructs of VB. However, they are there for
compatibilty....Remmeber that all .NET are compiled into CLR, so there is no
differene at the end.

You could use C# and never know how a "for" loop works, sticking only
to "while" loops - but you wouldn't know C#. Unless you're only ever
reading code that you've written yourself, you can't really work with
VB.NET (or claim to know it) without having at least a passing
knowledge of the "old constructs".

 

[Scott M.]

I meant that it is not what MS intended.

The Mono project is fully CLI compliant. What's not true about it? In
fact, I use the Mono C# Compiler GMCS, because I don't own Windows or
VS .NET. I get to use the IDE at University, but my late-night coding is
done by the light of Debian and GMCS.

--
Hope this helps,
Tom Spink

Google first, ask later.

 

[Larry Lard]

I am working with a .NET development team and I am looking for reasons,
that I can present to management, as to why we should develop our
software using C# rather than VB.NET.

Because C# developers get paid more than VB.NET developers. Oh wait,
that's a *bad* thing to point out to management...

One thing has me confused though. You say you are working with "a .NET
development team" - so what are they using at the moment? Presumably
it's one or the other, so whatever you're using at the moment must have
been chosen initially for some reason. What was that reason? Have any
of the facts on which that decision was made changed? What is the
skillset of the developers in the team?