October 27, 2007

XNA and VB, One Year Later

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#.


Sarkie said...

"related" You know of any good DirectX C# Books mate? Hopefully with game examples in it.


Anonymous said...

I don't think the communication has been bad - they have always told me from day one that its simply becuase they do not have time to test the add-ins/templates and starter kits for more than one language - its simply a feature vs time issue for them. They would like to include this but choosing that option would remove features from the API.

From what I can make out writing the sort of add-ins they are using is stretching the VS add-in model (or maybe that teams knowledge of it a year ago - they seem to be much more on top of it now).

The 'My' issues and VisualBasic namespace issues are valid issues which the compiler would have happily caught and while the advance VB programmers would understand and move on a lot of the VB audience would blame XNA for just ot compiling.

The quote form Chris/BlogusMaximus where someone told them that 'XNA was too complicated for VB programmers' was NOT from someone on the XNA team. I've never heard an XNA team member say that.