The VB OSS debarkle

Following a discussion last night between myself, several others, and Roy Osherove, which Jeremy Miller also commented on.

The problem was incorrectly stated. There isn’t a lack of OSS projects that VB programmers can use, there’s a wealth of projects out there. I’ve personally used IoC containers, ORM tools, unit testing tools, and build automation tools in VB with my most recent employer. The issue is that more recent projects are using some language features of C# that the VB team hasn’t chose to implement. This has got Roy all up in arms because he feels that should be our problem (as the OSS developers).

On a side note, it was also mentioned that there are few VB OSS developers because they don’t have anything to cut their teeth on. Chicken and the egg, no VB OSS projects means no VB OSS developers.

The fact that there are plenty of OSS projects out there that VBers can use kinda makes the argument that VB developers don’t contribute to OSS because they don’t have anything to start with redundant; the whole chicken and the egg argument is flawed because OSS is already out there. It has been out there for years and yet there are still precious little contributions from VB developers.

I think it all stems from a funny situation we’ve got ourselves into, one of unfounded expectations. C# and VB have always been pretty much the same language, just with different syntax. Everything you could do in C# you could do in VB. That’s no longer the case from .Net 3.5 onwards; however, it was only ever the case by coincidence due to their base in the CLI. If the CLI was never involved, they’d never have travelled the same path. When you take a step back and look at them for what they are, two completely distinct languages, this expectation for crossover appears less reasonable. I wouldn’t expect a Ruby developer to complain that they can’t use my C# project, so why should a VBer complain? VB is just as different a language as Ruby is to C#.

• If you want a framework for Ruby, you’d pick a Ruby framework.
• If you want a framework for C#, you’d pick a C# framework.
• So why if you want a framework for VB, do you pick a C# framework?

Regarding the conversation…

To those VB developers who responded with conspiracy: there is no conspiracy. Nobody is developing with C# out of spite, we do it because it’s our preferred language; nobody would accuse you of being spiteful if you chose to develop in VB, so don’t accuse us of doing it.

To those VB developers that think we choose C# because it’s the “flavour of the week” versus the old workhorse of VB: that just shows how far behind you really are; if you genuinely believe the C# developers think it is en-vogue, then you’re sorely mistaken. I don’t think I know any C# developers that actually think C# is really awesome, just that it’s their preferred of the two .Net languages.

I can’t believe I fell for a C# vs. VB argument.