Noel Coward: "I like long walks, especially when they are taken by people who annoy me."
Noel Coward: "I like long walks, especially when they are taken by people who annoy me."
I went ahead and ordered a Palm Tungsten/T and Sony Ericsson T68i this week. Bought the Palm online for about $400; AT&T (my current cell provider) sold me the phone for $100 after discounts and credits. That's $100 more than I would have paid had I switched to T-Mobile, but I got to keep my existing phone number, and AT&T's wireless data plan will save me $7/month over a comparable T-Mobile plan, so it won't take long to recoup the cost of the phone.
So far, everything looks pretty cool: via Bluetooth, I can use the phone as a wireless modem for the Palm without removing the phone from my pocket. (In informal speed tests, I've only been able to get up to about 25 Kbps.) I can also use the phone as a modem for my laptop via infrared, and, of course, I can send and receive e-mail and visit WAP sites on the phone itself. I'll be happier when I can get Wi-Fi anywhere, but it's nice to be able to check e-mail or surf the Web (well, it's not so much surfing as it is treading water) at near-dial-up speed when I'm nowhere near a laptop or a landline.
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.
Nathaniel Borenstein: "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents."
More ASP.NET goodness: Another library of cool [and free!] ASP.NET controls: http://www.metabuilders.com
Source: Sean 'Early' Campbell & Scott 'Adopter' Swigart's Radio Weblog
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.
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."
Enumerating the advantages of .NET's Managed Extensions for C++ (MC++), Sam Gentile writes:
Though not a member of the "VB.NOT" 1 contingent, I am dismayed by the above list: Why should C++ developers enjoy such ease of migration to .NET, while VB developers (of whom there are arguably many more) are forced to rewrite their code? I disagree with the opinion that VB is a "dead language" -- there are plenty of apps with limited life spans (say, up to 10 years) for which VB has been and continues to be ideal -- but it would have been nice if Microsoft had demonstrated its commitment to VB by making it as effortless to migrate "Classic" VB code to .NET as it did to migrate C++ code. The message seems clear: If your application is "mission-critical" 2, don't use VB.
1. For the record, several items at this link are misleading or inaccurate.
2. I don't consider most of my apps to merit that description -- I think many developers flatter themselves by believing that their code must live forever -- but there are clearly apps that do. For these, VB would seem to be a questionable choice.
Here's a cool ASP.NET tip from Sean 'Early' Campbell & Scott 'Adopter' Swigart (actually from their associate, Richard Hundhausen):
If you've got a password textbox name txtPassword, you cannot assign the Text property to it in code, or via DataBinding. This is by design. Here's a workaround, however:
txtPassword.Attributes.Add("value", "abc")
Now keep in mind, just because you can do this, doesn't mean you should. This is "by design" for a reason.
George Bernard Shaw: "The power of accurate observation is commonly called cynicism by those who have not got it."