In-Depth
Putting Productivity Back in VB
Go behind Visual Basic 2005's productivity enhancements such as generics, data binding, My Classes, edit-and-continue, and more.
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.
PM: Jim Duffy wrote in a recent blog that VB has "its mojo back." Is this something you agree with?
McCarthy: 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: All but one of the features you mentioned—My Classes—are part of C#, as well. Would it be fair to say that C# has VB's mojo back too?
McCarthy: C# is certainly following VB's lead here. VB invested heavily in snippets and edit-and-continue early on, but the C# team recognized the value of these features and added them too. So sure, VS 2005 heralds great productivity for both languages, and C# gets a little bit of the feel of VB, in a good way. That said, the My Classes and Application framework that only VB has are significant.
PM: You think My Classes give VB an edge; does that mean you consider them viable for production in business-class apps?
McCarthy: 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 they've won me over.
PM: In what way?
McCarthy: Assume I'm working with files on a computer, and I want to write out a string to a file. Before VS 2005, I had to think about opening a file stream of some sort—a text stream, for example—then think about writing the data, closing the stream, and so on. My Classes enable me to do all of this with the My.Computer.FileSystem.WriteAllText call. VB 2005's IntelliSense assists with this, as well. Together, My Classes and IntelliSense enable me to concentrate on the big picture instead of waste time with the stream details.
My favorite example is copying or moving files. In VB6, we used to do some Win32 API and use SHFileCopy to get the pretty Windows UI stuff, such as the dialog that prompts a user if he wants to overwrite a file. In .NET, we had to use PInvoke to accomplish the same task. So in both cases we were writing a lot of code for a simple Windows-standard operation. In VB 2005, all you need to do is use a simple My.Computer.FileSystem.CopyFile(...) call.
PM: What's your favorite new feature in VS 2005?
McCarthy: The code snippet editor, of course, which has nothing to do with the fact that I wrote a good portion of the utility. With it, you can easily create and edit your own code snippets. (You can download the utility from MSDN, or visit the GotDotNet workspace to download the source code.)
Least Favorite VS Feature?
PM: What makes you cringe?
McCarthy: 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: Here's a question I asked Soma in a recent interview. In VS, you commonly program against ASP.NET, SQL, WSE, ADO.NET—pick your acronyms. How much does language really matter in VS?
McCarthy: In the smart-client space, I think there is a distinct advantage to using VB with smart clients. In other cases, including ASP.NET, ADO.NET, and others, I think VB and C# are on par with each other. I believe you might see that VB will also offer greater productivity in Orcas when using LINQ. At this time, it appears that support for LINQ in VB will go one step further than what C# is planning, especially with XLINQ. If you are working with XML, VB will be the language of choice because of its intrinsic support for dynamic interfaces, dynamic identifiers, XML literals, and so on.
PM: Let's concentrate on smart clients for a second. At first glance, this appears to be a fancy marketing term for what were previously called desktop apps. What makes them more than that, excluding the case where you are running them on a mobile or nontraditional client?
McCarthy: The space between desktop and Web apps is blurring, slowly but surely. It will get even more blurry with Avalon. As the terminology indicates, the "smarts" for smart clients typically occur at the client level. As popular as the Web is, as popular as Web-based applications are, and for as much as people try to reinvent the Web with technologies such as Asynchronous JavaScript (AJAX stuff)—a rich client experience is still... well, richer.
For example, how many apps on your machine run over the Web?
PM: I use Outlook Web Access on a regular basis, but that's probably it for me.
McCarthy: Exactly. We've had HTML and Jscript for more than 10 years now, but the drawback with these technologies is their latency. Web-based clients will never be as rich as clients that run locally. Users prefer desktop apps for good reasons.
The Smart Language for Smart Clients
PM: Earlier, you mentioned that you think VB is a natural choice for smart-client development. Given how similar C# and VB are, what makes VB a better choice for that kind of development?
McCarthy: It's all about productivity. VB has My Classes, as well as the My Application framework. So, let's say I start a new app in VB. From the properties dialog, I can set the splash screen, I can handle application events, and I can set the application instancing and lifetime. I can't do any of that in C#. Instead I have to waste time re-inventing the wheel when creating these parts of an application.
Now assume I want to associate a file type with my application in VB, so that the app opens when the user double-clicks on this file type. Let's also assume I want the app to be run as a single instance, so it's a document inside the app. This is extremely simple to do in VB. Simply set the application to single instance, and then read the arguments for the second instance opening event: the StartupNextInstance event. Why would I want to waste my time creating mutexes, opening a local channel to listen for the arguments I need to get, and so on? VB lets me focus on the big picture. Hmm ... you can almost sense a theme here.
PM: It is still the case that new code examples appear first in C#, then VB, if they appear at all in the latter. For example, we saw this pattern again at PDC, 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?
McCarthy: 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 the code is still in its early state—not ready for prime time, and certainly not ready for production. Indeed, what it really tells me is that C# is great for code you want to play with, and that VB is great for code you want to enter into production [laughs].
PM: You seem quite pleased with the progress Microsoft has made with VB 2005. What does Microsoft need to do to take VB to the next level?
McCarthy: I think Microsoft is actually on track with VB 2005. They are seeking out the right balance between power and productivity, and generally getting it right. For example, I often argue with the VB team for "power" features in VB. I hate to admit it, but, I've been wrong—on rare occasions, of course—when insisting on some types of power features. What's most important here is striking a balance and introducing power features when they make sense and when the end result is that they make you more productive.
Take anonymous methods, for example. They are a cool power feature, but they also have many issues. I squirm over half the time I see a demo with them because what's being demonstrated is exactly how not use them, in my opinion. Delegates with state are not things you should just leave floating around without reason. For VB, I think it makes more sense to introduce this kind of functionality through lambda expressions alongside LINQ for their context. Sure, some people will abuse them, but this approach gives you that functionality with a clear purpose for where to use them. This kind of approach, where you create the functionality with a specific, productive purpose in mind, is preferable to a cool but powerful feature that isn't intended to solve a specific problem. So, again, it all comes back to balance.
Advantages of Generics
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?
McCarthy: 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.
PM: Generics weren't originally intended for VB 2005. Why do you think it was a matter for debate when you and others pushed for the inclusion of generics in VB?
McCarthy: I think that is overstating things. Sure, there were some folks in the community who didn't see the productivity bonuses of generics early on. It was one of those "out there" things for them. But I think the Microsoft goal was to have generics in VB from early on in the process. So, sure, some people were unsure about it initially, but I think they are all on board the generics bandwagon at this point. There was also a question as to whether you needed to be able to define generics, in addition to consuming them. The vast majority of the time, you only need to consume them. At the same time, defining them kind of comes with the package when you're enabled to consume them.
PM: What issues or potential drawbacks do developers need to keep in mind when using generics?
McCarthy: Variance can make them problematic to work with. For example, assume you get passed a generic List(Of Customers) as Object. It's awkward to determine if that is a List(Of Persons), assuming Customer derives from Person. But you can work around this issue in many ways. The basic rule is this: If you're working with a specific type, stay specific rather than going to Object and trying to come back again.
How ASP.NET Has Changed
PM: ASP.NET was considered by many to be the home-run technology in VS 2002. But it underwent a major upgrade in 2005. How has it changed, and what parts of this change are significant to developers?
McCarthy: Microsoft has significantly improved ASP.NET's performance and productivity. For example, data binding in ASP.NET 2.0 is much simpler. You can now write apps with literally a fraction of the code that these same apps required in VS 2002 and VS 2003. Also, Web Parts bring the concept of reusable parts to the forefront when creating ASP.NET applications.
PM: ASP.NET significantly reduces the code you have to write. But how well does this code scale?
McCarthy: I haven't pressure-tested the databinding features in ASP.NET 2.0 yet. I'd expect there to be some potential issues, but the truth is that early reports I've gotten from other people indicate otherwise. So I can't guarantee its scalability, but I'm optimistic.
PM: Let's take a look ahead at Windows Vista and beyond. Tell me why developers will be interested in Microsoft's Windows Presentation Foundation (WPF), formerly known as Avalon.
McCarthy: I'm both excited and nervous about WPF. I'm excited because WPF serves up some cool features: incredible graphics, great layout capabilities, and document-centric capabilities. Plus, WPF has the ability to be distributed over the wire like an HTML page, yet run on the client as a rich application. In other words, you get to pick and choose the best parts of client/server. The limitation here is that the client must be running Windows. So that solution is good for only 90 percent or so of the world's computers. For most of us, that's good enough.
But I'm also a bit nervous. I worry whether Microsoft will encapsulate the functionality well enough early on. Over time, I'm sure it will, but I'm concerned about the initial implementation. One other nice thing is the model Microsoft is working on where a graphic designer can work on the UI, while the developer works with the code. This could lead to significantly better interfaces for end users.
PM: It's hard for me to imagine that businesses will invest in a graphic designer for inward-facing applications—that is, applications that customers or the public never touch. It doesn't fit the way I perceive your typical business working.
McCarthy: Well, the science of visualization—which encompasses both how you present your app and how you manage the processes behind what it displays—is still in its infancy. One of the things about this model to keep in mind is that it doesn't require you to use a graphic designer; it merely makes it much easier for you to do so. In that sense, apps that don't require a graphic designer needn't use one. At the same time, that's only one part of what WPF makes possible. A nice UI makes people happier to use your software, which can translate to better productivity.
UI design is not just about pretty painting. It's about what parts of the screen get your attention. It's about balancing workflow and white space, and it's a complex science to create effective UIs. And it is in these things that I think developers will really appreciate WPF.
PM: What, specifically, appeals to you about WPF?
McCarthy: I personally like its declarative-style programming. This is something Microsoft took from the HTML world. Of course, you don't have to use this model—you can still do everything in code—but I like the productivity enhancements that can result from this model of programming.
Let's assume I want to write a rich client customer management app. I want to provide a rich editing experience and great visualization. You might imagine I would do this by creating a fancy 3D-style rolodex interface. And you could, but assume I just want to implement a plain-view, v-cards–style solution: a simple list of v-cards that you can scroll through and edit. In WinForms, implementing this app requires writing a lot of low-level GDI+ stuff, and then trying to superimpose editing controls when the user clicks on a v-card. This approach suffers from a certain kludginess. The alternative is to write a user control and repeat that control, but you run into resource issues quickly if you have thousands of customers. It requires too many windows to take that approach.
WPF doesn't have windows as such—only one. It's all rendered, which means you write a user control-type approach, and simply repeat that, without the overhead of all those windows. With this approach, you get a more responsive and cleaner-looking interface, and you don't have to mess with low-level GDI calls or worry about resource issues. Plus, you can design all this graphically, and it's easier to code. So, getting back to the theme du jour: WPF is all about productivity, if you're a developer. WPF lets you focus on the task, not some low-level GDI calls or concerns about how many window handles you're allocating. And, of course, once you have your v-card control, you can then hand that over to the graphic designer, who might even put that in a rolodex kind of view.
WCF: Best of Both Worlds
PM: We've touched on WPF; now let's look at the other Windows Vista technology that has received its fair share of ink: Windows Communication Foundation (WCF), formerly known as Indigo. Tell me what's significant about WCF.
McCarthy: WCF combines the best of Web services and remoting. I view it as Web services finally coming of age—in concept, WCF isn't drastically different from the model Microsoft has for Web services. One of the most significant aspects of WCF is the performance gains you can attain from using it. This reduces the need for using remoting in your applications. It's also a one-stop solution. It ties together Microsoft's alphabet-soup of technologies required for implementing SOA or Web service-based applications. As with other technologies in VS 2005 and Windows Vista, you don't have to focus on the underlying bits, but can instead focus on implementing the functionality that comprises the most valuable part of your application.
For example, you don't need to consider whether it would make sense to design your app for Web services or remoting; instead, you can focus on how to get the required data over the wire. You do that using the best contract available to you, and all the contracts you need are consolidated in WCF; you never need to step outside WCF, as you would if you were implementing various solutions using VS 2005.
PM: You seem quite pleased with where VB 2005 is and where it's going, but that's not the case for everyone. Is this version of VB one that will win over some of the remaining skeptics who have refused to move on from VB6?
McCarthy: Yes and no. One significant issue that VS 2005 doesn't address for those who still use VB5/6 is code migration. Apart from that, I find .NET 2.0 incredibly compelling, especially the features around generics. Then again, I found earlier versions of .NET compelling for different reasons, which ranged from the framework to implementation inheritance. The people who refuse to upgrade to .NET over migration issues? I'm not sure they ever will, if they haven't already. There have been minor improvements in how well VB6 code ports to .NET, but nothing huge. If code portability and migration were issues to you before Visual Studio 2005, they remain issues to you after the release of VS 2005.
But there are good signs, too. Back in 2002, the year .NET was originally released, Microsoft opted for power over productivity. Of course, the tool is still much more productive, as well as much easier to use. Better still, the power-to-productivity ratio is much more in sync with what it should be for VB.
PM: Are these great new features for the already converted, or do you think they might attract some older programmers who have held off adopting .NET thus far?
McCarthy: I see these as features that will appeal to the converted. For those still in VB6 land, the real deal will be the next version. I think LINQ is particularly compelling.
PM: I'm curious why you think that. If, as you say, VB has its mojo back and we can assume that the code won't get any easier to port in the next version of VS, what could the next version to do to attract this developer that VS 2005 doesn't?
McCarthy: Well, the more compelling the features, the more compelling the reasons for adoption become. VS 2005 makes some large strides, but I think the next version makes even larger strides. The productivity advantages of Orcas VB will add significantly to the productivity advantages of VS 2005—and those are extremely good, now. The next version ships with WPF and WCF in the box, as well as LINQ. Now, that's exciting!
That doesn't take anything away from VS 2005. Generics are huge, data binding is huge, the productivity enhancements of My Classes and edit-and-continue are huge. The application framework, strongly typed resources, and strongly typed settings are also incredibly cool. And they are extensible, as well.
So we get a lot of cool things with VB 2005, and the Orcas release adds to that. At some point, you're going to be left so far behind it will feel like working in DOS if you don't move on. I think Orcas will be a pivotal release in that sense.