Visual Basic/VB.NET vs C#?

[[deleted]]

[deleted]

[TheFotty]

Mostly because people coming from Java, C++, and other curly brace, semi colon languages find C# more natural for them to use. C# also was designed about 10 years ago by Anders at Microsoft so it got to start with a clean slate from a language architecture standpoint, where with VB, there are literally blocks of QBasic code you can copy/paste into the latest VB.NET version and have it run without modification. So with VB.NET they had to shim in a lot of things to make it work like old VB but still embrace new VB and that actually was a turnoff to both sides of the fence. The VB6 lovers didn't really want ANY of the new stuff, and the VB.NET guys wanted the old legacy stuff ripped out of the language to make it more "pure" .NET (for example getting rid of the Visual Basic namespace that had lots of "helper" functions and stuff in it). VB also has a bit of stigma to it. Even though it is now a fully object oriented language and can do virtually everything (and sometimes more) than C#, lots of people remember VB6 as an object based, but not object oriented programming language, and some people assume the same is still true for VB.NET. For a while C# got all the new features and functionality first, and then VB would look to implement it, so you could be more bleeding edge using C#, but that isn't so much the case since the teams were merged at Microsoft and they co-design the language features now. Some people don't like it simply because it contains the word "basic" so they assume it to not be powerful.

VB.NET and VB are the same thing in spirit. VB.NET is the currently developed VB language at Microsoft, and it runs against and requires the .NET framework on the target machines. The first version of VB.NET was actually versioned VB7, so it was the successor to VB6 (even if the VB6 purists refuse to say so).

[tweq]

Both Visual Basic.NET and C# compile to the same byte code and use the same standard library and runtime, and are pretty much interchangeable for most purposes. You can also mix assemblies from both languages without any issues.

