Language Choice Will (or Won't) Matter

There's more to this article than technology and technique. Yes, C# developers can benefit from elements of the Visual Basic namespaces, but the underlying challenge is the way we look at languages in the first place. Several years into .NET, we know that the language is nearly irrelevant next to the .NET Framework—at least when it comes to C# and VB.NET. Yet articles, books, and conferences still differentiate between them, and developers still debate which to choose. It's a necessary decision, but it's also one based as often on emotion as on technology.

The next phase of the debate will begin soon, as Microsoft attempts to differentiate the languages for Visual Studio 2005. Some have started the discussion already; I heard one developer argue that VB.NET is a more RAD environment and should be used only for quick "throw-away" code. He reasoned that RAD implies coding without proper design. Such silliness aside, it really is too early to debate the VS 2005 versions of the languages, because we still don't know what they will look like. Technology previews are just that—previews—and those of us who have suffered through them in the past know that major features might yet appear or vanish before the product is released.

Language choice matters. Choosing the right tool for the job can make a huge difference in the success of a project—but only if the languages truly represent a difference in functionality or development paradigm. Right now, the true language difference between the Microsoft .NET languages lies between C++ and the others. At this time, no such difference exists between VB.NET and C#. And despite the increased differentiation that seems to be on the way for VS 2005, the development paradigm and overall functionality look as though they'll remain similar enough so that the nature of this language debate won't change to any great degree. But it's sure going to be fun revisiting this topic in a year or so.