Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

To me, Visual Basic seems clumsy, ugly, error-prone, and difficult to read. I'll let others explain why. While VB.net has clearly been a huge leap forward for the language in terms of features, I still don't understand why anyone would choose to code in VB over, say, C#.

However, I still see (what seems to be) the vast majority of commercial web apps from "MS shops" are built in VB. I could stand corrected on this, but VB still seems more popular than it deserves.

Can anyone help answer any (or all) of these questions:

  • Am I missing something with VB? Is it easier to learn, or "friendlier" than C#? Are there features I don't know about?
  • Why is VB/VB.net so frequently used today, especially in web projects?

migration rejected from stackoverflow.com Jul 18 '13 at 15:03

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as primarily opinion-based by gnat, GlenH7, Yusubov, Jalayn, Dan Pichelman Jul 18 '13 at 15:03

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

How do you know what commercial Microsoft web sites were built with? –  samjudson May 26 '09 at 8:58
"Why is VB/VB.net so frequently used today," This is a bit like asking "Why are mules/trucks so frequently used today in transportation?" –  Daniel Daranas May 26 '09 at 9:04
Just for posterity, I stand (sheepishly) corrected. VB has a community of very loyal users, which says an awful lot. –  aaaidan Sep 2 '09 at 3:34
this question should be deleted. –  AMissico Sep 14 '09 at 12:46
Do not delete this question. It’s bad and prejudiced and subjective but it quite often occurs and can serve as a reference. –  Konrad Rudolph May 25 '10 at 16:33

2 Answers 2

It all started before C# existed

Back in ~ 1999, we had Visual Studio 5/6. If you were a Independent Software Vendor or corporate using Windows and needed an application written which could, e.g. track employee's time spent on projects, you had a few options:

  1. Forms in Visual Basic.
  2. MFC, ATL or Win32 in Visual C++.
  3. Forms in Access 97/2000.
  4. ASP website.
  5. Java applet.

At the time, we were just before the Dot-Com bubble burst, so anybody who was any good with (4) or (5) went off to negotiate stock options at whatever amazing dot-com they were attracted to.

(3) had issues with locking and overall scalability, but I saw a lot of Access-driven solutions which would shell-out to run support functions as needed.

So that leaves us with VB and VC++:

The Forms editor in VB was, at the time, excellent for productivity. You could drag-drop your components - not just buttons, labels and text boxes but the full 'OLE controls' toolbox of reusable components like clever Grids, Excel sheets or IE instances. The wire-up was done behind the scenes - everything was object-like and you just double-clicked things to add event handlers. This was very much harder in Visual C++. As a member of the Visual Studio developer support team at the time, I can remember how Visual Basic support calls were mostly about which component was best to use or how to optimize their application in certain ways. It was almost never 'how do I make an application with X, Y and Z user interface features'.

Building a rich UI in Visual C++ was a different challenge. Although there was Visual editor support for dialogs and SDI/MDI forms, it was fairly limited. The support for embedding OLE Controls (ActiveX) into MFC or Win32 was a black art, although a bit easier in ATL. Wiring up simple things like resize events or owner-draw was pretty painful, let alone the Connection Points required for custom events in components.

Yes, VC++ had the execution speed, debug-ability and flexible frameworks/libraries/UI options, but the IDE support couldn't cover all that ground so addressed the most common operations with things like Wizards, comprehensive MFC class hierarchies and 90-days/2-free-incidents support lines.

IIRC, the application packager that shipped with VB could package up your app, the VB runtime and latest common controls DLLs and supply you a standalone EXE installer that you could put on a CD and get to customers. None of this 'which msvcrtXX.dll and mfcxx.dll do you have installed?', which plagued the MFC developers.

So, for reasons of time-to-market and rich user interface, VB got a very big following.

When Visual J++ and Visual Interdev hit in VS6, it was clear that the Visual Basic IDE had won some battle over the Visual C++ one, which was fair IMHO. It was no surprise at all that Visual Studio .NET had a VB-like forms editor for the new COOL C# language.

The new Java/C/C++-like language coupled with the UI designer enjoyed by VB people for all this time gave a new migration path for the C++ people who were now done with MFC/ATL/Win32. For the VB 3/4/5/6 people who didn't like the lack of 100% backward compatibility in VB.net, this offered an opportunity to learn a new language in a familiar environment.

The reasons that VB was such a comprehensive product likely has something to do with the origins of Microsoft, with Basic being their flagship developer product, but I don't have any citations at this time.


As of the 4.0 framework, there are only a small handful of things VB lacks compared to C#, and the reverse is true as well. Namely:

  1. The most notable is that VB.NET doesn't have the Yield keyword, but it is coming soon to VB.NET with the new async framework.
  2. There's no unsafe keyword. I've never found it necessary, but surely there are some people who have.
  3. There are no multi-line strings. Multi-line strings are accomplished by using + (or the legacy &) operators across lines. Or, they can be accomplished by using the XML literal syntax: Dim s = <s>My string... multiple lines...</s>.Value. It's not pretty, but if you're not picky and really want multi-line strings it works. And, you can do string interpolation with it using <%= myVar %> syntax which is nice.
  4. There is no variable scoped equivalent of dynamic. Dynamic variables have been around in VB for a long time with Option Compare Off, but that is file scoped, so it's not as good as dynamicbecause dynamic limits the scope to only the variable declared that way.
  5. VB lacks a terse lambda syntax. Lambdas are there, but you have to use Function(x) or Sub(x).

Some features VB.NET has that C# doesn't:

  1. XML literals, which are handy for all sorts of things, not just XML.
  2. Case-insensitivity in a language is the cat's meow. Not many other languages allow it, but what a difference it makes in the speed of coding to never have to hit the shift key when you're typing and have your code just auto-format the way you want it.
  3. The often unnecessary Select clause can be omitted from Linq queries.
  4. The Nothing keyword is much more useful than null in that everything (even value types) can be set to Nothing and you get the default. There's no need for the default keyword.
  5. VB.NET is constantly compiled in Visual Studio so you see errors right away. No hitting CTRL-SHIFT-B all day long like in C#.

My shop does MVC3 with Razor using VB.NET and once you get over the (mostly unfounded) prejudices, it's actually a very nice language to use. It's not really more verbose than C# as many claim (except in the case of lambdas), and it's pretty much feature-for-feature parallel with C#. I've found that most people who are haters have not really coded in modern VB.NET for any length of time.

As for me, VB.NET is too verbose. You have to manually print lots of boilerplate code, and ReSharper doesn't help, actually. I have been coding in C#/VB.NET in paraller for 3 years already. –  Hedin Aug 9 '13 at 10:16
VB is indeed horizontally verbose due to the longer keywords. Although you don't often type them, because the IDE puts them in for you. But IMHO C# is often vertically verbose due to the curly braces. Some other advantages of VB: avoid debating the brace style because there's only one style in VB; (tongue goes into cheek) avoid developing overmuscled right little finger due to endlessly typing semicolon and brace boilerplate. –  MarkJ Aug 9 '13 at 11:30
@MarkJ: I find it interesting the way C# proponents criticize AndAlso [not withstanding that when spoken it's shorter than "double-ampersand"] but ignore the fact that an If-Then/Else/EndIf takes three lines plus the controlled statements, while the C# equivalent would take at least four and possibly six, depending upon brace conventions, unless one writes } else { as a single line. –  supercat May 6 at 21:57

protected by Anna Lear Mar 26 '11 at 14:43

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?