As someone who was writing Visual Basic.NET back when it came out, there was no upside to it over writing in C#. VB's original sweet spot was for writing small scripts and apps in Windows, and it was the only language available. When the .NET line came out, you could do the same things in whichever language you wanted. When new tasks came in, I started defaulting to C# for that reason. I don't think anyone actually prefers VB syntax. C# has a pretty robust community around it now.
> When new tasks came in, I started defaulting to C# for that reason. I don't think anyone actually prefers VB syntax. C# has a pretty robust community around it now.
Which was your experience because you knew C. VB appealed to people who were not programmers (or not very good ones like me). Microsoft effectively tossed an easy to learn procedural language in the trash and said "go learn all these advanced CS concepts or stop writing stuff" to which most hardcore VB users chose the latter.
While maybe that's true, that doesn't map to my experience very well. After QBasic, I wrote a lot of Visual Basic 5 and 6. I had poked at C, but would not say I knew it, and had never done anything useful in the language. But I did exactly one thing in VB.NET before trying C# and realizing that it really did encapsulate and present a better way to think about code. It's not perfect, but it's much, much better--and in that era, .NET 2 or so, it was significantly more ergonomic and had better tooling than Java or PHP, the other two languages I learned about contemporaneously with C#.
Maybe there's a mass cohort of people who were simply not going to learn something new, but in the light of most of twenty years hence, I think that they made the right call.
I've worked with a ton (too many) VB programmers by virtue of the work that I do (UI automation).
My experience all suggests that pure-VB (even .NET) is a treacherous dead-end, because it doesn't scale in terms of complexity and project size, and the point at which is stops scaling is often unrealized by its developers.
- VB(.NET) is amazing for small, simple gadgets.
- VB(.NET) is terrible for large or complex systems.
The problem is that VB is likely to be the only programming language that developer knows (moreso than developers in other languages).
Consequently, when they reach the end of the reasonable VB road... they will NOT say "Oh, I should learn C#."
They will say "How can I make this work in VB?"
And that's when you start to get business-ending unsupportable messes of spaghetti code that just barely work, on a good day.
Give a person only a hammer, and they'll find a way to make the entire world a nail.
> VB(.NET) is terrible for large or complex systems.
This doesn't make sense to me. I worked in a 50/50 VB.NET/C# codebase for years and while I don't love the VB syntax, the two languages were 99% interchangeable. Nearly anything you can do in C# you can do in VB.NET, and vice versa.
Lol, it doesn't scale because of the quality of the programmer, not because of the language. There may be some self-selection there but it isn't because of the language or tooling. Any "too easy" language brings these comments. People complain about MATLAB too when in fact there is nothing wrong with it or VB. Of course you can abuse both for purposes they are not meant for.
> VB(.NET) is terrible for large or complex systems.
C# and VB.net are semantically 100% identical. Only difference is surface syntax, like begin end instead of curly braces. It scales exactly as well as C#.
> - VB(.NET) is terrible for large or complex systems.
I can't say I agree with this. My experience has been that developers who write things in VB tend to be self-taught and don't know how to scale up small gadgets into large systems.
You may be confusing Visual Basic .NET with Visual Basic 6 and its predecessors. C# actually predates VB.NET by about a year.
VB.NET may be syntactically similar to VB6, but under the hood they were so different that migrating projects to VB.NET essentially meant a complete rewrite.
Visual Studio had a built-in migration utility which could get you 80-90% there. However if the original VB6 was spaghetti code written without Option Strict and Option Explicit enabled you had much bigger problems.
The biggest breaking change was the removal of the global Printer Object so any printing code needed a complete rewrite.
My recollection is that the migration tool was really just a tool that would fill your VB6 code with comments telling you that you had to rewrite stuff. Trouble spots were largely related to error handling On Error Goto and error handling blocks had to be refactored into proper Try...Catch blocks, which affected a lot of code, and another trouble spot was all File I/O had to be rewritten/redone, same with any drawing code; Resource files had to be recreated, etc; I don't even think it could load the FRX files but I might be misremembering. I felt it simply wasn't worth even bothering to try to directly convert to VB.NET, and since those programs I wanted to move forward I had to pretty much rewrite anyway, I decided to use C# instead and just make new versions.
The migrated VB6 code I saw back in the era when VS2003 came out was a thin glue layer over some compiled DLLs. So the result of using the converter was a thin VB.NET wrapper around very outdated, vulnerable, unsupported third-party code.
Maybe other shops had a lot of pure VB6 code, though.
