Are VB.NET Developers Less Curious? Standardizing on VB.NET

Question

I'm asking this question as someone who works for a company with a 70% to 75% VB.NET developer community. I would say 80% of those developers do not know what an OOD pattern is. I'm wondering if this is the best thing for the health of my company's development efforts?

I'm looking at the tag counts on:
https://stackoverflow.com/tags
There are currently:
12175 .NET questions
18630 C# questions
2067 VB.NET questions

Checking Amazon, it seems like there are:
51 C# Wrox books
21 VB.NET Wrox books

On CodePlex there are:
979 Projects tagged C#
136 Projects tagged VB.NET

There is definitely less materials to learn from if you wanted to be a VB.NET developer. What would be a company's advantage to standardizing on VB.NET and hiring VB.NET developers? How does Microsoft answer this question?

Is the only two arguments:

1. We had these VB6 programmers and lets make them comfortable
2. XML Literals

If you work for a company that has completely standardized on VB.NET, can you post an answer explaining the pragmatic or technical reasons why they made that choice?

UPDATE:
More stats - O'Reilly Radar
State of the Computer Book Market 2008, part 4 -- The Languages

Answer 1

As a VB.NET developer, here's what I don't like about C#, granted my experience is from reading C#, not writing it so much:

1) No edit and continue. I've seen arguments that Edit and Continue is a bad thing and that it encourages bad coding habits. It reminds me of my project manager telling me 25 years ago that my love of my then-advanced debugger was a "crutch" and that it encouraged bad programming habits. Sorry, I didn't buy it then, I ain't buying it now. At the very least, the advantages outweigh the disadvantages 10:1. Once C# gets this feature, you'll appreciate it more and really appreciate it if you ever have to code without it again.

2) The language is case sensitive. IMHO, this is pure evil. Would people agree that it is bad to have two variables in the same scope that vary only by case? If so, why allow it? Yuck.

3) Background compilation and hence better design-time feedback of errors. A mixed blessing, as this slows down the IDE. But with 2008, performance is better and is probably a time saver. Course, this is not a factor of the language itself, just the dev environment.

4) Braces {}{}. Reminds me of my LISP days where you can tell a LISP programmer from other programmers: They're the ones with their fingers on the screens trying to match up parens.

I find the following VB code easier to read and less likely to contain errors.

If condition1 then
  truestatement1
  truestatement2
else
  falsestatement1
  falsetatement2
end if

If (condition1) then {
  truestatement1;
  truestatement2;
  } //if (cond)
else
  {
  falsestatement1;
  falsetatement2;
  } //else (Condition)

All those braces with lack of auto-indent are just begging for compile time or run-time errors. And as the nested ifs get complex, the braces just add to it. In place of the 4 braces in the C# example, the VB code has just one END IF statement, but C# programmers that comment like to add optional comments as to what block the brace is end bracket is terminating.

The VB code is self documenting with less typing--the IDE even adds the END IF for you when you type in the IF condition line. So, in the end, I am missing the brevity simplicity/benefit here that C#-aficionados claim. The } might be more terse than the End If, but I'm suggesting that the overall structure is unnecessarily complex.

Granted, this all isn't that big of a deal, but as a novice C# coder I feel like it is a lot easier to mess up the nested conditions than it is to use VB.

Answer 2

It sounds to me like the programming language isn't your company's main problem. If I worked in your company I would set the priority on bringing the 80% who don't know what an OOD pattern is up to snuff.

Good code is good code, whether it's written in C# or VB.NET.

Answer 3

There are lots of good answers here already, but my take on the original question is that what really needs to be answered is not why people stick with VB.NET, but rather what makes C#.NET the language of choice for .NET books, samples and toolsets?

I think there are three things operating here:

1. The first people into C#.NET were curious by nature - that's why they went for the new language rather than sticking with something interesting. So yes, it did get more curious people at first ;D

2. C#.NET was Microsoft's way of attracting Java programmers into the .NET world, and it worked pretty well. Many of the best ideas in .NET have been ported from Java, and hence get ported into C#.NET first. They only end up in VB.NET after they go mainstream. See this article for an example of how C#.NET was seen as a reaction to the failure of Microsoft to have their own Java version.

