The Cafes

In an illuminating post (formerly at http://www.jroller.com/scolebourne/ but the domain was taken over by spammers) Stephen Colebourne demonstrates exactly why operator overloading is a bad idea. Now mind, you, he doesn’t think that’s what he’s doing. He actually believes he’s making the case for operator overloading. However the mistakes he makes are exactly the sort of mistakes likely to be made by almost anyone without at least an undergraduate degree in mathematics who tries to overload +, -, *, and especially /. If you don’t know the difference between a group, a ring, and a field, you have no business overloading operators.

Now I’m not saying that one has to take a course in abstract algebra before you can be a competent programmer. You don’t as long as the language you program in doesn’t support operator overloading (or as long as you’re wise enough not to use it if it does). However since most programmers are didn’t get beyond ODEs in college (if indeed they got that far–some of my comp sci friends struggled mightily with calculus and had to retake it repeatedly), one can’t responsibly design a language that requires mathematical sophistication in the 99th percentile for proper use. Probably one should stop with high school algebra.

Features that are guaranteed to be misused should be eliminated. In the specific case of operator overloading, I daresay, the feature will be misused far more often than it will be used properly. There are only about a dozen or so cases where operator overloading is called for, and only one is even remotely common. That one is complex arithmetic, and this single use case could be better handled by adding a complex type to the language. Arguably BigDecimal and BigInteger are a second and a third. The remaining cases are so incredibly esoteric that only a mathematician or an occasional physicist could possibly be interested in them. Can anyone name even one?

The following is a possible new chapter to be added to Refactoring HTML in the accessibility section. I’m throwing this in fairly late in the editing process, so I’d appreciate any thoughts, comments, or criticisms you might have about this. In particular, I’d appreciate any cases you can think of where autocomplete is not appropriate.

For what it’s worth, I’ve pretty well convinced myself that usernames and passwords are not such a case. That is, autocompleting usernames and passwords definitely increases accessibility and usually increases security. I don’t intend to explain why it improves security in this chapter, but if anyone wants to disagree with that, I’ll explain why in the comments.

Remove autocomplete=”off” attributes where appropriate.

<form action="/login" method="post" autocomplete="off">

<p><label>E-Mail Address: 
<input type="text" name="e1" autocomplete="off"/>
</label></p>

<p><label>Password: 
<input type="password" name="p1"  />
</label></p>

<input type="submit" title="Login" autocomplete="off"/>

</form>

<form action="/login" method="post" autocomplete="off">

<p><label>E-Mail Address: 
<input type="text" name="e1" />
</label></p>

<p><label>Password: 
<input type="password" name="p1"  />
</label></p>

<input type="submit" title="Register" />

</form>

Read the rest of this entry »

I missed a couple of important e-mails while I was in Norway this past week. Although I was checking my metalab.unc.edu e-mail at least once a day, several important responses somehow went to my GMail address instead, which I was not checking. I found them when I got home and opened my Gmail account yesterday.

At first I was perplexed, because I do not usually set my return address to GMail. Then I remembered that on the road I was using the GMail SMTP server to send, because the Speakeasy server I normally use only works from my local area network behind my router. Could GMail be rewriting my headers? So I did some experiments.
Read the rest of this entry »

I am getting quite tired of Mac OS X locking itself into the spinning beach ball of death due to failing hardware. In the last year or so I’ve had two LaCie hard drives go out on me, and a third seems to be going now. In each case, the Mac got thrown into a completely confused funk because the drive didn’t respond quickly enough or at all. Note that these drives were used strictly used as external backup device. They didn’t hold any operating system or application files.

Haven’t we learned by now that I/O is an unreliable operation, and that you should never assume that any read call will succeed, or will return data in the format you want? That’s true whether you’re talking about files or FireWire packets. Furthermore, critical components like the Finder should not block on synchronous I/O. Any I/O needs they have should be serviced asynchronously.

It’s hard to take the Mac seriously as a reliable server platform when it’s so easily brought to its knees by one misbehaving hard drive.
Read the rest of this entry »

For the last couple of months I’ve been working on Windows as my main desktop during the workday (not my personal choice, but I can live with it.), and that’s caused me to notice a few things I haven’t noticed before, especially in contrast to the Mac style of managing windows. I’ve task switched between Mac and Windows before–for several years in the late 90s I did all my development and book writing on Windows and all my e-mail and Internet on the Mac–but this is the first time I’ve had the chance to compare the two environments with multiple monitors, and that’s made some difference in my take on matters. Practices that work well on a single monitor system don’t work as well on multimonitor system and vice versa. After playing with this for a while, I’m starting to think that the Windows approach works better for multiple, small monitors and the Mac approach works better for a single, widescreen monitor.

To summarize, here are the critical differences between the two platforms. These are worth keeping in mind when you’re designing a cross-platform application such as Firefox or Limewire, or any web site.
Read the rest of this entry »