email article printer friendly

It's Time for Language Divergence
by Patrick Meader

April 2003 Issue

Patrick Meader Editor in Chief

What direction would you like to see C# and VB.NET take? Tell me at ednote@ fawcette.com or discuss this in the Talk to the Editors of Visual Studio Magazine forum on our Web site. Use this Locator+ code: VS0304EN_D

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.

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 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 language-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.

It's becoming increasingly clear that C# and VB.NET developers are different users, similar to C++ and VB before them. It's not that some VB 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 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 tool. Indeed, it would be limiting to attempt to make a language be all things to all developers.

I'd like to see the third iteration of VB.NET (code-named Whidbey) get back to its task-based, RAD roots. The reason VB took off in the first place is because 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 to have aren't there. As often as not, you spend your time fighting and overriding a wizard instead of implementing the functionality you want. 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 code you need yourself.

If wizards aren't ease-of-use, what is? Ease-of-use is edit-and-continue. It's simplified access to the underlying framework. It's extending the scope of IntelliSense and enabling end-to-end debugging 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 draft your business rules for an application visually, then being able to verify they're implemented in the manner prescribed. 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 should add that I was fortunate recently to see a demo of VB.NET's Whidbey version in an early alpha. I can't disclose what I saw, but I can say that I'm encouraged by some of the RAD features I saw incorporated. I think Microsoft is moving in the right direction, but I'd like to see more—I'm greedy that way. Regardless, it is up to you, as a developer, to tell Microsoft what you want. There are various ways to do this—send letters to the editor of a magazine such as this one, e-mail the general-purpose wish list that Microsoft maintains, or simply talk to the appropriate Microsoft personnel when you see them at shows.