Karl Peterson says that my characterization of his list of Visual Fred incompatibilities is "uncalled for", and invites me to "enlighten us" if I am "aware of actual inaccuracies." OK, Karl, here are a few:
60. The MsgBox function is not supported.
Wrong. Both the statement and function forms of MsgBox(Prompt, [Buttons], [Title]) are supported in VB.NET.
49. LSet is not supported.
50. RSet is not supported.
Misleading. While the syntax has, admittedly, changed, LSet and RSet are both supported in VB.NET:
Dim sBuffer As String
sBuffer = LSet("Hello", 30)
sBuffer = RSet("Hello", 30)
52. UDTs are not by default contiguous blocks of memory, but are objects.
Misleading. If you remove the weasel words "by default," it's simply incorrect. See http://discuss.develop.com/archives/wa.exe?A2=ind0201D&L=DOTNET&P=R58908.
61. The DoEvents function is not supported.
Misleading. While technically correct that the DoEvents function (which returns the number of open forms in VB6 and earlier) is no longer supported, the DoEvents statement, which processes all Windows messages in the message queue, is alive and well in VB.NET.
114. Debug.Assert is not supported.
Wrong. Debug.Assert is supported in VB.NET.
There may be others; those were just the ones that immediately jumped out at me. I hope those examples are sufficient to support my characterization of "several items at this link [as] misleading or inaccurate."
Comments
Posted by Karl E. Peterson on January 15, 2003:
Posted by Phil Weber on January 16, 2003:
I understand “not supported” to mean that a statement or function is no longer available in the language (as indicated by your use of the term in reference to As Any, Option Base, GoSub, etc.) If that is indeed what it means, then it is inaccurate to state that MsgBox, LSet, RSet and Debug.Assert are “not supported,” since they clearly are. At best, it’s ambiguous to use the same terminology to describe keywords that have been removed from the language altogether and keywords which are still present, but have changed in some way. Why not update your page to state the situation more accurately, e.g., “HelpFile and Context parameters of MsgBox function not supported,” “LSet and RSet syntax changed, UDT copying functionality not supported,” etc.?
OK, granted, the DoEvents function is not supported. You’ll forgive me for not being clear on your meaning, since you also state that the MsgBox function is not supported, when in fact it is?
Yes, I have used LSet and RSet to justify field values within random-access file buffers, back when that was their only function. As mentioned above, it would be more accurate to describe how their functionality has changed, rather than to claim that the keywords are “not supported.”
Can you provide a real-world example of code that is broken by the change described in item #52?
Finally, the only change required to use Debug.Assert in VB.NET is to add the line, “Imports System.Diagnostics” at the top of the module. I’d hardly consider that to be “not supported.”
I don’t dispute that VB.NET is significantly different from VB6, or even that many of the changes were unnecessary. But you hurt your case by making exaggerated or ambiguous claims. Wouldn’t all sides be better served by your stating the situation as accurately as possible?
Posted by Karl E. Peterson on January 16, 2003:
Okay, I’ll grant you the list contains statements that could be greatly expanded. I didn’t want to write a long description of each breaking change, as there were numerous other sites on the web, including Microsoft’s, that went into details on each and every bullet point.
The list was entirely intended, and it stands, as “areas to watch out for.” Words to that effect have always been part of its preamble. Is it sensationalistic? Sure. The destruction of the language is near complete.
I totally agree with your latest assertion that other than a very few items (such as reference counting and deterministic finalization), Microsoft could have maintained near complete forward compatability. They let us, their customers, down.
The community has been destroyed. As for “serving all sides better,” I leave that to someone who cares. I’d have to actually spend time with the abomination (VFred) to do so. The framework isn’t installed on any of the computers under my control, and hasn’t been since beta 1. It’s a damned joke.
Finally, I have no “case” to make. I state my own personal situation as it stands – I can’t trust Microsoft to protect/shepard code assets developed in Visual Basic. Clearly, that is not a priority, or even concern, of theirs. You seem to be in agreement on that. I can only wonder why it took so long.
.NET: It’s About Trust!
Posted by Phil Weber on January 16, 2003:
I don’t believe that someone who refers to VB.NET as “Visual Fred” and an “abomination” has “no case to make.” You claim to be objective and “About Trust,” yet you decline to update your (admittedly sensationalistic) page to make it more accurate or easily understood. How does that make you any more trustworthy than Microsoft?
As to my agreeing with your opinion on the viability of Visual Basic code, I think you view the situation much more extremely than I do. I agree that preserving VB6 code was not as a great a priority to MS as was preserving VC++ code, and I’m trying to do something constructive to change that. I think MS does what it considers to be its best to preserve VB code for as long as possible, and only breaks it when it believes it has a good reason to do so. I don’t consider VB to be good only for “throwaway scripting”: I haven’t had to throw away any of my “Classic” VB code yet. If VB.NET 1.0 code remains viable for 10 years, as did “Classic” VB, that’s good enough for me.
People get angry when reality deviates from their expectations. If people understand that VB is not set in stone, that it’s not reasonable to expect their code to run unchanged indefinitely, perhaps they’ll feel less betrayed the next time it’s broken.
Posted by Karl E. Peterson on January 16, 2003:
Well, Phil, you seem hellbent on arguing. All I did was tell ya like it is. If you think I’m trying to “make a case” that’s fine with me, and you can argue that point all you want, but it just doesn’t change the simple fact that I can’t be bothered to care.
I think your summary speaks volumes, btw.
Posted by Karl E. Peterson on January 16, 2003:
Almost forgot this little gem:
How does that make you any more trustworthy than Microsoft?
Let’s just keep in mind that I’m not selling anything. ;-)
Posted by Rob Abbe on January 25, 2003:
Phil,
Why is it so hard for you to admit that VB.Net is a departure from VB? Coding in them is almost nothing alike. It’s easier to compare C# or Java to VB.Net code than it is to compare VB.Net code to VB6 code. It’s true that much of the language is unchanged and it’s not fair to call it a completely new language, but it is however a big departure from VB6. For many (most by our estimate) developers, learning VB.net will require retraining in order to support development in a cost effective manner. We would just as soon spend that money on a language that has prooven to be stable. These days we like Sun a whole lot better than Microsoft.
Rob Abbe
Leave a comment
Well, Phil, I suppose I should’ve expected this.
As for #60, “The MsgBox function is not supported.”, yeah, I could’ve inserted “fully” there between “not” and “supported” to indicate two optional parameters were dropped. Maybe you’d call this misleading, but again I’ll refer you to my original position that behavior and/or syntax was changed.
As for items #49 and #50, “LSet is not supported.” and “RSet is not supported”, not only has the syntax changed, but so has the behavior. These statements no longer support data types other than String. I can’t think of a single instance, in the twenty-odd years I’ve been using Microsoft Basic that I used either for that purpose, can you? Lame.
As for the “weasel words” in item #52, changes in default behavior constitute changes – breaking ones at that, in this case – just as do changes in explicitly coded behaviors. Given Microsoft’s non-stop encouragement to rely on default behaviors, I don’t appreciate that characterization either. You don’t like reality, just say so.
As for item #61, “The DoEvents function is not supported”, why bring it up if you’re not going to refute it. As you state yourself, it is no more. Only the statement variant is offered in VFred.
Finally, item #114, “Debug.Assert is no longer supported”, I grant you it is supported by .NET, but it certainly isn’t by VFred. The old Debug object offered by VB is now a class in the System.Diagnostics Namespace. Changes to your original code are most certainly required to use it.