Myth-Busting Busting

The Classic VB petitioners have posted a FAQ page explaining their goals and the motivations behind them. (Hint: Contrary to what you may have read elsewhere, the impending end of mainstream support for VB6 is not the primary issue!) On the lower portion of that page is a section titled, “Myth Busting” which includes a myth of its own:

To take a trivial example, there is no defensible reason why a QuickSort algorithm should need to be rewritten because you have a new compiler for a language targeting a new platform.

Is it true that a VB6 QuickSort algorithm must be rewritten in order to recompile it for .NET? Let’s see…

Here’s a VB6 QuickSort implementation I found on the Web:

Public Sub Quicksort(ByRef list() As Integer, ByVal min As Long, _ 
    ByVal max As Long)

    Dim med_value As Long
    Dim hi As Long
    Dim lo As Long
    Dim I As Long

    ' If min >= max, the list contains 0 or 1 items so it is sorted
    If min >= max Then Exit Sub

    ' Pick the dividing value
    I = Int((max - min + 1) * Rnd() + min)
    med_value = list(I)

    ' Swap it to the front
    list(I) = list(min)

    lo = min
    hi = max
    Do
        ' Look down from hi for a value < med_value
        do while list(hi) >= med_value
            hi = hi - 1
            If hi <="" lo then exit do
        loop
        if hi <="" lo then
            list(lo) ="" med_value
            exit do
        end if

        ' swap the lo and hi values
        list(lo) ="" list(hi)

        ' look up from lo for a value >= med_value
        lo = lo + 1
        Do While list(lo) < med_value
            lo ="" lo + 1
            if lo >= hi Then Exit Do
        Loop
        If lo >= hi Then
            lo = hi
            list(hi) = med_value
            Exit Do
        End If

        ' Swap the lo and hi values
        list(hi) = list(lo)
    Loop

    ' Sort the two sublists
    Call Quicksort(list, min, lo - 1)
    Call Quicksort(list, lo + 1, max)

End Sub

And here’s the same implementation in VB.NET:

Public Sub Quicksort(ByRef list() As Integer, ByVal min As Long, _ 
    ByVal max As Long)

    Dim med_value As Long
    Dim hi As Long
    Dim lo As Long
    Dim i As Long

    ' If min >= max, the list contains 0 or 1 items so it is sorted
    If min >= max Then Exit Sub

    ' Pick the dividing value
    i = Int((max - min + 1) * Rnd() + min)
    med_value = list(i)

    ' Swap it to the front
    list(i) = list(min)

    lo = min
    hi = max
    Do
        ' Look down from hi for a value < med_value
        do while list(hi) >= med_value
            hi = hi - 1
            If hi <="" lo then exit do
        loop
        if hi <="" lo then
            list(lo) ="" med_value
            exit do
        end if

        ' swap the lo and hi values
        list(lo) ="" list(hi)

        ' look up from lo for a value >= med_value
        lo = lo + 1
        Do While list(lo) < med_value
            lo ="" lo + 1
            if lo >= hi Then Exit Do
        Loop
        If lo >= hi Then
            lo = hi
            list(hi) = med_value
            Exit Do
        End If

        ' Swap the lo and hi values
        list(hi) = list(lo)
    Loop

    ' Sort the two sublists
    Call Quicksort(list, min, lo - 1)
    Call Quicksort(list, lo + 1, max)

End Sub

Can you spot the difference? (If you intend to point out that Integers and Longs are different sizes in VB6 and VB.NET, please include an example demonstrating how that difference affects the algorithm’s behavior.)

Here’s another:

Why not leave functioning code in VB6, and write new code in VB.NET?

That's a fine solution for the problems it fits. Many developers can indeed let existing applications linger in VB6 forever (assuming future OS changes don't break them), and concentrate all their efforts on developing new VB.NET-based applications. For the great majority of VB developers, however, there is continuing need to revisit and revise legacy applications. While Microsoft may no longer want to support VB6, great numbers of VB6 developers still intend to support their customers with ongoing bug fixes and application enhancements.

Ahem. What prevents VB6 developers from supporting their customers with bug fixes and application enhancements in VB6? Nothing. That’s exactly how my employer is supporting its customers’ VB6 code.

 17 Mar 05 2:09 AM · Comments (5) · Tags: .NET, VB

My Thoughts on the Classic VB Petition

Much has been written over the past week regarding a petition asking Microsoft to continue development of “Classic VB.” I have chosen not to sign the petition; here’s why:

First of all, let me emphasize that I am not unsympathetic to the difficult choices faced by those with a large investment in pre-.NET VB code. Some people have built entire companies around products written in VB; the future of that code is quite literally the future of their livelihood. Microsoft has put them in the unenviable position of having to choose whether to leave their code in VB6 and hope that it remains viable, or to rewrite it some other language, which will cost time and money.

If I had been in charge when VB.NET was being designed several years ago, I would certainly have kept those developers in mind, and not broken compatibility with VB6 unless it were absolutely necessary. But wait: Microsoft is full of brilliant people; don’t you think the VB team thought of this? It’s the height of arrogance to believe that we’re aware of considerations that have never occurred to them.

VB.NET is a product of conflicting goals: On one hand, the VB team sought to maintain backward compatibility with VB6. On the other hand, they needed to make VB.NET a first-class .NET citizen, or risk further accusations that it’s a “toy language.” On a third hand, they needed to ship .NET and its key languages as quickly as possible in order to compete with Java and other tools which were nipping at Microsoft’s heels. While there were undoubtedly features the VB.NET team would like to have delivered in version 1.0 (such as edit-and-continue and closer compatibility with VB6), the tight schedule simply didn’t allow it.

