This sounds like I’m trying to start a food-fight. In fact, courtesy of Steve, Development Manager here at [Intilecta], I thought I’d share an interesting article that talks about the Language V’s Tool divide (Full article available here). Just as an aside, the author of this article seems to be involved with the OpenLaszlo project which strikes me as “just another web technology” (it might ease the pain of doing web development but it won’t make it go away….)
Ok, so back onto the topic of this post – the article points out that if you have $100 to spend on improving a language you have to choose between spending money on improving the language itself (thus increasing the power and efficiency with which developers can write code) or tool support (which can also improve the efficiency of the developer). Try as you might you are not a magician and you can’t make $100 into $200 and thus be able to do both.
Now apply this logic to the C# v’s VB.NET debate and the decisions the teams make about priorities. Clearly with C#’s background in C, C++, Java and other languages there has always been a strong focus here on extending the language. That said, with [VS2005] C# made considerable improvements around intellisense and refactoring.
On the converse VB.NET has always been the leader when it comes to tool support for the language. Whilst the language did get most of the features of C# (such as generics, nullable types etc) there were a few things which were left out -> iterators and anonymous methods to name just two. So where did the VB.NET team spend their $100 – the My Namespace? Agreed My does provide significant savings when it comes to doing common task but I must admit I was sorely disappointed that the VB.NET team decided not to give us feature parity w.r.t. the language. Further more our complaints seem to be going unnoticed with iterators and anonymous methods still missing the cut for the Orcas release.
The argument keeps coming out from Microsoft that they need to differentiate the two languages to justify the cost of maintaining two languages, compilers etc. Quite frankly I think this is a silly response and that if this is their primary concern, then they should just get on with it and axe one of the languages. This would not only free up resources to be more innovative it would also stop this continual need for developers wasting valuable resources deciding which language to code in (after all if we only had feature parity there would be no discussion….)