Back to VSLive! San Francisco Show Daily Home

	email article
	printer friendly

It's Time for Language Divergence
We need to reemphasize what made VB great in the first place.
by Patrick Meader

VSLive! San Francisco, February 13, 2003

During the VSLive! San Francisco keynote hosted by Eric Rudder on Tuesday, Microsoft unveiled a sneak peek at Whidbey, the third iteration of Visual Studio .NET. The biggest cheer of the keynote occurred when Microsoft showed off a working implementation of Edit & Continue, the much-beloved VB RAD feature that didn't make it into the initial two versions of VB.NET. The importance of this feature isn't so much what it does, but what it represents. It is one of the many features that Microsoft built over the years for VB that simplified development and enhanced productivity.

Its absence has been felt and discussed often among those who use VB.NET. VB.NET and C# are fraternal twins in their initial (Visual Studio .NET) and follow-up (Visual Studio .NET 2003) implementations. I suspect this wasn't so much by design, but related to the fact that creating C# and porting VB to the .NET Framework left little time for other enhancements.

Patrick Meader Editor in Chief

Inclusion in the framework meant these languages acquired the host of features delivered by the .NET Framework, the ability to create Web apps more easily being the most important. Without this feature, I think VB.NET would be shunned by many corporate customers in favor of others languages that do have it (read: Java). Had Microsoft instead created a version 7 of VB that built on VB5 and VB6, I think VB would be akin to Visual FoxPro, beloved by those who use it, but marginalized from (the future of) mainstream development.

Many of the framework's features are great, but functional equivalence isn't everything, and VB lost some of its RAD spirit in the transition. The emphasis in the first two versions of VB.NET has been more programmer-focused (inheritance and the extensive framework classes that sit underneath) than task-based, which is where VB has shone in the past. I think the power and control VB.NET developers have over the system is great—and many developers have welcomed it—but now it's time to reemphasize what made VB great in the first place.

C# and VB.NET developers are different users, similar to C++ and VB developers before them. It's not that some VB.NET developers don't want power and control, nor that C# developers don't want ease-of-use. But on a continuum, the majority of VB.NET developers prefer productivity, whereas C# users tend to prefer raw power and control. There is a place for both these attitudes in VS.NET—but they don't have to be espoused within the same language.

The reason VB took off in the first place is that it enabled people to get work done, and I'd like to see a push to incorporate more of the nifty RAD innovations that comprise VB's legacy to the world—features such as drag-and-drop controls and IntelliSense.

One caveat: Wizards aren't RAD, but a crutch for when the RAD features you'd like aren't in the tool. As often as not, you spend your time fighting and overriding a wizard instead of having the functionality you want generated for you. Wizards also divert you from the task at hand. Worse, wizards often introduce you to solutions that accomplish simple tasks, but fail when applied to anything that approaches a real-world scenario. True, some wizards are indispensable, but what developers really need are features that promote ease-of-use and the ability to create the necessary code yourself.

If wizards aren't ease-of-use, what is? Ease-of-use is Edit & Continue. It's simplified access to the underlying framework. It's extending the scope of IntelliSense and enabling end-to-end debugging (when possible) of any type of application you create from within the VS.NET IDE, whether you create a given component or simply consume it. It's being able to create templates for your app's business rules, then ensure they're enforced from within the IDE. It's also being able to create your applications more quickly and more reliably, and having the IDE tell you when you've created code that will fail, not just at compile time, but when the application runs—without having to run the application.

I think Microsoft is moving in the right direction, but I'd like to see more—I'm greedy that way. But it's up to you, as a developer, to tell Microsoft what you want. It is your feedback that led to the restoration of Edit & Continue in Whidbey, and it is this that will lead to the inclusion of other features you find indispensable.

About the Author
Patrick Meader is editor in chief of Visual Studio Magazine.