Language of Choice

Visual Basic used to be the red-headed stepchild of the Microsoft world. It was the language we all loved to hate. It had enough bondage and discipline (you can't put parenthesis on a Sub invocation unless you put the Call keyword in front of it...WTF?) in the days of VB6 and lacked enough performance and advanced features that it basically wore a sandwich board with a target painted on it.

Then along came the CLR, and the .Net label was affixed to VB. Gone were the B&D features (Get/Set/Let for properties? WTF?). Gone was the mediocre performance. Gone was the love. Even though VB 7 became what Borland wished Delphi could have been, an easy-to-read language that eschewed some of the more...dangerous features of the C-derived languages whilst giving the developer enough room to be creative, and enough performance to avoid new hardware purchases, many developers think the language is total, utter crap.

The sad fact of the matter is, LoC is many times an emotional decision. Developers love to hate VB (or Java for that matter) because of its un-hipness. They hate being mocked because language X doesn't have wicked cool feature Y.

For example:

Dev A: You use What? It has no clojures. It sucks.
Dev B: WTF? I don't know what a clojure is, and I probably don't need it.
Dev A: [Emits toxic levels of Smug]

This doesn't excuse you from knowing which languages are capable of what features. You never know what feature you could use to save your company cash and make you look like a wizard.

For example, see C# run straight into a brick wall with this bit of love:

...

object listOfCritters;
if(gimmieHTML)
{
listOfCritters = GetArrayOfLions();
}
else
{
listOfCritters = GetArrayOfMonkies();
}

foreach(var animal in listOfCritters)
{
if(animal.TypeName = "Monkey")
animal.FlingPoo();
else
animal.PreyUponGazelle();
}

...

Obviously, this won't work in C#. The compiler will verbally abuse you for trying to make some undefined, random call on some untyped, random, unknown object. This never really made much sense to me, because the runtime engine will know what type it is, and if you write good unit tests, you'll know well before deployment if you're code is bonkers or not, but it is what it is.

Next, in VB:

...
Dim listOfCritters
If gimmieHTML Then
listOfCritters = GetArrayOfLions()
Else
listOfCritters = GetArrayOfMonkies()
End If

For Each animal in listOfCritters
If animal.TypeName = "Monkey"
animal.FlingPoo()
Else
animal.PreyUponGazelle()
Next

...

This is contrived, of course. For a realistic example, in SMO, the authors attached the Name property to table objects, stored procedure objects, view objects, etc, at the final object level. If you get a list of "Database objects"(I don't remember what their base class really is), with tables and sproc's and what-have-you all mixed in together, there is no interface to fall back to to make accessing the Name property generic.

Point being, know which languages have which features. Don't be afraid to learn all 3 of the .Net biggies (VB, C#, C++/CLI). With the economy getting soft and flabby around the middle, it may make the difference between you paying the rent and paying the unemployment office a visit.