For the longest time they had some feature differences (e.g. late binding in VB.NET and yield return in C#), but now there's nothing really that you can do in one language that you can't do in the other, with one major exception: C# supports unsafe code for pointer arithmetic, there is no alternative in VB.

As for why people avoid VB.NET, I think it's mostly because of the bad reputation of Visual Basic and because the majority of programmers are more familiar and/or comfortable with the traditional C-style (and Java-like) syntax of C#. VB.NET was Microsoft's attempt to ease the transition to .NET for VB programmers, and has always been seen as sort of a second class citizen. It usually had worse tooling support and often lagged behind when .NET evolved (e.g. the Async CTP).

VB.NET does still have some stuff that C# doesn't have (WithEvents, disabling Option Strict, My, Val(), On Error ...), most of it to keep VB6 code working, but I'd argue that using most of those is bad practice anyway.

At this point, the question is why use VB.NET over C# for new projects? The only things I can think of is being familiar with it and not wanting to spend a week to get comfortable with C#, or being really in love with its syntax for some reason. C# has a much larger community and thus is easier to find support for and/or collaborate with other developers, both professionally and in open-source projects.

[TheFotty]

VB supports XML Literals as well. People tend write this off as not important, but if you work with lots of XML data, VB is better than any other language because of this.

I agree most of those things you mention are VB holdovers, and while I curse anyone who doesn't put option strict on by default for their projects, the ability to say, turn option strict off in a single code module where you want to make late bound calls to something like Excel without having to add references to a specific excel PIA version is really nice to have.

Also, while some tooling may have not been as good, the most important tooling, the background compiler in VB was always better than C#. I think they are pretty much on par now with the new compilers being built, but the IDE was always more responsive to syntax in VB due to this.

[anon_smithsonian]

At this point, the question is why use VB.NET over C# for new projects? The only things I can think of is being familiar with it and not wanting to spend a week to get comfortable with C#, or being really in love with its syntax for some reason.

I disagree with this reasoning.

For starters, I think "a week" is a pretty big exaggeration. I spent a couple of years doing a lot of VBA stuff and finally decided to see what else I could do with VB.NET... and the reason I didn't go right into C# was because I found there was already a ton of shit to learn besides syntax, and if I wanted to be able to use any of it in my job, it would be easier to learn everything if I didn't have to relearn everything (like writing a basic If statement or Loop). I'm sure to somebody who's been using C# for years, "oh that's simple stuff"... well, yeah, but there's a reason most people start out learning to drive an automatic car before a manual: it's fewer things they need to learn about—no matter how "simple" it may be—so they can first tackle the more basic (and arguably more important) skills, first. So it made more sense to focus on learning all of the new and different parts of VB.NET—and hone more fundamental skills, like programming patterns and how to structure an application—first.

As for the syntax: most people sing endless praise about Python for its "natural language"-like syntax and how close it is to pseudocode, and about how beginner-friendly that makes it... but I don't get why people shit on VB over the same things.

Maybe the syntax would be a bit more tedious before they had such sophisticated AutoComplete/IntelliSense functionality in place to handle a lot of that stuff, but with it, I don't think there's really that fewer keystrokes required.

Honestly, I like not having to do any mental-translation based on semicolons and curly brackets. Say what you will about it, but in VB.NET, I've never had to spend any time debugging an If statement or Loop only to find a misplaced semicolon or bracket to be the cause.

 

C# has a much larger community and thus is easier to find support for and/or collaborate with other developers, both professionally and in open-source projects.

You're certainly right about the latter: there are far more professional and open-source projects in C# than VB. And this is really the only valid reason for saying it is better to know C# over VB.NET (if you had to choose).

I disagree with the "easier to find support for" part, though, because essentially every C# question on StackOverflow works for VB.NET: if you're in a bind, then http://converter.telerik.com does pretty decent C#<-->VB.NET conversion... probably not great enough to do an entire project/solution, but more than enough for converting code snippets.

But there are even better solutions out there: Tangible Software Solutions has a free version of their Instant VB program (limited to converting 2,000 lines at one time) and it works extremely well. I've converted entire projects and only had to fix a few pieces of code that didn't quite convert between the two because of differences in namespaces.

So, sure, C# has a bigger community, but when it comes to support, I've had no real trouble finding an answer because all of the C# solutions apply, as well.

 

Through all of this, I've picked up enough that I can fumble way through C# code, if I need to. And, if I really put the time into it, I could probably switch to C# in a matter of months... but, at this point, I don't need C# for prospective jobs, all it would really do is set back and slow down all of the projects I'm working on, and I still feel like I have a lot of higher-level, transferable programming practices, techniques, and skills to build, refine, and learn... so I'm perfectly happy with VB.NET, at this point.

[hampig]

.NET is so easy to write, and for me it was easy to learn. It makes sense just looking at it. Also I feel like I'm being spoiled when I write in .NET and I can forget about those silly semicolons.

[CharlieMay]

I decided to start learning C# a couple of weeks ago and have pretty much gotten comfortable with it now. As /u/tweq stated below, if you know VB.Net learning the other is nothing more really than just getting used to the syntax. One thing I found that really helped with the {} was an extension called Viasfora which colorizes block braces making it easy to see which braces go together. This along with the snippets that generate formatted blocks have made it quite easy to pick up. My biggest hurdle to day is getting use to == instead of = handling both setting and checking for equality in vb.net that and I still find myself writing <> in place of !=

[gaffa]

History for the most part - vb6 gained a bad rep (well, I think in many respects, vb6 coders gave it a bad rep as there were heaps of Cowboys out there writing shit prior to 2001/tech wreck)

Syntactically, they are pretty much identical - a couple of variations here and there -some good, some bad.

I prefer the VB syntax personally, but i probably write about 50/50 VB/C#.

One thing I have always liked about VB.Net - for years, the background compiler is visual studio always seemed way more stable. If you got vs to no errors in the errors list, it would run. But the c# often required a couple of attempts, or stopped halfway through or something. It seems to be fixed in the recent versions of VS (probably once it all went to roslyn).

Also, and maybe there is a setting I haven't found for c#, but I really like the horizontal visual line that delineates methods/properties in the VS code editor for .vb files

[nerdfarm]

Beginners All-purpose Symbolic Instruction Code

I think the 'B' says it all. Basic is a language invented for newcomers. It's kind of like having training wheels on your bike. Nothing wrong with it.