Geeks With Blogs
Bob Taco Industries Blogging Division

For anybody who might have missed the news, XNA is coming to Visual Basic. I’ll admit that my first reaction was to groan and grumble and mumble. But this is actually a very good thing. While nothing’s ever certain, the fact that Microsoft has spent time making Visual Basic a supported language in XNA Game Studio is a further sign of Microsoft’s long-term commitment to XNA. (Note that VB.NET with XNA is not an immediately available thing; it’s still a few months off as the original blog post notes). And, as others pointed out, XNA has its roots in Managed DirectX (MDX), which was originally a VB.NET effort. So it’s only right and proper that XNA + Visual Basic will finally be a supported scenario. And devs who spend their days toiling away writing LOB apps in VB.NET deserve the same opportunity to spend their nights and weekends making their dreams come alive that those of us who are fluent in C# already have; it’s all CIL in the end.

So I welcome my VB coding .NET brethren and sistren (which should be a word) to XNA and shall do my best to help them just as I’ve helped others with XNA + C#. Of course when I first read the news I knew next-to-nothing about Visual Basic. And that’s what this post is actually about.

For those of you, like me, who have never done much of anything with VB, there are quite a few resources to help you translate between C# and VB. A great starting point is the MSDN Language Equivalents pages.

If you are simply looking to see what C#’s != is in VB, you can go there, click on the “Operators Compared in Various Languages” link, and see that it’s <>.

Sometimes, though, certain things just don’t exist. For example, VB, not having a C origin, doesn’t contain a sizeof operator. Nor does it have any prefix or postfix increments/decrements.

It does have other things that C# does not have, of course. Static local variables, for instance, simply don’t exist in C#. And there are certain names of things in VB that, to me at least, make more sense than the C# equivalent. VB’s MustOverride vs. C#’s abstract is an example of that.

Something that’s likely to drive me a bit crazy is VB’s case insensitive variable names. The (to me) common C# pattern of “private int someValue; public int SomeValue { get { return someValue; } set { someValue = value; } }” for properties and explicit fields simply won’t work in VB. To the extent that they allow mixed-language assemblies (something we’ll find out about later), at least some C# code will be in for some refactoring in order to make things accessible in VB. That’s all for the future still.

In the end, the most important thing I think I have to do is to not treat VB like it’s C# with a funny syntax. While the Language Equivalents reference I linked to above has been (and will continue to be) very helpful for getting an initial idea about what a particular block of VB code does, VB is a different language, not just a different syntax. When I left programming a decade ago, I was still treating C++ as C with objects (and I had tried my best to avoid the “with objects” part since I found the syntax ugly and confusing, especially when coupled with Hungarian notation). When I came back in to programming again, I initially started working with C for hobbyist stuff. I then found XNA and made the effort to learn C#. Of course I tried to treat C# as C with objects and that led to some spectacularly bad code (god objects, rampant abuse of static to recreate globals, etc.). I did eventually learn to appreciate objects and have improved quite a bit since then (though I do still have a tendency towards god objects that I have to actively suppress at times). I think that a lot of that is due to my personal preference for C#’s object orientation syntax over C++’s.

My goal with VB is not to make the same kind of mistake that I did with C#, i.e. not try to treat it as being a bizarro version of a language I already know. To that end I already have one print VB book and will doubtless be getting one or two more. I also have bookmarked the Visual Basic Programming Guide and the Visual Basic Language Reference. I’m going to spend some time recreating (not simply rewriting) certain apps and utilities that I’ve made in C# in the past in VB. And also spend a lot of time reading and studying existing VB projects to figure out what they are doing and how they are doing it both to try to recognize common VB constructs and patterns and also to internalize the keywords and other language syntax elements until I feel fairly confident in being able to write out working, performant VB code without the aid of a compiler or even Intellisense (something I can do reasonably well with C#).

It’s a long road and I don’t know how far along it I’ll be when XNA + VB arrives, but it should be an interesting journey regardless. It’s kind of exciting to learn a new language and it’s nice to have an impetus to do so. It’s something else to add to my mental toolkit and it should help make me a better programmer overall. And it’ll be very exciting to engage with a whole new wave of programmers, to help them understand XNA and solve any problems they might have encounter, and to see all the games they create. It will be an even busier Spring than I had originally imagined, but it will be an exciting one too!

Posted on Thursday, March 31, 2011 5:55 PM xna , VB | Back to top

Comments on this post: Preparing Myself For XNA and VB

# re: Preparing Myself For XNA and VB
Requesting Gravatar...
Interesting article. Makes me want to take a serious stab at learning Visual Basic.

I just noticed today that you need Visual Studio Professional to deploy Visual Basic/Silverlight-based apps to WP7. I hope I'll be able to use the Express edition for future XNA/VB projects.
Left by Greg Leck on Mar 31, 2011 8:21 PM

Comments have been closed on this topic.
Copyright © Michael B. McLaughlin | Powered by: