0207: Letters

Thanks to Scott Meyer who kindly pointed out that in my article "Disk Thrashing & the Pitfalls of Virtual Memory" (DDJ, May 2002) I mistakenly implied that indexed access to a deque is done through a directory tree, which would lead to logarithmic times. Instead, it is done through constant-time index arithmetic. As always, he's right! This, by the way, makes my argument for using deques for large datasets even stronger.

Bartosz Milewski
bartosz@relisoft.com

Dear DDJ,

In the May 2002 Java Q&A, Tal Cohen discussed a way to implement the equals() method, which continues to work even after subclassing. It was very insightful, as I had never considered the situations he used to make his case (where the normal unidirectional equals fails the validation checks). I've since implemented the method he discussed, but there was one error. In Listing Five, the last method should read as follows:

public boolean equals(Object o) {<br>
  if(!(o instanceof Point))<br>
    return false;<br>
       return (this.blindlyEquals(0) &&<br> ((Point)o).blindlyEquals(this));<br>
}</p>

Without the typecast, the code yields a compile error.

Jeff Hubbach
jeff@hubbach.com

Dear DDJ,

Michael Mitzenmacher's use of multiple hash functions ("Good Hash Tables & Multiple Hash Functions," DDJ, May 2002) was interesting. However, I must take exception to his cavalier suggestion that discarding data be considered a legitimate approach to handling bucket overflow.

First, hashing algorithms should expect bucket overflow and handle it gracefully. The cost of decent handling is quite small. A simple and robust approach is to move the key to the next not-yet-full bucket (mod m). The lookup function then searches buckets accordingly.

Second, does anyone really believe IP addresses arriving at a router form a uniform distribution? Certainly not. And with error retries due to dropped packets, the algorithm belies such an assumption. The failure probability should be considered "very small," but the order of magnitude is questionable. As a practical matter, miniscule odds represent events that occur during acceptance testing or when the stakes are very large.

Third, built-in unreliability in embedded systems is likely to be silent; designers are not going to tell their supervisor the system may fail. And such information would never make it past marketing. Users are the victims of the bad design.

There is no cost tradeoff presented; this appears to be strictly a question of good design and professionalism versus the alternatives.

Richard Mickelsen
rich.mickelsen@ctg.com

Dear DDJ,

The Code Red virus has shown once again that computer security is stuck in a primitive rut. While virus scanners do good business hobbling along checking for last week's viruses, most gurus only say users should be educated not to start the "programs" (in the broadest sense) they are sent. As so often, the users' wishes are reasonable, and Linux, Windows, and other operating systems and mailers should satisfy them, in spite of what experts say.

If someone sends me what might be an amusing program, I want to try it out, and I should be able to do so in safety. What is needed is a way of starting any program in a sort of padded cell, where it can show me things, ask me questions, and have a little space to work in. It should, however, not be allowed to change anything on my computer, nor to mail or print, without my permission, which could be asked as the need arises or in advance. In practice, most programs are allowed to do anything I am.

In fact, the padded cell is an old idea, and any computer [that] runs Java properly could provide a reasonable one, though asking permission is less common. My advice is: By all means, click on all your attachments, but first get a proper e-mail system — a few Linux users will be able to make themselves one, most of the rest are at the mercy of Microsoft or the Open Source movement.

You would admittedly not lock an unknown plumber in a padded cell, but one would normally keep an eye on him; most systems give him the keys to the safe and turn their backs.

Patrick Traill
Patrick.Traill@soz.pinkroccade.nl

Dear DDJ,

I believe that the language critics gave several comments at the Lightweight Languages Workshop (see "The MIT Lightweight Languages Workshop," by Eugene Kim, DDJ, February 2002) that reflect a view that "interesting languages" are somehow desirable. This implicit assumption is by no means well founded. If the goal of the language is to be lightweight, then indeed, simplicity is a feature! Thus, the goal of a lightweight language designer may be to minimize syntax, while enabling the needed features of a language. So, if a feature can be implemented with semantics (design patterns or API, for instance), then it should be removed as a syntactic language feature.

Do I buy a hammer because it is interesting? Is a screw driver any less useful because it is a boring tool? What we leave out of a language is just as important a design decision as what we put into a language.

Yes, we do need people to develop interesting tools! We shape our tools, and thereafter, our tools shape us. But design is an iterative process that is guided by constraints and goals. And the goals are derived from the language's intended roles.

If your role is to explore a new frontier in language design, then interesting is a good feature. Otherwise, more pragmatic motivations should probably govern your selection of design goals.

Douglas Lyon
Lyon@DocJava.com

Dear DDJ,

One piece of info should be upfront in all language descriptions — are they line oriented? Ruby is presented as if it isn't — which is good; is that the case? As a practical matter this can be really important; one of the continuing annoyances of even the giant Visual Basic is those lines. And of course many of the UNIX little languages are line oriented.

My theory is that UNIX/Linux has all these little languages because they never had Phillippe Kahn and Turbo Pascal; it's still so awful to compile/debug C in UNIX that people constantly turn to scripts and so on, while in CP/M, MS-DOS, and Windows, similar yearnings were crushed in the face of the incredibly convenient Turbo languages.

J.G. Owen
owen_labs@bigfoot.com