4 ms·

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

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.

cm2187 10y ago
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.
MichaelGG 10y ago
Hundreds or thousands of differences? Do you have a citation for that?
- cm2187 10y ago
  He is the program manager for VB...
  - wuzzard 10y ago
    Even so... with numbers like that we need proof!
  - MichaelGG 10y ago
    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.
    - Locke1689 10y ago
      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.
jug 10y ago
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.
josteink 10y ago
> 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/ http://converter.telerik.com/
- averagewall 10y ago
  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.
  - josteink 10y ago
    > 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 :)

cm2187 10y ago

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.

MichaelGG 10y ago

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

cm2187 10y ago
He is the program manager for VB...
- wuzzard 10y ago
  Even so... with numbers like that we need proof!
- MichaelGG 10y ago
  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.
  - Locke1689 10y ago
    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.

jug 10y ago

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.

josteink 10y ago

> 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/ http://converter.telerik.com/

averagewall 10y ago
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.
- josteink 10y ago
  > 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 :)