One reaction to it is telling:

"I'm not a MS programmer, but if I'm ever forced to move there from Java, I know I won't be totally lost and useless now that they have C#."

3. VB.NET programmers are as smart and curious as any other programmer, so when they see a C#.NET book that deals with a topic they find interesting they buy it and convert what they need to know to VB.NET - or even just implement it in a separate C#.NET DLL in their VB.NET projects.

Answer 4

Paul Vick, who was the language architect for VB.NET at the time, wrote this in 2008.

Our users [VB developers] run the gamut from people who are picking up a programming tool for the first time to industry veterans building large-scale commercial applications. The key to designing a framework that appeals to Visual Basic developers is to focus on allowing them to get the job done with the minimum of fuss and bother... A framework that uses the minimum number of concepts is a good idea [for VB.NET developers] not because VB developers can't handle concepts, but because having to stop and think about concepts extraneous to the task at hand interrupts workflow. The goal of a Visual Basic developer usually is not to learn some interesting or exciting new concept... but to get the job done and move on.

From the .NET Framework Design Guidelines 2nd Edition page 10.

Answer 5

To learn to be good VB.NET programmer you don't need to learn it from a VB.NET resource learning from C# resource is perfectly fine. If you can't even translate a C# code to VB.NET you got bigger problems anyway.

Almost all decent+ VB.NET programmers can read and decently write C# due to the things you just said, because otherwise you can't learn new stuff easily.

Finally, the people who are crap, are not crap because they are VB.NET programmers, that's just VB.NET is easy to code and it's not a bad thing! Also it's been said that most of these people coming from Classic ASP and VB6 background, which are again really low entrance threshold languages. After a week any decent computer user can code in those languages. But most of the C# developers coming from Java and C/C++ background. Especially Java side got lots OO in it. After all especially C is not easy to learn, most of the people either learned in the school or in a long course, or from bunch of books.

When it comes to a why company uses VB.NET it's mostly because of legacy reasons. Also some companies who jumped .NET 1.0 from VB6 thought that VB.NET will be the major language, which turned out to be a big mistake after couple of years.

Answer 6

This doesn't pertain to the question but to the comments being made to the questions

Reading this comments reminds me of back in the 70s and 80s when I read about people using any high level programming versus assembly. The assembly programmer had an 'elite' status compared to those who used high level languages like ... C!

And it was baloney then and it still baloney now that it is C# vs VB.NET.

Experienced programmers like using C# because it terse. There less damn typing involved. I rarely see new languages where they to try expand the amount of typing you have to do. C# is no exception.

But... there a problem with this. The problem of maintainability. The more terse a language is the harder it is to go back 5 years, 10 years later and read what you were doing. Which is why I use VB.NET in preference to C# or other C style language. And before you bust my chops about being a VB programmer I maintain software simulations of various historical spacecrafts in C++. I use both styles extensively.

Now it not a dramatic difference. But combine experienced programmers with the religious attachment many have to their favorite language it no wonder question like Tyndall comes up.

QuickBASC/PDS/Visual Basic family of languages continue to sell for Microsoft because they are not terse. Because they are more readable. While this feature doesn't appeal to many experienced programmers it does appeal to many starting out. Combined with the religious attachment many develop toward their tools they stick with it throughout their careers. Plus the Visual BASIC has a populist aura about it that is appealing to many.

Like most things with populist appeal is looked down on by the elites. Conversely it gives the language a lot of users. So it not likely that it will be axed by Microsoft any time soon.

Answer 7

I think you will find its not the language but the people that use it. Forcing these people to use C# wont solve the core problem.

However if you do program in C# chances are you are more likely to get a better class of programmer next time you hire if they have this as an existing skill. (This is not to say there are no good VB.net programmers, as i have known some great VB.Net programmers. Or even that all C# programmers are great.)

However in my experience the poorer skilled programmers tend to stick with VB and VB.Net and don't even want to look at C# or any other language outsite VB/VB.Net

Answer 8

I worked for a small company with an existing ASP/VB6 codebase, built by several different devs, each with their own "stamp" to put on it.

