Crisis? What Crisis?

In a comment, Kent asks:

Doesn't it bother you that MS doesn't see the current state of VB.Net as a problem?

No, Kent, it doesn't bother me, because I don't see the current state of VB.NET as a problem, at least not a major one. Here's why:

Microsoft has always positioned VB as a RAD tool. By definition, RAD applications are meant to be developed rapidly. So while I agree that it would be nice if VB6 code could port effortlessly to VB.NET, I don't think the fact that it doesn't will present a huge problem to the vast majority of VB users: Most VB apps were written in a few days or weeks, and/or were written to solve very specific problems. Many of these apps can be maintained in VB6 for the remainder of their useful lives. If they do need to be rewritten, doing so will not require a great deal of effort -- they were developed rapidly to begin with, remember?

Most of the angst I see regarding the lack of compatibility between "Classic" VB and VB.NET comes from people who have used VB not as a RAD tool, but rather to develop large, complex applications. They have made a large investment in VB code, and expected to be able to collect dividends on that investment for many years. If I were in their position, I'd probably feel similarly frustrated. But I don't think their frustration equates to a major problem for the "state of VB": Their situation is an exception, rather than the rule.

25 Aug 03 5:44 PM · Comments (3) · Tags: Rants, VB

Comments

Posted by Len Weaver September 28, 2003 8:28 PM:

> They have made a large investment in VB code,
> and expected to be able to collect dividends
> on that investment for many years. If I were
> in their position, I'd probably feel similarly
> frustrated.

It should be noted that in the case mentioned above the programmer would still have the option of using COM Interop to use their VB6 components in .Net, or use the COM type-library export tool to use .Net assemblies as COM components.

Posted by Kent October 3, 2003 9:20 PM:

Phil,

Seems like a year ago since I left that a comment.

While VB in general has been positioned as a RAD tool, so have others such as Delphi and yet only VB developers seem to enjoy this total break down in compatibility. So saying that breaks in compatibility are an inherit trait of RAD tools is a fallicy.

This problem will only fuel the sterotype VB has fallen into and VB.Net will not be selected for applications where VB once would have been.

The other problem for VB.Net is that as of right now VB.Net is no more a RAD tool than C# is.

Kent

Posted by Phil Weber October 3, 2003 10:06 PM:

> ...saying that breaks in compatibility are an
> [inherent] trait of RAD tools is a [fallacy].

Kent: Where did I say that?

> ...as of right now VB.Net is no more a RAD
> tool than C# is.

I disagree. So do these people:

"[Uttam Narsu, a vice president with Forrester Research,] said developers can produce programs faster with VB than with C#."

Microsoft's Paul Vick: "If you use VB.NET and VC#.NET for a while, you'll quickly realize that they are not just the same language with different syntax."

A few examples of what makes VB.NET more efficient (RAD) than C#:

Background compiler
Case-insensitivity
Better IntelliSense
Effortless late-binding
WithEvents

This disparity will only increase with future updates to the languages (see: Edit-and-Continue).