3 ms·

VB.NET is shaped like the CLR, just like C#. (Similarly, Java is shaped like the JVM.) It is possible to mechanically transform VB.NET code into C# code. Heck,

VB.NET is shaped like the CLR, just like C#. (Similarly, Java is shaped like the JVM.) It is possible to mechanically transform VB.NET code into C# code. Heck, I'd bet they both parse to the same AST. They are very, very similar languages, with the exception of syntax. The upshot is that writing VB.NET involves understanding everything you need to understand to write C#. All the syntax is VB6-flavoured, sure, but it still involves making people learn about classes, this year's flavour of Windows UI components, and so on. What's more, you have to do it all in an industrial-strength IDE, with all the complexity that brings. (Don't get me wrong - Visual Studio is more or less my gold standard for a usable industrial-strength IDE. But if you stand it next to VB6, you'll see how much more you need to understand just to get to editing code is noticeably larger. It can be invisible to people like you or me, who have already absorbed these concepts, but it's real.)

WorldMaker 9y ago
VB1-6 encouraged classes. The fact that OO was not more popular in VB was a failure to communicate. VB.NET didn't add classes, it removed the anti-pattern that was grab-bag modules. Again, that's much more of a backwards compatibility problem than a CLR problem. The VB team could have kept modules and still targeted the CLR, they just chose not to in the hopes of cleaning up some of the worst patterns in VB. Just because you can "mechanically transform" code between two languages doesn't make them the same language. Compilation is a mechanical transformation to machine code, but you don't see anyone arguing C++ is the same language as Assembly. (Did you ever look at the output of such mechanical transformations? The results were always weird, lacking proper idioms in the target language. Just like machine translations of spoken languages, I wouldn't rely on them without a lot of work to clean them up and verify them.) Yes, VB.NET and C# share many (but not all!) components of the same AST, but so too now does F# as it is being brought over to the Roslyn compiler platform. Shared AST components also do not make a language "the same", because of that fun word "abstract" in AST. Just as most languages can be described in a BNF variant, fall into some variation of the category Context-Free Grammar, represent similar Pushdown Automata, etc. The underlying tools are very much the same across the vast spectrum of languages, but that doesn't mean all languages are the same/interchangeable. Also, Visual Studio is a direct successor to the VB6 IDE. Visual Studio .NET shared a lot of code with that IDE. I'd be surprised if VS today didn't have at least some code inherited down the many years from that predecessor (certainly plenty of ghosts of it in source control). The VB6 IDE was considered "industrial-strength" in its time, too. Given there's a free Community Edition of Visual Studio, and VB6 was never cheap, arguably the barriers to new developers to "just get to editing code" are at the lowest they've ever been, complexity or not. (Nostalgia is a weird fuzzy thing.)

WorldMaker 9y ago

VB1-6 encouraged classes. The fact that OO was not more popular in VB was a failure to communicate. VB.NET didn't add classes, it removed the anti-pattern that was grab-bag modules. Again, that's much more of a backwards compatibility problem than a CLR problem. The VB team could have kept modules and still targeted the CLR, they just chose not to in the hopes of cleaning up some of the worst patterns in VB. Just because you can "mechanically transform" code between two languages doesn't make them the same language. Compilation is a mechanical transformation to machine code, but you don't see anyone arguing C++ is the same language as Assembly. (Did you ever look at the output of such mechanical transformations? The results were always weird, lacking proper idioms in the target language. Just like machine translations of spoken languages, I wouldn't rely on them without a lot of work to clean them up and verify them.) Yes, VB.NET and C# share many (but not all!) components of the same AST, but so too now does F# as it is being brought over to the Roslyn compiler platform. Shared AST components also do not make a language "the same", because of that fun word "abstract" in AST. Just as most languages can be described in a BNF variant, fall into some variation of the category Context-Free Grammar, represent similar Pushdown Automata, etc. The underlying tools are very much the same across the vast spectrum of languages, but that doesn't mean all languages are the same/interchangeable. Also, Visual Studio is a direct successor to the VB6 IDE. Visual Studio .NET shared a lot of code with that IDE. I'd be surprised if VS today didn't have at least some code inherited down the many years from that predecessor (certainly plenty of ghosts of it in source control). The VB6 IDE was considered "industrial-strength" in its time, too. Given there's a free Community Edition of Visual Studio, and VB6 was never cheap, arguably the barriers to new developers to "just get to editing code" are at the lowest they've ever been, complexity or not. (Nostalgia is a weird fuzzy thing.)