Like many, BASIC was my first language in the early 80's, but I "graduated" to assembly (6502 and x86), and have wandered through many languages to what I hope is strength in C/C++ (tho' I always have more to learn). I'm very much a "right tool for the job" kind of guy, so I even learned (and learned to hate) VB, from 3 up through 6 and VBScript.

I picked up C# fairly easily, and was slowly working on converting my ratty old codebase to C#, when the company was purchased. $corporate_owner has standardized on VB.Net. The things that drive me nuts about VB are some of the same things that others love, namely all the syntactic sugar (excess verbosity).

There's also the dislike of VB among "real" programmers that Jeff has written about before.

All in all, VB.net just isn't "cool". However, it does have many advantages (syntactic sugar, familiarity, ease of learning); I know of at least one college that has a VB.net course as part of their required CS and CIS curricula.

Anyway, because of its ease-of-use, and the relatively straightforward upgrade path, I don't see it going away any time soon. At least it's not as brain-damaged as it used to be.

Answer 9

I'm only now making the switch to .NET, after having maintained existing VB6 code for a number of years following the advent of .NET. I believe I'm justified in considering myself a VB6 expert. My current employer is standardized on VB.NET.

For a number of reasons I find that I have some slack time in which to learn the new language. I'm using an ASP.NET book that has all code in both, and while I'm typing in the VB I'm making a point of reading the C# as I go.. There are a few things I've seen that one language does "better" than the other (a subjective call...), going both directions.

My sense so far is that by the time I finish this process I'll be able to go back & forth with a reasonable degree of comfort. I'm certainly not incurious--if I were, would I be here are SO?

Answer 10

We're not standardized on VB.Net, and I often have to go back and forth between VB.Net adn C#. I'm unusual, in that I come from a C/C++ background, know C#, but actually prefer VB.Net (I severely dislike vb6/vbscript).

I say all this because it's important to remember the VB6 is NOT VB.Net. It's a whole new language and IMO does deserve to stand up next to C#. I really hated vb6, but I fell in love with VB.Net almost instantly. However, VB.Net did inherit some things from VB6, and not just a syntax style. I'm talking reputation, and that's not entirely deserved. But I'm also talking about the developer base that helped create that reputation. That seems to be part of what you're experiencing.

With that in mind, it looks like you're judging the language based primarily on popularity. Not that there's anything wrong with this. There's plenty to be said for the ability to more-easily find samples and community support. But let's at least call it what it is. And if that's your measure, there's certainly enough support out there for VB.Net to make it viable, and it's not hard to take advantage of the C# samples.

Also, we're still on .Net 2.0 where I work. For 2.0, I definitely prefer VB.Net. I like the syntax better and I like the way it does a few other things over C#. But I play around with Visual Studio 2008 at home. On 2008 I really prefer the C# lambda expression syntax.

Regarding your two arguments:

• For #1, that may not be such a good idea, though I suspect it's the primary reason for many shops.
• For #2, I've never used Xml literals. They looks nice, but just haven't been that practical.

---

Something I wanted to add: it seems like some of the recent C# features are actually intended to make C# work more like VB. Static classes fill the conceptual space of a vb module. The var keyword makes variable declaration look more VB's dim. The upcoming dynamic keyword will allow vb-style late binding. Even properties, which is something you could say was "added" to c# for 1.0, are something that vb has had since before .Net.

Answer 11

I'm sure there are a lot more VB.NET developers buying books to learn C# than vice versa. They know they'll get more respect (reasonably or not) if they switch.

Answer 12

The only argument I have to keep using VB.net is:

