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:
And here’s the same implementation in VB.NET:
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.)
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.
Posted by Karl E. Peterson on March 17, 2005:
Posted by Jeff Atwood on March 17, 2005:
Posted by Phil Weber on March 17, 2005:
Posted by Bruno on March 21, 2005:
Posted by Rob Abbe on March 21, 2005:
Leave a comment