Why do DBAs prefer VB over C#?

The saga of VB vs C# continues even in the DBA community.

This morning I was having a talk with our lead web dev about the merits of C# over VB.  And yeah, I know it sounds like one of those tired old conversations that never goes anywhere, but this actually wasn't.  He's actually quite a bit more practical than most and he's very willing to admit that it boils down to preference and there's no real difference until you get into the real outer space type of stuff. 

There were a couple interesting things that shook out of this conversation however.  One was the practicality of whether to insist on everyone coding in a single language vs letting them code in whatever they want.  The other was why DBAs mostly prefer VB.  I'll cover them in order as briefly as I can.

His preference is to insist on C# (which is what lead to this whole thing to begin with).  When I asked him why his reason was simple and reasonable.  Because it's the language we've all agreed we're going to write in and we can easily develop standards with a single language and anyone can support the code.  If you bring another language into the mix then that guy may be the only one who speaks that so he's the only one who can support it.  And while I completely agree with him, it also goes against the whole tenet of .NET as a coding platform because the whole point is that your coders can code in whatever they like and just plug in the different classes to the projects and they'll just run like they're supposed to.  It's the IL that takes care of all that for you.  So finding C# or VB guys isn't a big deal because they're both plentiful in the marketplace so you should just allow your coders to do what they prefer.  And while that's a fine argument, he threw me a nice wrench... what if the guy wants to code in perl.net?  Or something-else.net?  How easy will it be to find that guy or port his code to another language if he leaves?  OK, point taken.  And there are a couple other factors.  If you allow multiple languages, you can always find the best coder instead of the best C# coder.  Your options open up when looking for talent.  The problem is of course to maintain code written by former devs can be hard.  If the guy who just left is a VB guy and the best guy for the job you just hired to take his place is a C# guy, then you're in trouble.  So I can really see his point, but I can also see both sides.  There are going to be management issues on both sides, but I think his argument is the stronger of the 2. 

But then we started talking about why DBAs all seem to prefer VB.  Are we all really that much dumber than "real" coders who do C#?  While that's entirely possible, it's really a sub-culture that's been bred by MS more than anything.  Let's look at how this happened.  The main scripting language for windows has always been vbscript.  So admins initially learned vbscript.  When DTS came around in SQL7, the best way to do out of the box stuff was in the scripting task, and it only spoke vbscript.  I've got a fuzzy memory that you could load other scripting languages on the box and use those somehow, but hardly anyone did it.  Then when SQL2K5 came out with SSIS, it had a new scripting task that used .NET, but guess what... that's right, it only spoke VB.  And of course then there's the expression language SSIS uses that is basically VBA.  So MS DBAs have been groomed for VB for years.  Now in SQL2K8 they've got the new scripting task that not only allows C#, it defaults to C#.  So I'm not sure if MS is trying to push us in that direction, or if the list is just alphabetical.  Either way, it's an option now and we just have to decide what to do with it.  I know for many DBAs there's just no reason to change.  It's all we've known for years and it's served us well and to date, nobody has really offered a solid reason to change... other than C# sounds cooler.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2010 IDG Communications, Inc.