More feedback to "VB: Second-Class Citizen?"

Interesting feedback to my post on Microsoft's preferential treatment of C++ developers: Over at DevX, the post spawned a thread containing several dozen messages. Larry Serflaten believes that it's easier for C++ to maintain long-term compatibility, because it's closer to the hardware and doesn't depend upon ever-changing abstraction layers. VB's problem, he says, is that MS pulled the COM rug out from under it, and created a new, incompatible abstraction layer (the .NET Framework). Since C# (which has been submitted to various standards bodies and which MS allegedly uses internally) depends upon the same framework, Larry believes VB.NET will remain more stable going forward than "Classic" VB has.

Well, Larry, I hope you're right, but changing the underlying framework should not have required major changes to VB's syntax. That's the very purpose of an abstraction layer: to isolate higher-level elements (such as syntax) from lower-level ones (such as hardware and the OS). As I stated in my reply to Sam Gentile, MS BASIC has remained relatively stable as it has progressed from CP/M to MS-DOS to 16-bit Windows to 32-bit COM. Changing the platform does not require wholesale syntax changes.

Meanwhile, over at Fawcette.com, Dennis suggests that VB had to change in order to become more object-oriented. That makes sense, but MS could have added OO features while keeping legacy syntax (e.g., GoSub, file I/O statements, etc. -- clearly marked as "deprecated") for compatibility purposes, just as it did with the String object vs. InStr, Left, Mid, etc.

Finally, Bill McCarthy suggests that the .NET situation for C++ developers is not as rosy as Sam Gentile suggests. Is this true? As long as C++ programmers have to suffer as much as VB devs do, I guess I have nothing to complain about. ;-)

I think the best solution for moving VB6 code to .NET would be to create a VB6.NET compiler: a tool that reads VB6 source code and emits MSIL. Would anyone be interested in participating in an open source project to create such a beast? Failing that, my second choice would be an improved Upgrade Wizard (along with several additions to the Microsoft.VisualBasic.Compatibility namespace) that generates cleaner VB.NET code and knows how to convert GoSubs into standalone procedures.

 24 Jan 03 6:21 PM · Comments (0)