C# or VB.. Did anybody go about deciding which one is good for the team.

[KN]

I know both are pretty much the same and it comes down to personal choice.
But I have to make the choice for the team. Things so far that I am
considering

1. XML documentation in C# -- thats good.. not there in VB.net??

2. Some language features of VB.Net like Redim(makes it easier for
developers), but not good enough reason.

3. C# is in more like standard languages and key words used are more
standard. It kind of makes it easier for C# developers to communicate with
developers in other languages similar to C.

4. Moving to C# might have a higher learning curve for a developer with a VB
background. But I think C# can help in encouraging good development
practices and the language itself is simpler than VB.Net

5. Finally I think if you are developing multi layered application, I am
leaning on developing the middle tier in C# and the presentation with
VB.Net.. Its just RAD.

Thoughts and other opinions on this please!!!

KN

 

[Marina]

First off, you should not need Redim. I haven't yet, the collection objects
that grow dynamically are very good at this. And you hardly ever need arrays
at all.

I think #3 is not a good enough reason, considering there is already the
fact that you have VB developers.

As you said yourself, the language are very similar. There is functionality
in each of them, that the other does not have. But if this is not an issue,
then the language choice is not either.

Since you have a VB team, they should continue to use VB, as this will have
the smallest learning curve. Once they know and are comfortable with .NET,
they will easily learn C#, as for most thing there is a one to one
correspondance.

Also, if you do a search on google groups, you will about 1000 threads with
the same question...

 

[Robert Jacobson]

Check out these links:

http://support.microsoft.com/?kbid=308470

http://www.desaware.com/Ebook2L2.htm

Other comments inline...

1. XML documentation in C# -- thats good.. not there in VB.net??

It's not built into VB.Net, but there are several plugins that add this
functionality.

http://www.gotdotnet.com/team/ide/

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvssamp/html/vbcs_XMLComments.asp

The IDE has one feature that's only for VB.Net -- background compilation.
It immediately warns you about coding errors with a squggly line and an
error message in the task list, rather than making you wait until compiling.
I love it, and miss it when coding in C#. Other people find it annoying.

2. Some language features of VB.Net like Redim(makes it easier for
developers), but not good enough reason.

3. C# is in more like standard languages and key words used are more
standard. It kind of makes it easier for C# developers to communicate with
developers in other languages similar to C.

As you mentioned, selecting C# or VB.Net really is just a personal
preference -- they both can do almost exactly the same things with about the
same performance. (Yes, C# will let you use unsafe code, but how often will
you want or need to do that?) VB has more keywoards -- some that are useful
(like the With/EndWith) constructs, and some that are primarily legacy
keywords that you might want to avoid. (I try to use the .Net Framework
methods, rather than VB keywords, wherever possible.)

If you and your development team are more comfortable with C-style keywords
and language constructs, go with C#. If you're more familiar with Visual
Basic, go with VB.Net.

4. Moving to C# might have a higher learning curve for a developer with a VB
background. But I think C# can help in encouraging good development
practices and the language itself is simpler than VB.Net

A valid consideration. A VB6 developer who just moves to VB.Net without the
proper training could develop some bad habits. The biggest paradigm shift
is that VB.Net is now a fully object-oriented language, and it takes some
time to get used to this. The more important consideration is to ensure
that the developers get enough education regarding the new language --
whether it's C# or VB.Net. (There are several good books for VB6
programmers who are moving to VB.Net, particularly from APress.)

5. Finally I think if you are developing multi layered application, I am
leaning on developing the middle tier in C# and the presentation with
VB.Net.. Its just RAD.

Don't mix-and-match the languages just out of a sense that "that's how it's
done." You could just as easily use VB.Net for both layers, C# for both
layers, or C# for the presentation layer and VB.Net for the middle tier. I
think that your rationale is just a holdover from the old days when VB6 was
used for front-ends because it had better RAD features for developing user
interfaces, and C++ was used for the middle layer because of better
performance and power. These considerations no longer apply.

There's nothing wrong with using both languages, and there's a benefit to
learning both. But if your programmers are more experienced with one
language, it would be a better practice just to stick to that language for
day-to-day development.

Hope this helps,

Robert Jacobson

 

[SR]

Hi
Agree with most of the points but for the first one :

First off, you should not need Redim. I haven't yet, the collection objects
that grow dynamically are very good at this. And you hardly ever need arrays
at all.

With the features offered by collections, there might be
a tendency to do away with arrays completely. This could
be coz the jazzy methods offered by the collection and
related classes might be attractive. But there is a
performance issue here

Do note that collection takes a parameter of the object
type. this means that if i use a collection to store a
group of integer values , every time i add/retrieve an
integer, there will be a boxing and unboxing(which is
costly). Arrays are more suitable here coz u can declare
an integer array, add/retrieve the same without any
problems.

So i feel that collections are good when
a) u use reference types
b)u want to group multiple types of data in a single object
c)u do not know the type of the object and it wil be known
dynamically, but u want a generic object which can hold
all the types

So If
a) you know the type clearly at design time
b) all the types in the group are homogenous

then arrays are better

Would appreciate if some one has any comments on this

regards,

sr

regards,

sr

 

[guy]

Rob, 100%Ack
I have spent 50% of my time using each language and at
first was marginally in favour of C#, however i have now
swung round to VB.NET but theres not much in it.

Background comiplation is very good

two other points - I find reading VB.NET easier as you
can see more clearly that a method is a
Function/Sub/Property, and that a Property is readonly
when collapsed - it is not so clear in C#

c# compiler warns you if there is no reachable code path
and also it a function does not return a value.

hth

guy