1. I hate case-sensitive languages (like C#)

It is dumb, the first thing after creating a case sensitive language is creating a best-practice "Do not use the same variable name with different case ever"

I know they want to copy Java case-sensitivity, but was really a dumb decision.

Answer 13

Yes, there are more C# books, and the C# community is more active, but at the same time both languages use the same framework, and have mostly the same features, which means a VB.NET programmer can pick up a C# book and understand it with no problem if he knows the C# syntax (which is close to many other languages' syntax).

At the end of the day there is no BIG advantage of choosing one language over the other. Because of the reasons you mentioned, I'd choose C# if your team had no preference, but if most came from a VB6 background, I'd see no problem choosing the VB language.

That's what happened in my organization. Most of our software was written in VB6 before so they decided to go with the syntax that the team was already familiar with, and I don't have a problem with that.

Answer 14

I'm currently working with a customer who is in the process of standardizing on VB.NET.
The main reason is, as you mentioned, the fact that the majority of the employees have 10+ years of experience with VB and COM.
They feel that going to VB.NET makes the most sense as a career path, even though they're well aware that very little of their existing knowledge base can be leveraged going forward.
Given this fact, they also considered moving to C#, which indeed seems to be the most used language on the .NET platform today. However, given the great amount of new knowledge they already have to learn in order to start using .NET, they preferred to go for a language with a familiar synthax.

In my opinion this proves exactly the purpose of VB.NET. That is to help bring the large base of VB developers in the world over to .NET, giving them the ability to use a language that "feels" familiar to them.
Also, the backwards compatibility layer built in VB.NET makes it possible to port existing (large) applications written in VB to new platform one piece at a time, while keeping them running.

Answer 15

Not looking for argument but as an old VB.NET fan:

3 . With statement, Handles statement, Module statement, XML literals, case-insensitivity...
4 . My namespace, Microsoft.VisualBasic namespace, all the "sugar-coating"
5 . Late-binding support and COM components interoperability
6 . Ermmmm..... (finger-crossed) readability?

As said, I'm not trying to be argumentative and I'm a big fan of C# but just that there is more to having VB6 programmers in a company to standardize on VB.

For example, COM interoperability could easily be a "show stopper" if you standardize in C# and your business depends on a lot of COM components...

And the sugar-coating support mentioned is rather huge (I miss them all the time writing C# code). I feels like there are more tooling support from the VB.NET team than the C# team while the C# team focus their efforts on more language features.

Answer 16

At my workplace, VB.NET was the standard up until recently as several of the previous developers came from a classic ASP background and were familiar with VB syntax. As our development team has matured, and we've adopted more sophisticated design methodologies (DDD, good OOD), there has been a natural shift towards using C#.

In most instances I would guess that shops using VB.Net is a pragmatic choice, rather than a technical one. That being said, VB.Net really is a much more capable language than it's predecessors - it just lacks some of the elegance of C#, and as you've discovered there's much more material related to development in C# on the web.

Answer 17

I think its more to do with the potential target audiences that VB.NET and C# would have appealed to when they started out.

Under the hood, its all the same (well mostly) but .NET Winforms/Websites etc... what you can do in VB.NET you can do in C# and vice-versa. So the question isn't really relevant in terms of functionality

Completely subjective opinion, but I'd say anyone who jumped on the VB.NET Bandwagon would have come from a background in VB6/Classic ASP. However the ability to jump on the C# bandwagon extends to people with Java/C++/Other OO Backgrounds.

So from the outset, you have a larger community of people taking up C#, it makes sense that there are more educators/contributors/Open Source projects under that language

Answer 18

Re point 1:

Well, my shop was a VB6 house - with lots of VB6 code to support, and we moved straight to C# with no problems. We did have to think about the decision, but I am 100% (or more) confident that we made the right choice.

Re point 2:

You'd be amazed at how much I don't need this day to day ;-p

I have nothing against VB.NET - I simply feel that C# allows me to do my job more elegantly.

Re the books etc - I wonder if there isn't a contingent of ex-VB6 developers who are still writing VB6 in VS2008. Making the switch to C# really helped me appreciate the new (at the time) .NET architecture. If I had moved to VB.NET I don't think I would have made that mental leap - at least for some time.

Answer 19

I'm sure most of the time the reason companies go forward with VB.NET is exactly as you mentioned - large amounts of VB6 in the organization, both in terms of codebase and developers. Keep in mind that ASP websites and VB6 applications can be migrated to VB.NET with little to no pain. VB6 to C# is a different story.

That being said, having worked at companies that have used VB.NET, there's really very little difference in how you do things and developers who are curious get used to reading examples, books, etc. in C#. It's not like it's terrifically hard to translate C# code to VB.NET, especially if you're not copy-pasting.