6 ms·

I think they should quit with VB support not because there is anything wrong with it, but because it is, now, identical to C#. It is just C# with words replaced

I think they should quit with VB support not because there is anything wrong with it, but because it is, now, identical to C#. It is just C# with words replaced. This is nonsense. I would donate many beers if they halted all VB work and put those guys and gals on F#!

btilly 10y ago
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.
- runjake 10y ago
  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.
  - btilly 10y ago
    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.
  - Zardoz84 10y ago
    Or throw it to the trash and rewrite it
    - krylon 10y ago
      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.
AnthonyDGreen 10y ago
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.
madiathomas 10y ago
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.
- krylon 10y ago
  Never having touched VB.Net, that makes me kind of curios: Would you care to name a few of those features?
  - smoothdeveloper 10y ago
    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.
    - krylon 10y ago
      Thanks!

btilly 10y ago

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.

runjake 10y ago
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.
- btilly 10y ago
  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.
- Zardoz84 10y ago
  Or throw it to the trash and rewrite it
  - krylon 10y ago
    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.

AnthonyDGreen 10y ago

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.

madiathomas 10y ago

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.

krylon 10y ago
Never having touched VB.Net, that makes me kind of curios: Would you care to name a few of those features?
- smoothdeveloper 10y ago
  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.
  - krylon 10y ago
    Thanks!