Sam Gentile suggests that Microsoft could not make VB.NET source-compatible with VB6 due to the latter's COM underpinnings. A nice theory, Sam, but I'm not buying it: MS had little trouble maintaining source compatibility when it re-plumbed VB4 to use COM; I don't see why it couldn't have done the same when it replaced COM with .NET. Certainly a few changes (such as ref counting vs. GC) were unavoidable, but many (most?) of the items on Karl's list could have been avoided.
I understand that MS had to make difficult decisions in the face of tight deadlines and limited resources; it had to get VB.NET out the door as quickly as possible. But now that it's shipped, why not improve VB.NET's compatibility with VB6, even if only by means of a deprecated compatibility namespace? This would undoubtedly spur increased adoption of .NET, and underscore Microsoft's commitment to VB as a serious development tool.
Comments
Posted by Sam Gentile on January 16, 2003:
Posted by Mike Gunderloy on January 19, 2003:
“MS had little trouble maintaining source compatibility when it re-plumbed VB4 to use COM”. Actually, during the VB4 beta, there were equally loud howls (from some of the same people who now defend the sanctity of VB6) that Microsoft was breaking the language. There is a group of vocal developers who believe that Microsoft does not own the language, and who whine at any change. Outside their own little world, I don’t think many VB developers take them seriously any longer.
Posted by Dave Rothgery on January 22, 2003:
Eh. The incompatibilities between VB.NET and VB6 can be broadly categorized as
1) library incompatibilities (UI, IO, strings, database, and web), which not much can be done about, though the compatibility namespace helps here and could probably be expanded some
2) COM vs. .NET incompatibilities (side effects of garbage collection instead of reference counting, COM interop issues), which not much can be about beyond improving COM intereop and possibly adding some auto-dispose syntactic sugar to VB.NET (similar to what they did with using in C#, though I’d prefer to use another keyword rather than overloading Imports).
3) OOP incompatibilities. Some things work differently in VB.NET because it’s a full-featured OO language, while VB4-6 was in a halfway house between OO land and procedural land. Again, it’s hard to do much about this.
4) Fixing bad VB Classic design decisions. 16-bit Integers, defaulting to pass by value, and the hundreds of variations on procedure calling syntax were serious problems in VB6; leaving them alone would have kept anyone but VB6 diehards from taking the language seriously.
Posted by Mark Hurd on January 23, 2003:
ffs what is it with having multiple ways of calling routines? There are multiple ways of doing almost anything on a computer. If you don’t want to confuse students don’t teach them all the options straight away!
And then if you’re going to drop one of these:
X a, b, c Call X(a, b, c)
when at the same time you remove
Let Y = z
from the language, which would it be?
Posted by Dave Rothgery on January 23, 2003:
I’d ditch all of them (and just use X(a, b, c) for procedure calling), but you expected that answer, right? Both Call and the no-parens method calling syntax are impractical if a method returns anything; the only reason I approve of the Sub/Function dichotomy is because it’s less hokey than the C style of claiming the return type is ‘void’.
Leave a comment
I don’t know. It’s just a guess and a theory. But take it from someone who has done COM Interop with millions of lines of COM code - it doesn’t work very well with non-trivial COM code bases that use Connection Points, etc. Don’t underestimate the effort involved-)