It never was and never will be identical to C#. They share a lot but there are hundreds if not thousands of subtle differences between the two. It's just easier for people to 'think' that VB is just C# with a search and replace because... that's a lot shorter to say. If you were to look at the compilers themselves or try to write a perfect automatic conversion tool you'll quickly see that far from identical.

For example, VB Select Case and C# switch work nothing like each other.

Yes, they have a pretty dissimilar philosophy. XML Literals, different event handling/wiring, no need for event delegates, inline date declarations, explicit integer division operator, the Module concept, the My namespace, etc.

> If you were to look at the compilers themselves or try to write a perfect automatic conversion tool you'll quickly see that far from identical.

There's so much truth in this.

Telerik has a online conversion tool[1] you can us, which can batch convert entire code-bases. But a 1-to-1 straight conversion cannot be done with 100% accuracy, and the tool will tell you everywhere it struggles to figure out the right C# equivalent for the corresponding VB.Net code.

I've used this tool in the past to "eliminate" the last remnants of VB-code in our organization. And when you do a job like that, on that scale, you definitely notice the differences.

A quick list of things you can expect to cause troubles (from memory and may not be 100% accurate):

- The difference in VB global/C# static semantics.

- The (default & overuse) of late-binding in a typical VB codebase. (While that wasn't an option for me back then, this can now be overcome by using "dynamic" everywhere, but that's hardly idiomatic C#)

- VB Modules can cause issues.

- For a full conversion, you'll typically have to rewrite all code using the functions and operands only found in the Microsoft.VisualBasic namespace. Not all these have straight up C#/BCL replacements.

Etc etc.

For being superficially so similar, a conversion job is actually much more work than you would typically imagine.

[1] http://converter.telerik.com/

Isn't Microsfot.VisualBasic just as much part of C# as it is VB or any other .Net language?

The rest of your points all sound like bad practice anyway so hopefully people are already avoiding them.

> The rest of your points all sound like bad practice anyway so hopefully people are already avoiding them.

Welcome to the real world. I can tell you're new here :)

And until VS2013 the IDE was nothing like either. I think with VS2015 both have mostly converged but I must say it is a bit of a regression for the VB IDE.

Hundreds or thousands of differences? Do you have a citation for that?

He is the program manager for VB...

While I was/am a bit incredulous at the number I was hoping for some sort of list or summary. Just sounds like a lot.

Read the source for the compiler and find all the differences. There are constantly minor semantic changes, like numeric conversions, double parsing, scope of generated temps in for loops, delegate conversions, Nothing, etc.

I just started typing this list off the top of my head and every time I typed something out I could think of one more thing. And these are just the ones I remember, so they're probably the ones that were annoying to work around in the compiler.

Even so... with numbers like that we need proof!

As long as paying customers have legacy VB code, Microsoft has a very good reason to continue supporting VB.

Companies generally spend a lot more money maintaining legacy code than they do creating new code.

Legacy VB != VB.net. VB.net is just C# with the words replaced (although there are a few unique logic structures). Legacy VB code has to be ported to VB.net.

You should parse my statement as (legacy (VB code)) and not ((legacy VB) code).

At this point anything written in VB of any flavor is legacy. But it still needs to be supported. And as long as that is true, Microsoft has reason to support it.

Or throw it to the trash and rewrite it

In an ideal world, this would probably happen quite often, but on a large and complex code base, it also means throwing away the specific knowledge that might only exist in the heads of people who have already left the company, as well as throwing away the countless hours of debugging to get it working (even if "working" might mean "barely working").

From a management point of view, it means throwing away a large amount of money and then spending more money to replace the old code base, accompanied by the usual risk of whooshing deadlines and all that.

To a programmer it might be easy to see that a rewrite will save the company money in the long run, that can be difficult to sell.

Existence of VB.NET doesn't bother me at all. I develop exclusively in C#.NET but there is a lot of VB.NET language features I wish were available in C#.NET.

Never having touched VB.Net, that makes me kind of curios: Would you care to name a few of those features?

better type inference for anonymous functions, better type inference for instance members.

Another big feature is code layout being more compact and consistent than in C# codebases.

Thanks!