VB.net or C#.net

  • Thread starter Thread starter Terry
  • Start date Start date
T

Terry

Hi, I need some feedback.
We are converting to .Net and we are trying to decide on whether to use
VB.net or C#.net.
As far as our current systems, they will probably be rewritten in ASP.Net.
I have looked into both and I don't see anything that would scream out to
use one or the other. So at this point, it is still a toss up.
However, I want to look at the two languages from a different perspective.
That is from a career point of view.
Which has the larger install base. Which has more demand. Are developers in
one paid more than the other.

Any help would be appreciated.
Terry
 
Right now there's virtually no difference between the products. There will
be some divergence in the 2005 versions (for example VB will add edit and
continue to the debugger while C# will add refactoring support) but they
will both continue to give full support to the framework.

I don't know any specific numbers but I would guess that the .NET market is
55%VB, 40% C# and 5% other.

As far as money goes, C# developers tend to get more. Again, I don't know
specific numbers but I think it's safe to say that on average C# developers
will earn $5,000 - $10,000 per year more than their VB conterparts. I think
that trend will continue into the near future but I see things evening over
time.

Hope this helps,
 
For ordinary purposes, the differences between the languages are
insignificant. Unless you need to run unsafe code blocks, which you can
currently do only in C#, you won't see much difference between them. If your
people are experienced only in VB6 or VBScript, perhaps they'll be more
comfortable in VB.Net; they'll at least be comforted by having access to the
good old VB6-style runtime methods like CSTR() and InStr() and so forth. If,
on the other hand, your peeps have been doing C++ or even have C in their
backgrounds, they may quickly come to prefer C#. In either case, there's a
steep learning curve even for programmers who are extremely fluent in the
older languages. For an experienced programmer, picking up the syntax of a
new language is fairly easy - three days and you've got it. The hurdle is
the framework class library. It's on the same scale as the Java class
library - it has literally thousands of classes to find your way around in.
I estimate that it's a six month to a year project to become practiced at
the journeyman level in the use of the framework class library, if you can
work on it full-time or nearly so. During that year, you're going to write a
lot of code that you'll later want to throw away.

And don't underestimate the need to become fully proficient in
object-oriented programming. It's a crucial and essential skill and it can't
be learned from a "Learn Object-Oriented Programming in 24 Hours" book.
Maybe you and your guys are already there - if you are, good on you, mate.

As to career strategies, there's some evidence that C# programmers are
getting higher salaries than their VB.Net counterparts. There's also that
indefinable cachet that seems to go along with programming with curly braces
and semicolons and case-sensitive names that the C++ programmers of old hold
so dear to their hearts, as symbols of their technical superiority. Along
with zero-based counting in arrays and collections, where VB programmers are
accustomed to start counting with one instead of zero. Now, of course, in
both VB.Net and C# that rational approach to numbering has gone by the
wayside, so it's not a discriminating factor between the languages either.

I guess I'm a case in point. I was a C and C++ programmer long before even
VB 1 came out in 1991. I worked my way up through VB1,2,3,4,5, and 6, using
less and less C over the years as VB became more capable and the need for
coding to the Windows API in C became less necessary. When .Net came along,
I'd been programming almost exclusively in VB for years and years. Now I
switch easily back and forth between VB.Net and C#. If I pick up some sample
code from the net for something I want to do, I use whatever language it
happens to be in. But if I start a new project from scratch, I almost always
start it in C#.

Personally, I'd recommend becoming practiced in both languages. There's so
much code floating around the net, both from Microsoft and from enthusiast
web sites, that if you only know one of the languages fully half of the
resources on the net are unavailable to you. This and this alone makes me
look at the language bigots with a jaundiced eye. And it really makes me sad
when someone comes on one of the .Net newsgroups and pleads with the group
members to translate a piece of code for them from the language they haven't
taken a few days to learn.

Regards,
Tom Dacon
Dacon Software Consulting
 
Rob Windsor said:
Right now there's virtually no difference between the products. There will
be some divergence in the 2005 versions (for example VB will add edit and
continue to the debugger while C# will add refactoring support) but they
will both continue to give full support to the framework.
Click to expand...

I believe VB.NET will have refactoring support, too.
I don't know any specific numbers but I would guess that the .NET market is
55%VB, 40% C# and 5% other.
Click to expand...

I would guess at VB.NET and C# being the other way round, personally.
Lots of VB Classic developers are annoyed at the horrible migration
situation, so are turning to C# instead of VB.NET. Only a guess though.
 
Jon,
I would guess at VB.NET and C# being the other way round, personally.
Lots of VB Classic developers are annoyed at the horrible migration
situation, so are turning to C# instead of VB.NET. Only a guess though.
Click to expand...

You know that there is a big difference between VB2002 and VB2003 the
upgrade from the last is (very) much better.

However this is not important of course in a ASP situation where the most
ASP pages will run with very few conversion on dotNet and otherwise normaly
on the IIS server mixed up with aspx pages.

The last of course not when it is done with the VB6 IIS class or with
another way of VB Com.

Just some thoughts

Cor
 
Terry,

You see all the answers, so from your part of view as you stated, it should
be an easy decission. For me is the conclussion.

When you are a manager choose VBNet
When you are a programmer choose C#

Cor
 
Cor Ligthert said:
You know that there is a big difference between VB2002 and VB2003 the
upgrade from the last is (very) much better.
Click to expand...

That's good to hear. I suspect that a lot of VB developers will have
been so turned off by the early migration problems that they don't want
anything to do with .NET any more - at least, that's some of the
feeling I've got in discussions with some VB programmers who are rather
cross (to say the least) about how things have been handled.
However this is not important of course in a ASP situation where the most
ASP pages will run with very few conversion on dotNet and otherwise normaly
on the IIS server mixed up with aspx pages.

The last of course not when it is done with the VB6 IIS class or with
another way of VB Com.
Click to expand...

Right - again, I didn't know that ASP pages were mostly compatible...
 
I truly hope VB.Net will have refactoring, one of the things I'm looking forward
to.

I was one of those VB Classic programmers caught up in the migration. I must say
that after reading all the hype about dotNet, I was really looking forward to
it. However, in practice it was much more difficult. Many things advertised
early on were things that MS didn't plan on implementing until later. Most truly
proficient VB programmers needed to know some C to overcome some limitations.
But interoping with C with VB Classic was a pain. So when I heard about truly
unified data types and marshalling between C# and VB.Net in managed code I was
elated. Only to find out that many things had not yet been implemented in VB.Net
< 2003. So I continued in VB6 until VB.Net 2003, at which point enough things
had been added to make it truly useful. Once some of the seemingly minor changes
to VB 2005 are available (such as UInt support, operator overloading, code
snippets, etc) I foresee that I may not have any need to go back to VB6 and/or
C.

With all that said, I personally think that VB2005 just might be the turning
point which brings the old school VB'ers back in droves. I also suspect that
those who ended up migrating from VB6 to C# will start to migrate to VB.Net
again. I am also going to go out on a limb and suggest that maybe it will be a
mature enough product and become widely enough used that many Java programmers
will migrate to C#.

In the end, I suppose it comes down to what you are most comfortable with. If
you have the knack for counting curly braces and truly think that Case in
variables names is a good thing, go with C#. If you know VB, go for VB.Net
(although there is a significant VB learning curve as VB.Net is a little more C
like in that it does try to encourage better programming practices than classic
VB, and the .Net Framework is huge). As far as performance, compatibility, etc.
I don't see much of a difference between them. In fact, in the end you will end
up using both, just like proficient VB'ers have in the past. But it is SO MUCH
easier to jump back and forth.

Just my 10 cents worth.

Gerald
 
I fully disagree with people that say that VB.NET 2002/2003 is equivalent to
C#.NET 2002/2003. I was originally a high level VB6 developer. When I first
look at the original betas of .NET, I chose C# for a couple of reasons.
Firstly, Microsoft might as well have called VB.NET, "Fred". Only simple
syntatic similarities exist between VB6 and VB.NET. Other than that, they
are very different products. Secondly, VB.NET, for some idiotic reason, was
limited compared to C#. Silly things like unsigned integers were not
included. Lastly, as I began developing with C#, I discovered that VB.NET
had/has a HUGE limitation. VB.NET 2002/2003 cannot use operator nor
conversion overloads built in C#. That means if you build classes that are
to be used by other developers, those other developers cannot use VB.NET
either because they have to hack their code to death to utilize conversion
and operator overloads. For example:

Suppose someone in C# builds a couple of classes and overloads the "+"
operator. You could write the following:

MyClass foo = new MyClass();
MyClass bar = new MyClass();
MyClass gamma = foo + bar;

In VB.NET, they would have to write something like (not sure the exact
syntax):

Dim foo as MyClass = new MyClass();
Dim bar as MyClass = new MyClass();
Dim gamma as MyClass;

gamma = foo operator+ bar;

Insanity that VB.NET 2002/2003 cannot even *use* overloads built and
compiled in C#. So, prior to Whidbey, I would say that if you want to build
nothing but "Hello World" apps, you could use VB.NET, otherwise use C#. Note
that this opinion has absolutely nothing to do with performance which is the
same between VB.NET and C#.

Whidbey changes all that. Microsoft has added most of the new goodies to
VB.NET as well as C#. In addition, VB.NET 2005 includes operator overloads
so, theoretically, VB.NET developers can use components with operator
overloads built in C#. I'm not yet sure if VB.NET can use conversion
overloads written in C#.




Thomas
 
I must agree that VB.Net is really so different from VB6 that maybe it should
have been named something different. Maybe B#, but I suppose musically speaking
that would make it the equivalent of C and that would have caused an uproar. Cb
would proly get it laughed at. Maybe V#?
I have also noticed quite a lot of VB6 programmers trying to make the switch
are just plain overwhelmed by VB.Net. I know I was.
FYI, to be CLS compliant I believe the sample of operator overloading should be:
Dim gamma as MyClass = MyClass.op_Addition(foo, bar)
But it is all symantics. Sadly, pre-Whidby VB.Net won't even honor the operators
on built-in classes/structures.
Even simple things like Point require this syntax.
pt2 = Point.op_Addition(pt, sz) :-(

I was so poorly disappointed that VB.Net 2002/2003 was not what I thought it was
going to be. Really sounds like Whidby just might be what I've been waiting for,
but I will need to wait and see.

So, I fully agree with everything you have said. However, IMHO I have found
VB.Net to be a quite powerful and respectable language. More so than VB6, which
I also feel is awesome. But give me VB syntax with all the capabilities of Cxx,
and I'll be happy.

Gerald
 
Hi Thomas,

Is overloading the operator that important for you that your complete
message is bassed on that, C# cannot use optional parameters as with VBNet
however that are differences in the marge of a thousands of the promilage
of the use in the world in my opinion.

Just my thought,

Cor
 
You asked, "Is operator overloading that important?" My answer, yes. The
primary reason is if you are building business classes that will be reused
by other developers, you want to define what >, <, etc do in the business
class. Optional parameters are really a convenience of method calling.
However, operator overloads present a serious potential for mistake by other
developers. For example, if developers do this:

MyClass foo;
MyClass bar;

if (foo == bar)
//do work

If MyClass represents a business object that has pulled data from the
database, this may indeed represent the same record in the db, but obviously
won't represent the same address in memory and thus will return false.
That's an error that will compile and may be difficult to catch.

I would put conversion overloads in the same category as optional
parameters. They are both contrivances of convenience. They save the
developer a little code. Requiring developers to explicitedly cast
everything, while inconvenient, won't lead to logic errors. Requiring C#
developers to find the overload that matches the optional arg signature they
want, while annoying, doesn't really produce logic errors.



Thomas
 
Hi Thomas,

A few things. First, I know I've heard one of the VB team members (I think
it was Paul Vick or Amanda Silver on .NET Rocks!) say that VB.NET was going
to have unsinged numeric types but they did not implement because the C#
team had decided not to. Then the C# team changed their mind and added them
very late, too late for the VB team to included them.

Secondly, VB.NET 1.0 and 1.1 can use overloaded operators. The syntax isn't
the most lovely but it works. From your example you would use: gamma =
foo.op_Addition(bar)

Lastly, I don't think the fact that VB.NET has a not-so-elegant way of
handling operator overloading means that it's only good for "Hello World"
apps. There are things that are nicer to do in C# and there are things that
are nicer to do in VB.NET (interop with Office apps being the classic
example), but there are *very* few things that one language can do that the
other can't.
 
apps. There are things that are nicer to do in C# and there are things
that
are nicer to do in VB.NET (interop with Office apps being the classic
example), but there are *very* few things that one language can do that the
other can't.
Click to expand...

What, in your opinion, makes VB.Net nicer for interop with Office apps? I'm
doing some of it in a VB.Net application of my own, but I didn't notice
anything about doing it in VB that seemed any different or easier than it
would have been if I'd been doing it in C#. Add a reference to the Outlook
11.0 Object Library, do a using for the namespace, and hi ho off we go. Did
I miss something important?

Thanks,
Tom Dacon
Dacon Software Consulting
 
Tom Dacon said:
What, in your opinion, makes VB.Net nicer for interop with Office apps? I'm
doing some of it in a VB.Net application of my own, but I didn't notice
anything about doing it in VB that seemed any different or easier than it
would have been if I'd been doing it in C#. Add a reference to the Outlook
11.0 Object Library, do a using for the namespace, and hi ho off we go. Did
I miss something important?
Click to expand...

I gather optional parameters and late binding can make interop with
Office significantly easier. That's just what I've heard though - I
haven't done any myself.
 
See inline below...
Secondly, VB.NET 1.0 and 1.1 can use overloaded operators. The syntax
isn't
the most lovely but it works. From your example you would use: gamma =
foo.op_Addition(bar)
Click to expand...

I wish people would get in the habit of assuming that someone else will use
their code. Technically, yes VB can use operator overloads. However, that
assumes that the VB developer knows they exist. The odds are much higher
that the VB developer will not know they are there and try to wire up their
own special function that does the same thing as the overload. Of course,
later down the line it will be far from obvious why a change in the overload
logic doesn't affect the VB developer's code.

Lastly, I don't think the fact that VB.NET has a not-so-elegant way of
handling operator overloading means that it's only good for "Hello World"
apps.
Click to expand...

IMHO, the statement "isn't the most lovely but it works" is the same as "a
not-so-elegant way" is the same as "insane vbonics solution that will cause
nasty hard-to-detect bugs when people use my code".

Think of the scenario: you want to build 1.x components that will be used by
other developers in an enterprise. If you use C#, your developers can easily
utilize a greater percentage of the CLR. In addition, you make operator
overloads such that your GUI developers do not even need to know they exist.

If you have some developers using VB in your company, then you have to code
everything to the CLS and you lose the ability to create *seemless* operator
overloads.

There are things that are nicer to do in C# and there are things that
are nicer to do in VB.NET (interop with Office apps being the classic
example), but there are *very* few things that one language can do that
the
other can't.
Click to expand...

I completely agree that there are somethings that are easier to do in
VB.NET. However, assuming that your VB people will use your C# operator
overloads is a bug waiting to happen.

With all that said, I still can't fathom why VB.NET cannot *use* operator
overloads seemlessly. I can understand why VB developers might not want
them, but I fail to understand why VB.NET can't use them if they are in a
compiled C# dll. Doesn't it read the MSIL and see that C# has overloaded the
"+" operator?



Thomas



--
Rob Windsor [MVP-VB]
G6 Consulting
Toronto, Canada


Thomas said:
I fully disagree with people that say that VB.NET 2002/2003 is equivalent to
C#.NET 2002/2003. I was originally a high level VB6 developer. When I first
look at the original betas of .NET, I chose C# for a couple of reasons.
Firstly, Microsoft might as well have called VB.NET, "Fred". Only simple
syntatic similarities exist between VB6 and VB.NET. Other than that, they
are very different products. Secondly, VB.NET, for some idiotic reason, was
limited compared to C#. Silly things like unsigned integers were not
included. Lastly, as I began developing with C#, I discovered that VB.NET
had/has a HUGE limitation. VB.NET 2002/2003 cannot use operator nor
conversion overloads built in C#. That means if you build classes that
are
to be used by other developers, those other developers cannot use VB.NET
either because they have to hack their code to death to utilize
conversion
and operator overloads. For example:

Suppose someone in C# builds a couple of classes and overloads the "+"
operator. You could write the following:

MyClass foo = new MyClass();
MyClass bar = new MyClass();
MyClass gamma = foo + bar;

In VB.NET, they would have to write something like (not sure the exact
syntax):

Dim foo as MyClass = new MyClass();
Dim bar as MyClass = new MyClass();
Dim gamma as MyClass;

gamma = foo operator+ bar;

Insanity that VB.NET 2002/2003 cannot even *use* overloads built and
compiled in C#. So, prior to Whidbey, I would say that if you want to build
nothing but "Hello World" apps, you could use VB.NET, otherwise use C#. Note
that this opinion has absolutely nothing to do with performance which is the
same between VB.NET and C#.

Whidbey changes all that. Microsoft has added most of the new goodies to
VB.NET as well as C#. In addition, VB.NET 2005 includes operator
overloads
so, theoretically, VB.NET developers can use components with operator
overloads built in C#. I'm not yet sure if VB.NET can use conversion
overloads written in C#.




Thomas
Click to expand...
Click to expand...
 
Back
Top