Over the last while, I've ranted and raved about Microsoft's XNA Game Studio Express Edition not supporting Visual Basic .NET.
Now that the ZMan is updating again, I've noticed a new post about some really poor communication skills from the XNA team about VB.NET support. He links to a great XNA/VB rant from a Microsoft MVP about it.
Now, awhile back one of the Microsoft guys said that the reason VB wasn't supported on the Xbox 360 was because VB used some features of the CLR that their version of the Compact Framework didn't support. I think I finally figured out what it was, and if it's the case, we have only our older VB6 brethren to blame.
The XNA team could have easily said that you couldn't use "My" on the 360, even though it's supported in the full .NET Compact Framework. They could have easily said that the Microsoft.VisualBasic namespace couldn't be used on the 360, and we would have adapted, even though it is also supported in the full .NET Compact Framework. But remember back in 2001 when the value of True was a big deal? It does make me wonder what other "hacks" were put into the full CLR to support the older VB6 way of doing things.
I love VB.NET with a passion, but over the last couple of years I have started to lose my faith in VB's future. When you look at many of the new features that are coming into the .NET Framework, the syntax that is being used to bring these features into VB is becoming more and more tortured, and some language constructs now go against best practices. (Using "Handles" with WPF applications means that you aren't using the WeakEvent pattern, for example.)
So as a result, we're going to have to move back to the realm of VB hacking to get things done...even though we no longer have that VB hacker icon to follow. If you want to use XNA and VB, you can check out Alan Phipp's page for now, but if we want full access to the managed world, we're going to have to tell Microsoft two things. One, it's okay to let the VB6 way of doing things die, and two, .NET-capable technologies that Microsoft releases must support all languages that are supported by Visual Studio out of the box.
Teams like the XNA team and the Windows Home Server team may only have the funding to support one language, but if something like that is detected inside Microsoft, the platform evangelism teams should step up to the plate with either funding or staff to help them support the other languages. After all, language diversity doesn't mean anything if Microsoft is only going to be giving us items we can use with C#.