In-Depth
VB.NET Branches Out
Chris Dias, group program manager for Visual Basic .NET at Microsoft, talks about the present and future of the language, including the target audience of this tool.
Chris Dias, group program manager for Visual Basic .NET at Microsoft, talked at length to VSM Editor in Chief Patrick Meader about the present and future of Visual Basic .NET, including its target audience and Microsoft's larger goals when creating the tool. This is the expanded version of the interview that ran in Visual Studio Magazine's January 2004 issue.
PM: The VB development team serves a lot of masters. Can you describe, in a nutshell, whom this tool is for?
CD: We have a wide audience that we need to provide services for, but these users do have one important characteristic in common: They are looking for the best combination of productivity and power.
We spend a lot of time reviewing how VB developers work, and we try to provide tools that suit how different types of VB developers use their tools. It's critical that we make things easier for developers, but it's just as critical that we provide the features and capabilities for high-end VB developers. This is why we provide features such as generics, operator overloading, and so on. It's my opinion that all these features will eventually be applicable to everyone who uses the product.
For example, take a look at the My.Classes we've added to the framework, which enable you to speed-dial into aspects of the framework. These classes also come with hooks back out to the framework, where appropriate. We have some simplified file access stuff in there, but the Stream object is right there, hanging off the top-level file I/O class. So you can do the 80 to 90 percent of the stuff you need to do right there with two to three lines of code. But if you are the bleeding edge power-user, you can jump off right there using the Stream object.
PM: Reviewing some of the features for version 1 of VS.NET—inheritance, support for multiple threading models, direct access to the underlying framework—it appears a lot of time and effort went into disproving that VB was a toy language. How much was the desire to create a "real" development tool a factor for you when designing and building the first implementation of VS.NET?
CD: The reason we made many of the decisions we made was so we could make VB a first-class member of the platform. In order to play in that space, we needed to add all those things you mentioned. We got a lot of those power features because we implemented the .NET Framework.
So, it isn't that we set out by saying that we were going to create a really powerful object-oriented tool that is going to satisfy x or y group of people who have been demanding x and y features. What we said was, "We want to be a first-class tool on the .NET platform," and those features came along with that. But we also know that what we didn't get in version 1 of the product were features like edit-and-continue.
PM: Given that features like edit-and-continue didn't make it in, do you feel that any of the emphasis on your initial version of VB.NET was misplaced?
CD: No. It's easy to second-guess things in hindsight or even as you're going along: "Are we doing the right thing? Should we do this? Should we do that?"
But when I review the decisions we've made to move the tool to .NET, I still think it was the right move to cut edit-and-continue from the first release, given that the primary goal was to ensure we got on the platform. Because going forward, the developers who use this tool will reap tremendous benefits from being on the .NET Framework. All the stuff that comes from being on Longhorn, all the managed code, we're there, and we don't have to wait for anything.
Today, we have full access to the platform, and the bleeding edge, hard-core developers can now write XAML, Avalon, and Longhorn apps with VB Whidbey's managed code. Now, we can go back and figure out what we can do to make this tool easier and more productive to use for everybody, which is a nice place for us to be.
PM: I don't think VB developers missed edit-and-continue so much as the idea of what edit-and-continue meant. It just became the stand-in feature for the types of things that developers missed, for the kinds of productivity features that developers had hoped to see in the initial version of VS.NET. Do you think the developers missed the idea of the feature? Or was it really about not having edit-and-continue, after all?
CD: I think edit-and-continue was so important because of the iterative way that VB developers like to work. So, we're bringing it back for productivity reasons. But Whidbey is not about going back to the features of VB6 we wanted and didn't get, and making sure they get into the tool. What we're really trying to do is to push the tool to the next level of productivity, and edit-and-continue is merely one part of that.
Edit-and-continue is certainly a checkmark for us. It's great that it's there. But it's a starting point, not the end point of where we want the tool to be. The question for us is: What are the things we have to do to make developers even more productive with VB?
PM: And what are some of those things?
CD: I think AutoCorrect is going to be huge. I think compiler warnings where we can tell you where dead code is or where things aren't going to be initialized will be well received. Code snippets are a huge productivity feature. It might take 30 lines of code to do something, but all you have to do is tab in and fill in the blanks.
PM: Describe that feature, please, for those who haven't seen or heard about it.
CD: We came up with the idea from our internal review forums. Every review, you have to enter the person's name, manager, employee ID, and so on, and the review form walks you through that simply by tabbing to each new field that requires you to insert data. So we were sitting around, discussing the form, and someone said, "Wouldn't it be great if this were code, and I could fill in the blanks just by hitting the Tab key?"
So assume you have 30 lines of code, where three to four things need to be modified. If you could identify those three to four things, you could do a lot of interesting things with that code block. Because we have background compilation, we always know where you are in the project. So if you have something that requires a textbox, we can give you a dropdown list of all the textboxes that are in scope inside your form when you get to that field. We can also give you an option to create a new one, if that is what you need. Or, if you are doing something like a file path, we can give you pickers to go grab that file. We can add rich tooltips to tell you what's going on inside the text that you can edit. It's re-entrant to a point. We've had a lot of internal discussions as to how re-entrant it should be. Right now, it's re-entrant until you close the file and save it. So, I can go and put these in, and the IDE will remember which code sections are snippets and will rehighlight the appropriate text if I re-enter the code block.
PM: And this feature is extensible, correct?
CD: Correct. We're actually hoping there will be an interesting and vibrant community built around these snippets. The easiest way to create code snippets is to create a few lines of code yourself, highlight the text, then right-click and choose Create Snippet. This will bring up a dialog that walks you through replaceable fields, asking you to verify the type and so on. This will save the code as an XML file that you can plug into your projects in the future. We've also made it simple to create and share these files. It's nothing more than a text file in a directory on your disk. You can also distinguish between the code snippets provided by Visual Studio and those created by your company. We're hoping that there will be sites of great snippet repositories for people to try out and use.
We're also going back and snippetizing the help, where it makes sense, and we're doing the same thing for new examples. If the example has only two lines of code, it doesn't make sense to snippetize that. But if it is 30 lines of code with three to four things to change, that is a great candidate to snippetize.
PM: Part of the promise of VB.NET was to make Web services simple. Point and click and build. Indigo appears to make them complex again. Is this driven by criticisms that Web services are lacking in security, transaction processing, and reliability?
CD: The Indigo team is building the right Web services infrastructure for the platform. It is powerful and flexible as it should be, and at the same time, those guys are thinking hard about making it easy to use. From the VB team's perspective, we're going to look at what Indigo provides and build an incredibly easy experience on top of what they deliver. The specifics of this are not worked out yet. The team is heads down on Whidbey and will in the near future be looking at Indigo and Longhorn.
I'd like to note, though, that we spend a good deal of time talking about issues like this from the perspective of framework and runtime features. The edit-and-continue feature provides a good level of insight as to how this will probably work. The people who are doing the most work on edit-and-continue are the runtime guys. The C# guys are doing a ton of the work on the debugger. We're doing some of the work required in our compiler. But the majority of the effort for adding edit-and-continue to VB.NET falls outside the physical VB team. So the push for productivity actually comes from the entire division.
The VB team isn't inhibiting any of the functionality that needs to exist in the framework in order to simplify things for developers, but it's building easier-to-use interfaces for taking advantage of things inside the framework. A lot of what the VB team does is spend time with the Indigo guys or the CLR guys to discuss how to make things easier from a developer standpoint. We discuss the object model and how it should be put together. We discuss how you should be able to navigate the object model without having to turn to the help files. For example, 600 overloaded constructors might not be the right thing to do. We actually have a best practices document that describes how to create approachable frameworks—frameworks that are friendly to VB and other developers.
Again, we're pushing our teams to do the right thing, which is to build a platform with the requisite robustness and security, but to do so in a way that the features provided will also make all developers more productive.
PM: What is there about Whidbey that will compel VB6 developers to move to this version of VB.NET, to the extent that the move is up to the developer?
CD: What we want to nail in Whidbey is the wow factor that was present in VB1. There are a lot of reasons people haven't moved to VB.NET from VB5/6. Part of it was a messaging problem. For example, there are some people who've looked at VB.NET and see it as this tool for creating Internet applications. But some developers aren't doing Internet applications, so they think VB.NET has nothing in it for them.
But the fact is, VB.NET has some great rich-client features. We're working on making sure that message comes through loud and clear. The Windows Forms team is doing some great work; laying out forms, building data access applications, and deploying rich client applications are all incredibly intuitive in Whidbey. The UI stuff and the one-click deployment stuff should be hugely appealing to developers of all types.
There are people who haven't moved forward because VB.NET represents a platform shift to them. They need to get the framework rolled out onto their machines. We're doing things to make that transition easier, as well, such as bootstrapping the runtime onto the quick-launch deployment. This makes it easy to distribute the runtime throughout your organization.
There are many different reasons various segments of the audience haven't adopted VB.NET, but the Whidbey release will give many of these segments compelling reasons to move forward.
The other thing we can do at Microsoft as a whole is to continue to feature VB at the keynotes. It's important that we relay to our customers just how much the tool now holds for them.
PM: That would include making timely samples available, as well.
CD: Absolutely. The samples have been a problem. It's not surprising you saw so many C# examples, if you consider the fact that the majority of people Microsoft hires are C/C++ developers. But we're making a huge push at Microsoft to have parity between the languages, not just in terms of raw capabilities, but in terms of providing documentation and samples.
PM: Does the migration wizard matter when making this transition? Isn't some of the disappointment people have expressed with the tool over the migration wizard related to efforts to port code that never really needed porting?
CD: The migration wizard will move more stuff forward to VB.NET; we continue to hone the wizard and improve the experience of those who need to port their existing code to .NET. For example, the Wizard will take advantage of some of the My.Classes functionality, such as being able to display a form by typing Form2.Show.
PM: Speaking of transitions, did it bother you when some people said that some of the changes in the transition from VB to VB.NET were gratuitous or unnecessary? Is it fair for developers to look at the changes that were made and be concerned about the longevity of future code they might write?
CD: Ahh. Language stability. People having concerns, I understand that. People being concerned, I don't see cause for that. We're not going to go rebuild the program again anytime soon. I think that the changes we made to the product were the right thing to do.
The ironic thing is, we made these changes to the product so we could continue to move it forward. In the course of that, we made some changes that might or might not have needed to be done, such as the changes with End While. We did it, really, for stability, so VB could be a viable tool for years to come.
This product is stable. We're betting on it. We're going to do everything we can for the language and those who use it to make it a powerful and productive environment, something they can use without reservation for many years to come.
PM: We've discussed My.Classes a fair amount so far. Please sum up what they are and whom they are for?
CD: They are for everyone. Everyone should feel free to use them.
They are essentially another namespace inside VB.NET. The primary goal with these classes was to provide a quick and easy way to find common functionality in the framework through IntelliSense. IntelliSense is a great tool for people to navigate and learn how things work. People often start at the top of a list of IntelliSense commands and try each one of them (see Figure 1). But the current breadth of the framework makes it difficult for people to find things. It's not that it's hard, but that it's so big. So what we're trying to do with these classes is provide a simple way to find the common functionality they need.
We looked carefully at how people build applications, how they assemble forms and access data, and eventually My.Classes evolved into a higher-level scoping project. They're simply thin pointers on top of the framework classes. We understand that some developers like to do everything themselves. They want to put the pedal to the metal and write the 55 lines of code to print. If that's what you want to do, great. If you want to write one line of code, that's great, too. In fact, we think most people will appreciate being able to implement that functionality with one line of code. This is one of the things that VB has always been about.
PM: I've had a lot of discussions about this feature with developers who are regular contributors to the magazine. Some people love them; others are highly ambivalent. I'd sum up some of the reservations I've heard in this way: In the same way that wizards aren't necessarily RAD, productivity doesn't necessarily mean ease of use. For example, do My.Classes really make you more productive or simply delay the point where you hit the framework wall, without improving your ability to write nontrivial apps?
CD: Does writing 50 lines of graphics code make you a better programmer? My question would be: Is that a wall that you need to hit? If, in order to be a better programmer, you need to go learn the low-level APIs of printing, then My.Classes would impede you getting there because you chose to do so in only a few lines of code.
PM: I take your point, there. Let me spin it in a slightly different way. Nearly everyone I've talked to agrees these classes make it easier to accomplish a fair number of tasks. On the other hand, they give you a new way to do some things. Is this a return to the less-than-fondly remembered days of VB6, where you had a multitude of keywords that did something similar, but did them in a slightly different fashion?
CD: No, and we're working hard to make sure that doesn't happen. As I said earlier, My.Classes are just pointers into the framework, where we get the environment variables for you. We get the same environment variables that you would get if you went through the framework natively. We're not doing things differently, but getting you to where you want to go more quickly. This is a huge win for the customer.
PM: I spoke to a prominent software architect yesterday who told me he thinks that MyClasses will add to the complexity of applications and maintenance. Yes, some individual tasks might be easier, but long-term, he thinks this will come back to bite enterprises whose employees rely on this functionality. He said people like himself will be forced to add to the list of rules and requirements for applications built to accommodate these code permutations or, more likely, will be forced to use another language such as C#.
CD: People can write bad code in any language—and do. Is providing features that get developers using the tool more quickly and more robustly than would otherwise have been possible a bad thing? Of course not.
If someone is so concerned that developers will use features in VB they don't want them to use that they would think about requiring a different language instead—well, I would simply say if that's what you want to do, that's what you want to do. It's fine because it's all in .NET in the end, and you'll be able to create the same application, whether you use C# or VB.NET.
A more interesting outgrowth of this idea is this: How can we add functionality to the tools that will enforce coding practices in an organization? We've had templates in previous versions of the tool—I'm not sure what the status of those is right now—but we could do something like that. We could restrict what appears in the toolbox. That's a feature that we need to consider across the programming languages, not just in VB. It would be nice to be able to flip a switch that says when in VB, you can't use On Error or you can't use My.Classes, if that is your company's preference.
PM: I don't have the citation handy, but I believe Gartner projected recently that C# developers would equal or surpass VB.NET developers as soon as 2007 or so. If that came to pass, how would that affect VB's role as the everyman's tool in the VS.NET lineup? For example, if that came to pass, would that mean that VB had failed in its goal of being a broad-based tool for developers of all skill levels?
CD: I think what you're asking is: Would that be the death of VB.NET as a language? But the truth is: I don't think it would be significant at all. What we're trying to do is provide a language and a tool that appeal to a set of developers. If it turns out that C# appeals to a larger number of developers than VB.NET does, but that we appeal to VB developers in the right way, then that's fine. If VB.NET users love the tool and are productive with it and create a lot of terrific applications with it, that's great. There is space for both C# and VB.NET. If there are more people using C#, and they are happy and productive and creating great applications, that's great.
PM: From Microsoft's perspective, does it really matter what tool developers use, as long as it is a .NET programming language?
CD: It doesn't matter, as long as people use VB.NET or C# for the right reasons. If they're using a particular language because they like using the language and they feel more productive when using the language, then no, it doesn't matter. If they're choosing a language because a Microsoft VP mentioned C# more often than he mentioned VB.NET in a given magazine article, that's the wrong reason. People shouldn't be forced to use a particular language, but to use that language they feel works best for them and makes them most productive.
PM: Let's look at things from the other side. On the one hand, you have the software architect I mentioned earlier, who argues that Whidbey is a step backward—it is more VB6-like, but less enterprise-ready. On the other hand, I'm still talking to users who think VB.NET is too complex for creating anything beyond a trivial app. When you hear these kinds of criticisms, do you ever get the feeling you can't win? Hey! It's too hard! Hey! It's too easy! How do you know when you've done the right thing, notwithstanding the contradictory feedback you receive?
CD: It is always going to be a judgment call, and sometimes it is as scientific as a gut feeling. I've been working on VB for 10 years. I haven't worked on anything else at Microsoft. I am VB to the core.
I get a good feeling when I look at the product and see that I've made decisions that will make everyone who uses the product a more productive programmer.
The other part of it is as simple as talking to people. We actively solicit feedback on this tool, and do everything we can to learn how people use the tool. In the end, we know we've hit the sweet spot when we look at the number of people who are using the tool and are happy with the tool. But a lot of it is simply seeing 70 or 100 people in a room saying we have the right product.
PM: How does someone decide between C# and VB?
CD: One question we hear a lot is: Where are you going with these tools? How are they going to diverge? The root of the question is: Is there something they won't be able to do in VB.NET that they will be able to do in another language such as C#? The answer to that is "no." There are features that one or the other might not have, but the fundamental capabilities will be the same, because they derive from the framework.
What we're really looking at diverging isn't the development capabilities, but the development experience.
The background compiler is a good example of this. The C# guys sit downstairs, and every so often they'll come upstairs and give everyone on our floor a hard time. Someone will come up and say to us, "I was using VB the other day, and when I hit return, the language started yelling at me: 'You did something wrong! You did something wrong!' I know I did it wrong; I'm not done yet! Just let me finish my job!"
And I'll respond: "Well, I was using C# the other day, and I typed my code and hit return, and nothing happened! I said, 'C'mon! Give me something. Let me know if I did the right thing.'"
It's just two different ways of thinking about and building apps. C# and C++ guys like to write a lot of code, hit Build, and see what happens. VB guys want that immediate feedback. I want that slap on the hand or a good job. It's those types of differences that really define a C# or a VB programmer. The development teams try to target their features around these kinds of sensibilities.