As someone who was a VB developer back when VB.NET first shipped twenty years ago, I'm kind of surprised by this. VB.NET was very clearly a second-class citizen in the .NET ecosystem even back then. While Microsoft paid lip service to supporting it equally with C#, it was very clear from the huge volume of documentation, tutorials, books, etc. they put out for C# compared to the tiny volume for VB.NET that C# was where they really wanted developers to be. And syntactically VB.NET felt more like C#-with-training-wheels than "classic" VB anyway, which reinforced the impression.
Given how big C# ended up becoming, I'm wondering why anyone committed to staying in the .NET ecosystem would have stuck with VB.NET all this time. What's the attraction? I could see it as a transitional stage to get classic VB developers started on the road to C#, but as a long-term solution it seemed doomed to chronic suffering from birth.
I remember this slightly differently; the change to C# was swift and rather brutal, but VB.Net was very much the default choice for most organisations transitioning from VB. In 2001-2002, seeing C# in production eluded a response along the lines of "wow, you guys are quite brave, kudos". By 2003-2004 though, the switchover had pretty much happened, nevertheless there were still swathes of legacy code to be maintained. At least, this was my experience in the handful of companies I worked with around then.
I've seen several moderately large and active projects (5+ developer maintenance team) still surviving to this day, running on VB.Net. In most cases though, these were started in the mid-2000s, simply due to manpower questions, not language advantages. I recall being moderately surprised even circa 2008 that the author of CSLA.Net (an interesting object-oriented framework) was mostly using VB.Net. I guess from their point of view, they were more proficient in that languages, and the cost of switching was too high. I definitely don't see any rationale for benefits, akin to say F# vs C#.
That is how it was for my shop too but honestly I think the semantics of VB.NET was always closer to C# than it was to VB 6. I remember working on a mixed code-base and it was absolutely effort-less because the semantics and of course the libraries were all identical, you just had to switch syntax. Syntax isn't really what takes time to learn in coming up to speed in a new language; what takes more time is language concepts, semantics, APIs and tooling. Once you realize this and observe the fact that C# is winning mind-share there didn't really seem to be any need for VB.NET. It really seems to me like it should have been stopped entirely ~2006 but Microsoft just doesn't do that to products, to their credit in most cases.
Yes, I completely agree. Syntax can be a stumbling block for beginners, but is generally far easier to re-learn than core libraries, or semantics, etc. That said, the syntax shift from a basic-like language to a C-like language is slightly larger than what we are generally used to, within the C-like families. I recently had to work on some VB.Net code, and aside from the occasional "let me Google this quickly" moment for surprisingly basic concepts, it was a breeze for the reasons you mentioned.
I think the MS world of the time was very much a monoculture (and would be until circa 2010 or so), which lead to a lot of developers who had only ever really worked in one main language (plus maybe SQL / T-SQL). I tend to think this is quite similar to children growing up in a single-language vs multi-language environment. The patterns tend to get ingrained in your brain in the former, and there are few signals for our brain to understand that "this concept can actually vary from language to language, don't get too used to it", making later shifts much more difficult. It's kind of a case of over-fitting the data, which is the first language they learned, in this case. I think a lot of the VB and then VB.Net developers had this kind of strong mono-culture of language, which compounded the need to keep VB.Net alive for longer. This may have been further compounded by VB's image as a beginner-friendly language, which a lot of people took up to get into the industry as outsiders, without any formal or informal experience. I really do think this might be the main factor. VB.Net may have had a few tiny advantages in terms of semantics (slightly looser casting and conversion rules), syntax clarity ("static" vs "Shared" - an example of a keyword which is objectively clearer in VB, IMHO), or some convenience libraries (I recall occasionally having to reference core .VisualBasic assemblies to get hold of some helper method which was missing on the C# side, for no apparent reason). But it also had just as many detractors, and I would not think any of these were nearly enough to lead to people choosing it over C#.
I think I must be the only person alive who actually prefers Pascal-style syntax (VB, VB.NET, Delphi, PL/SQL) to C-style syntax. There are lots of small nice things, such as distinct keywords for end blocks ("End Try", "End Loop", "End If"), and syntactic sugar like the "With" keyword. Intellisense in Visual Studio still seems to work better in VB.NET than C#. It does look comparatively simple; but I'd prefer the complexity of my code to be mitigated by the syntax, not exacerbated by it.
I've had to deal with a codebase that's part VB.Net and part C# for the last 6 years.
I don't really feel any pain switching between them, apart from VB.net is a bit annoyingly verbose and I always forget how to do linq lambda functions in it.
One tip I would add is that you can change the colour of the matching {} when you're in a block scope. VS actually highlights the opening and closing of the block. Usually not much of a problem due to auto-indenting, it can help a lot with complex code.
For some idiotic reason the default is a very light grey, but if you make it darker or a different colour, picking out ending } or starting { becomes trivial.
Ada is a lot like this too. I can read, compile and run it in my head during a gerrit review with almost no glitch by now. Written once, read 20 times at least.
There was some talk on HN yesterday about making your code easily changeable. First step is to make it easily readable, understandable. Little things help. End loop helps. Exit loop_name helps. Non-fallthrough case statement help. in / out / in out help so much. Pre and post conditions help also. Clear static types help. Internal functions help. Explicit generic instantiation, while a pita to write, helps a lot at code read time... Lots of lead bullets.
As someone with a passion for programming language design, this is very intriguing indeed. I wonder if a more verbose and explicit language is indeed better...
AppleScript pairs a concise writing syntax with a verbose reading syntax. The writable->readable translation is done automatically on save - think first-class clang-format.
As a simple example you can write an if block with `if...end`, and this will be automatically rewritten as `if...end if`.
I wish every language had built-formatting and also made the reading/writing distinction!
I have to agree: VB has better syntax, at least for my head. In addition to better block-boundary-matching, I like the type name coming after the variable name. It's silly to put the type first, especially for long ones. And it has a much better SWITCH/CASE statement. Having to use "_" for line continuation can sometimes be annoying, but at least you don't have to deal with semi-colons.
In C-style syntax there's often disagreement on how to format blocks, but there's rarely a disagreement in VB: there's naturally only one choice.
Maybe take the best of VB and Pascal, clean up the key-words by tossing legacy inconsistencies, and produce a next generation "word-oriented" style. #MVBGA!
You are not the only one. I can see a few around me, and there aren't that many developers here :)
Personally, I think every balanced marker (parenthesis, block beginning/termination, brackets) adds a maintainabiliy cost and is better replaced by some unbalanced alternative (on the case of blocks, semantic whitespace is the current winner). The largest the thing inside the markers, the higher the cost.
This. I flip between both languages all the time and without issue but I have to say in VB.Net I never have to go looking for that random missing brace that is throwing the entire structure off. I spent enough time doing that in my LISP days. :)
As for the complaints of something being verbose, I see people constantly adding comments to close braces to indicate what it was they closed.
The Verboseness starts to get very real when you are dealing with inlined Expressions/Functions. But maybe that's not what a normal VB.NET project has a lot of.
And, for whatever it's worth, it can encourage people to not inline which probably would be more maintainable anyway.
> As for the complaints of something being verbose, I see people constantly adding comments to close braces to indicate what it was they closed.
Lazy commenting. If you are for some reason dealing with code complex enough to need to keep track of it like that, instead take the time to comment what's happening next as a way to help the reader infer.
Because, let's face it, if it's complex enough to need to track those things, there's a decent chance it's worth leaving some explanations of what it's meant to do.
in my opinion, if you are having issues with mismatches braces, you have too much code in your file. I have seen this issue with God classes (which seem to be more prevalent in VB codebases)
If I am at the end of a long code block in C# or JavaScript, I might see this:
...lots more code up here...
return result;
}
}
}
return -1;
}
What's that next-to-last "}" for? To find out, I need to scroll way up, and hope the code is properly indented, or use an IDE feature to collapse the block.
But with a Pascal-family language, it would be more like this:
...lots more code up here...
return result
End If
End Loop
End While
return -1
End Function
It is more verbose - but its verbosity with a purpose, and it helps me avoid the distracting question "What is ending here?".
I recognized that I had to move from VB.Net to C# because that's where the jobs were 15 years ago. Anyone sticking it out now won't quit until they have zero options left.
I actually quit a company in 2004 because they decided to go VB.net first. Was a good move because they are still on it and up shit creek now. I’m not sure how they managed to retain any staff as long as they did.
I did a lot of VB6 around the time C# took hold. I initially thought that switching to VB.NET was the move, but with the .NET framework the whole paradigm shifted anyway so I figured I would go the way of the curly bracket. I was also tinkering with C/C++ at the time doing DSP/VST plugin development so while VB was a great RAD/Line of business platform it quickly ended up feeling verbose(most of the time, but sometimes not) and clunky. I soon could parse curly bracket languages much more quickly as well. Be it nostalgia or stubbornness I don't see a problem with sticking with VB if that is your jam, but you cant expect the world to not move on either...
We moved from vb6 to vb.Net and within about 2 years it was clear that c# wa the path forward. We transitioned after that but still have legacy apps that combine both. It was actually the smoothest, least painful technology dead-end I've ever experienced.
Given how big C# ended up becoming, I'm wondering why anyone committed to staying in the .NET ecosystem would have stuck with VB.NET all this time. What's the attraction? I could see it as a transitional stage to get classic VB developers started on the road to C#, but as a long-term solution it seemed doomed to chronic suffering from birth.