I am just wondering: if you were starting a new project from scratch and you had a choice between using C# or VB.NET, which would you choose and
why? Personally, I am not interested in replies like "Well, I was a VB6 programmer and so VB.NET is the natural choice for me" or "I come out of the C/C++ crowd and so C# makes the most sense for me." I am wondering if there
is any technical or software life-cycle, etc., sorts of reasons. Thanks.

I have given this one some thought over the past couple of years, and I am fairly sure the answers you aren't interested in are the only ones that matter. Especially with the 1.1 improvements to vb.net, flavor is the choice.

For the record, I am a former VB 6 programmer who was tired of that lazy syntax and so craved the C like structure of C#.

I was a VB programmer and switched to C# when .Net first launched. The reasons why were much clearer then:

1. C# had XML documentation - VB.Net didn't

2. We had two centres of excellence: one for J2EE, one for Microsoft and programmers tended to be VB OR JAVA programmers - never the twain would meet. We saw C# as being a way, at least in theory, of making programmers more able to move to where the work was
needed, ie to move between the two worlds of Microsoft and Open Source J2EE - a move I still think Microsoft cottoned on to late in the game when suddenly they started telling us VB.Net was the way we should be going to avoid too many previously loyal developers
"jumping ship" to the J2EE world via C#.

3. Being in web development I found it was a nightmare switching between server-side VB COM components and client-side JavaScript. Too much time wasted trying to spot obtuse case-sensitivity or missing semi-colon errors in client-side script that kept arising
because of being used to coding VB for most of the time, and for which there was little debugging help client-side. C# set up the same "rules" with regard to semi-colons and case-sensitivity, both client-side and server-side meaning, in theory, less wasted
time making "schoolboy errors" when switching between the two environments.

4. .Net had only just been released. The first beta was all C# examples and the framework itself was allegedly largely written in C#. VB.Net was still debating whether changes should be made from VB6 at the risk of non-conformity with other .Net languages (eg
the 0 index array issue) which gave little confidence that VB.Net would be as well tested or proven come general release. It made sense to go with the "product" that appeared to have been through more testing.

5. We had over the years suffered quite a lot of "poor" VB programmers who just didn't "get" object orientation, where C++ programmers were much more familiar and rarely proved to be anything less than an asset. C# involved a learning curve (mainly one of syntax)
but that was small in comparison with learning object orientation and the framework and we figured the VB programmers who couldn't make the switch to C# weren't the sort of programmers we wanted to employ anyway! I think it was Don Box who rather unkindly
referred to VB programmers as "failed journalists and marketeers" - unkind, and intended as a joke, but representing a mindset that is quite common in the industry. I currently work with three guys who all come from a C++ background and I don't think they'd
have hired me if they'd known I'd come from a VB background

Having made the switch (and I found it hard - not the C# - but the properly "getting" OO which we'd only really paid lip service to with VB6) I couldn't go back to VB now. I look at VB.Net code when there are examples that might not be in C# and thankfully I
find it relatively easy to "translate" this into C#, but for me C# just seems more elegant or disciplined and VB.Net seems kind of sloppy. Your mileage may differ!

There are a lot of religious wars around languages of course. At the Patterns and Practices Summit last week at Reading one of the lecturers, getting some gentle ribbing about his examples being in VB from an audience that seemed more versed in C#, J2EE, C++
etc came straight back with "In the VB world We've had managed code since 1991", LOL! There was also a very cheeky article posted on DevX in the last week or two implying that C# people were lucky because with .Net they could now use the power of VB.

I think the official answer is it probably doesn't matter. The worst thing to do is let the programmers decide and ending up having to get expertise in both. I remember when we were making our decisions being amazed that an early adopter (a large supermarket
chain in the UK) told us that they didn't set a standard of one language over another and let the individual developers decide which language they wanted to use. A bit of a nightmare trying to recruit staff who now have to know two languages if they're going
to do support on any systems developed.

I think also that there are more jobs advertising VB.Net these days than C#, at least that's my perception, mainly because I think most shops have taken the lazy way out and assumed that VB 6 and VB.Net are pretty much the same thing and chosen to stick with
the "same" language they've been using for some time when moving to .Net.

Purely from a language point of view, VB.net and C-sharp are basically the same. As you noted, VB.net uses BASIC-style syntax and C-sharp uses C-style syntax.

C-sharp has some syntactic sugar for some of the more core classes in the .NET framework, such as collections and delegates while VB.net does not have as much.

