Guest Opinion

VB Gets Productive

In an exclusive interview, Bill McCarthy, a frequent contributor and advisor to VSM and member of Microsoft's software design review team for VB, discusses the imminent release of Visual Studio 2005 with VSM's editor-in-chief, Patrick Meader. The theme of the day: productivity, productivity, and, well, more productivity.

• By Bill McCarthy
• 01/01/2006

Bill McCarthy, a frequent contributor and advisor to VSM and a member of Microsoft's software design review team for VB, discusses the imminent release of Visual Studio 2005 with VSM Editor in Chief Patrick Meader. The theme of the day: productivity, productivity, and well, more productivity.

PM: Jim Duffy wrote in a recent blog that "VB's mojo is back." Is this something you agree with?

BM: I'd have to say that's true. The more I use it, the more I notice the productivity improvements. VB 2005's productivity frees you up to think about the bigger picture, much as pre-.NET versions of VB did. You don't waste your time on the little things, but spend your time now solving the big things—which is exactly as it should be. My classes, code snippets, edit-and-continue—these are tremendous productivity features.

PM: You think My classes give VB an edge; does that mean you consider them viable for production in business-class apps?

BM: Definitely. The code in My classes has been thoroughly tested and designed from the ground up for the enterprise. I confess that I thought they were just another set of code libraries initially, but with use, they've won me over.

PM: It is still the case that new code examples appear first in C#, then VB, if they appear in the latter at all. For example, we saw this pattern again at Professional Developers Conference 2005 with the preview of some new technologies. Does Microsoft undercut VB with this approach, or do people like me make too big a deal out of this issue?

BM: This is not one of those cases that bothers me, personally. Production-ready code now comes out in VB and C# simultaneously. For example, look at the Enterprise Library and other examples like that. It is true that you see early prototype stuff done in C#. But if the code isn't in VB yet, then that tells me that the code is not ready for prime time and not ready for production. That tells me that C# is great for code you want to play with, and VB is great for code that you want to enter into production with. [laughs]

PM: You've mentioned a handful of features so far. Which is your favorite?

BM: The code snippet editor, of course, which has nothing to do with the fact that I wrote a good portion of the utility. I think the ease with which you create this kind of utility speaks volumes about the productivity enhancements in VS 2005. [You can download the utility at http://msdn.microsoft.com/vbasic/downloads/tools/snippeteditor.]

PM: What makes you cringe?

BM: Well, default instances do make me cringe a little. For example, the ability to write Form1.Show is potentially confusing and can lead to a lack of clarity in your code. Is "Form1" referring to the type or an instance? On the other hand, writing My.Forms.Form1.Show is extremely useful, so it's not default instancing per se, but using default instancing without My.Forms that I dislike.

This goes back to VB5 and VB6. It was always "dirty," in my opinion, but then you couldn't have shared (aka static) methods in your form, so it wasn't as important. My dislike of this approach is more of a code styling issue than anything else.

PM: Let's talk about generics. You were a big proponent of generics early on, and an even bigger proponent for generics in VB. What do generics bring to the table for developers?

BM: You'll think I'm getting carried away with a theme, but once again, it's all about productivity. This is a feature that can save you a ton of effort. For example, let's compare a List(Of Customers) with an ArrayList. In the case of an ArrayList, you're hosed from the start. Item is as Object, so there's just way too much room for mistakes. You end up having to write so much code to cast the object back to Customer, and then try to ensure only Customers get added to the list. The issues around this were significant enough that you would end up writing your own CustomerCollection in Visual Studio 2002 and 2003. So, you would implement IList, hide those methods, and then provide strongly typed methods. That's a lot of code, considering all you want is a list of strongly typed Customers.

With generics, you just use a List(Of Customers) and that's it. Everything is done for you, and it's strongly typed. Item is as Customer, and you will be warned if you try to add anything else other than Customer at design time. Another benefit: You don't have to cast anymore.