Speaking at VSLive!

I'll be speaking at the VSLive! conference in San Francisco on February 12. The PowerPoint slides for my presentation are here.

permalink 29 Jan 03 4:53 PM · Comments (0)
Quote of the Day

Alvin Toffler: "The illiterate of the 21st century will not be those who cannot read and write, but those who cannot learn, unlearn, and relearn."

permalink 29 Jan 03 4:03 PM · Comments (0)
Cool Stuff for My New Palm
  • Newpen: Enables Graffiti input directly on the screen. Perfect for the Tungsten/T, which hides the input area when the unit is collapsed. Free, 22KB
  • VeriChat: Unified IM client. Chat with AOL, MSN and Yahoo! Messenger users simultaneously. $24.95/year, 87KB
  • SilverScreen: App launcher with gorgeous color themes that replace standard icons. Drag-and-drop, shortcuts to frequently-used apps. $24.95, 300KB
  • McKinley-Burnstein Handwriting Analyzer: Hilarious handwriting "analysis" program. Amaze your friends! Free, 11KB

permalink 27 Jan 03 5:59 PM · Comments (0)
Linux 'Switch' Ad

Linux 'Switch' Ad: "Linux gives us the power to crush those who oppose us..."

permalink 27 Jan 03 2:07 PM · Comments (0)
Quote of the Day

Noel Coward: "I like long walks, especially when they are taken by people who annoy me."

permalink 27 Jan 03 1:58 AM · Comments (0)
New Toys!

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.

permalink 25 Jan 03 1:44 PM · Comments (0)
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.

permalink 24 Jan 03 6:21 PM · Comments (0)
Quote of the Day

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."

permalink 24 Jan 03 4:45 PM · Comments (0)
Free ASP.NET Controls!

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

permalink 17 Jan 03 12:42 PM · Comments (0)
Sam Gentile: COM is the Culprit

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.

permalink 16 Jan 03 8:14 AM · Comments (5)
Karl Peterson Defends "VB.NOT" List

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."

permalink 15 Jan 03 4:25 PM · Comments (7)
VB: Second-Class Citizen?

Enumerating the advantages of .NET's Managed Extensions for C++ (MC++), Sam Gentile writes:

  • Leverages existing investments in C++ programming skills and legacy C++ code.
  • Porting unmanaged code to .NET: MC++ allows you to take existing unmanaged code and compile it to managed code (with the /clr compiler switch and IJW ["It Just Works"]).
  • Gives the ability to port code at one's own rate rather than re-write all at once.
  • Provides the easiest way to add .NET support to your existing native...Windows applications, by allowing you to bridge the gap between the two environments with as little work on your behalf as possible, and with the lowest performance penalty.

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.

permalink 14 Jan 03 12:13 PM · Comments (1)
ASP.NET Password Textbox Tip

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.

permalink 11 Jan 03 6:32 AM · Comments (2)
Quote of the Day

George Bernard Shaw: "The power of accurate observation is commonly called cynicism by those who have not got it."

permalink 11 Jan 03 6:26 AM · Comments (0)
Quest for the Perfect Handheld

My quest for the perfect handheld continues: T. Bryce Yehl writes:

Nothing meets your specs for $500. The freshly-announced Sony Cli
permalink 10 Jan 03 6:20 PM · Comments (0)
Quote of the Day

Berton Averre: "To err is dysfunctional, to forgive co-dependent."

permalink 10 Jan 03 3:02 AM · Comments (0)
Quote of the Day

Chris Sells: "'Aha! But what about unmanaged code? x86 can't be read like IL.' You're right. It is harder to disassemble x86 than IL, but not significantly so. The x86 disassembler tool vendors have been working for a lot longer on this problem and we've bred guys like Andrew Shulman and Matt Pietrek that dream in x86 and only translate to English as a convenience for their wives."

permalink  8 Jan 03 10:35 AM · Comments (0)
Attribute-Based Data Validation in .NET

This is very cool: Assign attributes (e.g., NotEmpty, MaxLength) to Class fields, then validate them with a single method call. Wish I'd thought of it!

permalink  7 Jan 03 12:07 PM · Comments (1)
Handheld Computer Wishlist

For the past two and a half years, I've been using a Palm Vx with a Minstrel V wireless modem. It's functional -- I enjoy having anywhere access to e-mail, instant messaging, yellow pages, Google, etc. -- but I must admit that newer devices have given me a bad case of PDA envy: I'd like a color screen, more memory, more bandwidth, a better browser, etc. But I can't find a device (or combination of devices) that provides everything I want for anywhere near the price I paid for my current setup (about $500). Here's my wishlist:

  • Small & light. As close to the size and weight of a Palm V as possible;
  • High-quality color screen. Minimum 320x320, 64K colors. Transflective preferred;
  • Wireless. Integrated Wi-Fi or Bluetooth, with the other available via expansion card (2.5G or 3G wireless data capability would be OK as an alternative to Bluetooth);
  • Full-featured Web browser. I currently use Handspring's Blazer, but it doesn't support JavaScript or do a very good job with "full-size" Web sites. I'd prefer the new Palm Browser (requires OS 5), a mobile version of Opera, or at a minimum, Pocket IE;
  • Reasonably priced. As close to $500 as possible.

Anyone care to recommend their favorite wireless handheld device(s)? Any manufacturers want to send me an eval unit? ;-)

permalink  6 Jan 03 4:57 PM · Comments (0)