As for the question about whether VB.net generates bigger assemblies, this is a difficult question. As with VB6, there is a VB.net runtime library which each VB.net-generated assembly depends on. This comes in the form of an assembly: Microsoft.VisualBasic.
C-sharp, on the other hand, generates standard IL code with few runtime dependencies. The VB.net result, then, will call more functions to get the job done, but the difference in performance will be basically negligible. The difference in size will be negligible
too if you assume that Microsoft.VisualBasic.dll comes with the .NET Framework anyway and thus does not need to be distributed.

I would advise that you just use whatever you are most confortable with, and if you have no specific preference then go for C-sharp because it's more closely integrated (and designed for) the .NET framework and generates native IL code which can be run more
easily on non-Microsoft IL interpreters which may not necessarily have the Microsoft.VisualBasic assembly available.

(Sorry about typing "C-sharp" throughout this post. Due to some unfortunate interactions I'm unable to type a hash/pound/sharp sign right now without resorting to Character Map!)

How many actually use both? What I am doing at the moment is using C# for ASP.NET pages with code-behind, and VB.NET for doing a quick control where the code is part of the page. It is good to actually learn both, as you never know what code you may inherit
in the future.

It should be relatively easy to translate the code between the languages. To help, you could set up a document that has comparisons between the languages (i.e. how to do the same thing in the different languages).

i.e.

VB.NET
Public Shared Function Foo(i As Integer) As String
...
End Function

Actually the correct answer on generated code and performance is "it depends". VB does generate some more noops (which are removed at compile time) to allow for a better debugging experience, for instance. The IL generated by each can be somewhat different,
but doesn't typically favor one over the other - for instance, some of the native VB functions can compile to faster performing IL than C#. For more information, check out the following:

Personaly I'm a VB6 to C# man myself. I'm not going to say ex-VB6 'cus there's times when a quick Out-Of-Proc ActiveX Exe is just too damn handy.

Moved to C# for reasons outlined more eloquently above. Although with the advent of the VS Tools for Office I'm predicting that VB.net makes a comeback. Just see how many times you can type System.Type.Missing before begging VB's forgiveness.

Sorry, I didn't mean to start a debate or flame-war. I come from the C/C++ world and latched on to C# myself but I know both C# and VB.NET very well; I hope it makes me more employable. I've never had patience with people who boost their egos by disparaging
VB developers.

Anyway, the reason for the post is that I am starting a job with a company that is building a .NET web app from scratch. All the developers are coming from the C/C++ world and so I was wondering why the VP of Dev decided on VB.NET. I thought to myself "there
must be some technical reason that I don't know about for choosing VB.NET". I hope the decision was not made via a coin flip as that would bode ill for the company.

Simo wrote:

ooo - two years on and the VB.net Vs C# debate still goes on.

Personaly I'm a VB6 to C# man myself. I'm not going to say ex-VB6 'cus there's times when a quick Out-Of-Proc ActiveX Exe is just too damn handy.

Moved to C# for reasons outlined more eloquently above. Although with the advent of the VS Tools for Office I'm predicting that VB.net makes a comeback. Just see how many times you can type System.Type.Missing before begging VB's forgiveness.

I use VB mostly for the design time experience which I didn't see mentioned above. I like the background compilation that lets me see and correct errors before that first F5. Also, I like the lack of parens in VB conditionals and loops; the fact that the
IDE autocompletes them for me is nice too.

Also, our team uses VB so I don't really have a choice (if you have a community preview of Whidbey, Microsoft.VisualStudio.Publish.dll is pure VB).

That is weird. Previous experiance in C/C++ usualy means a no-brainer move to C#. Am sure the die-hard C++ guys a re going to be gritting their teeth as they create their MustInherit classes.

I think it's the things like 'MustInherit' that are the worst part of VB.net. It's as if the VS team have assumed that the actual word abstract is too complicated for the target audience. It appears very condescending from my POV.

phunky_avocado wrote:

I am starting ... with a company that is building a .NET web app from scratch. All the developers are coming from the C/C++ world and so I was wondering why the VP of Dev decided on VB.NET.

Simo wrote:ooo - two years on and the VB.net Vs C# debate still goes on.

Personaly I'm a VB6 to C# man myself. I'm not going to say ex-VB6 'cus there's times when a quick Out-Of-Proc ActiveX Exe is just too damn handy.

Moved to C# for reasons outlined more eloquently above. Although with the advent of the VS Tools for Office I'm predicting that VB.net makes a comeback. Just see how many times you can type System.Type.Missing before begging VB's forgiveness.