How should Microsoft have handled cases in which “the .NET way” and “the VB6 way” were at odds (such as the size of the default integer data type)? The “correct” answer depends upon your point of view; the VB team was damned either way. I’m sure there were many spirited discussions on issues like this one. We may not agree with the final decision, but that doesn’t mean Microsoft didn’t seriously weigh both sides of the issue.

This is one problem I have with the Classic VB petitioners: They focus solely on the goal of VB6 compatibility, while ignoring the perhaps equally important goal of parity with other .NET languages. Any proposal which Microsoft is to take seriously must consider VB’s future, as well as its past.

Another issue: Microsoft doesn’t create development tools out of the goodness of its heart. The business case for tools like Visual Basic and Visual Studio is to drive adoption of Microsoft’s platform du jour. (Remember Steve Ballmer’s “developers, developers, developers” chant?) In the last decade, that platform was Win32, and versions 4 through 6 of VB helped a lot of people create a lot of software for that platform.

Today, the target platform is .NET. Company representatives have stated that Microsoft has “bet the company” on it. But here’s the problem: Some of the Classic VB petitioners — in fact, many of the driving forces behind the petition — have made no secret of the fact that they have little interest in learning or using .NET. They would have Microsoft keep cranking out new versions of COM-based VB for as long as it’s willing to do so. What’s the incentive for Microsoft to spend millions of its dollars and years of its developers’ time, if it won’t help drive adoption of its current platform?

Now, if the petition had said, ‘We want Microsoft to help us migrate our VB6 applications to .NET as easily as we were able to move our code from, say, VB3 to VB4,’ I would have signed in a heartbeat. Classic VB developers could preserve their code assets, and Microsoft would get potentially millions of additional developers creating .NET applications. Everybody wins.

Of course, nothing prevents the Classic VB petitioners from working on their own compiler/conversion tool/compatibility library to ease migration of VB6 code to .NET. This would be an ideal project for the 2,000+ signers of the petition, and I have repeatedly suggested and offered to contribute to such a project. I have also pointed out that the source code for two “nearly-VB” .NET compilers is readily available. If you’re interested in contributing to such a project, please post a comment below.

 17 Mar 05 12:19 AM · Comments (2) · Tags: VB

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

I have a dream...

Julia Lerman laments the VB.NET stigma and C# elitism being perpetuated by the trade press. In particular, she refers to this editorial in asp.netPRO magazine. I found that editorial troubling as well. In it, Elden Nelson writes:

Whether it's just or not, C# developers make more money, get work more easily, and enjoy more prestige than VB developers.

He then recommends that VB.NET developers learn C# at their earliest opportunity, presumably to cash in on the cachet.

Now, I don't disagree that it's a good idea for VB developers to learn C#. But I do object to asp.netPRO's tacit endorsement of language bigotry. What if the editorial had said:

Whether it's just or not, white developers make more money, get work more easily, and enjoy more prestige than minority developers

(Or, as one of the commenters on Julia's blog suggests, "...male developers make more money, etc. than female developers")? If the situation is 'not just,' as Nelson implies, why isn't he working to change it?

 15 Aug 03 9:22 AM · Comments (1) · Tags: .NET, Rants, VB

A Solution to the VB.NOT Crowd

Unhappy with the state of VB.NET? Here are two things you can do about it:

• Kent Sharkey links to a new APress title by Edward Nilges, Build Your Own .NET Language and Compiler. The book includes a complete QuickBasic-compatible compiler with source code! Buy it, and you're halfway to VB6.NET. (While locating the links for this item, I stumbled across this project: an open source, QuickBasic-compatible compiler for Windows.)
• Microsoft is looking for a developer to work on "language conversion tools to convert VB6 projects to VB.NET and to convert Java J2EE projects to C#.NET." Apply now!

 14 Jul 03 3:42 PM · Comments (1) · Tags: .NET, VB

In Defense of "Mort"

My long-time colleague Keith Pleas (remind me to tell you about the trip we took together to South Africa...) has started blogging, and he's off to a good start: I particularly enjoyed this post, defending lowly VB programmers against the condescending attitude of certain self-important semi-colon jockies. ;-)

Go, Keith!

  9 Apr 03 2:28 PM · Comments (0) · Tags: VB

Is Inheritance Overrated?

I had looked forward to using implementation inheritance for the first time in my current project. Is it just me, or is inheritance more trouble than it's worth? [Read more]

 27 Nov 02 5:49 PM · Tags: .NET, VB

In Touch with My (Case-)Sensitive Side

OK, here's a nugget that could have saved me several hours: XML is case-sensitive!

I'm working on a content management system which saves content objects as XML in a SQL Server database. A typical content object might look something like this:

    <?xml version="1.0"?>
    <Content>
      <Items>
        <Item Name="Title">Document Title</Item>
        <Item Name="Author">Phil Weber</Item>
        <Item Name="Publication">Visual Studio Magazine</Item>
        <Item Name="Issue">December, 2002</Item>
        <Item Name="Body">Document Body</Item>
        ...etc.
      </Items>
    </Content> 

So, I wrote some code (in VB.NET, which is not case-sensitive) to extract individual content elements, and it wouldn't work -- kept returning empty strings! I spent hours poring over the code, tweaking the XML, banging my head against my desk... Turns out I was looking for an Item whose Name attribute was equal to title instead of Title. GRRRR!

Go ahead and laugh, but if you ever make a similar mistake, you'll thank me!

 19 Nov 02 9:38 PM · Comments (1) · Tags: .NET, VB