Hall of Shame

One of my pet peeves is Web sites that ask for a credit card number and then refuse to accept spaces despite the facts that the spaces occur on the card and that it's significantly more difficult to enter them correctly without the spaces. Similar remarks apply to phone numbers and doubtless others. There's no reason for this other than programmer laziness—or perhaps just cluelessness—and, really, a lack of respect for their users. Why any company would tolerate this is a mystery, but that companies such as Microsoft, Adobe, TurboTax Software, and Apple tolerate it is just inexcusable.

Comes now Steve Friedl in a fit of righteous anger with his No Dashes or Spaces Hall of Shame. As Steve demonstrates, it's often easier to do the right thing than it is to add an instruction line specifying no spaces or dashes. The best part of his post is a long list (with examples) of offenses by major companies that really should know better. Steve is still accepting nominations, so by all means send him any examples that are inflicted upon you. Maybe public shaming will put an end to this disgraceful practice.

Russ Cox on Regular Expressions

I've long been a fan of Russ Cox's 2007 paper Regular Expressions Can Be Simple and Fast. In it he explained why many of the common regular expression libraries in languages such as Perl, Python, Java, PHP, and others can exhibit exponential behavior, while the libraries associated with the Unix tools, such as egrep and awk, have provably linear performance on all inputs. Oddly enough, the O(1) Unix regular expression tools are based on an algorithm invented by Ken Thompson in 1968 for the QED editor, while the (potentially) O(2ⁿ) implementations used by PERL et al. were based on Henry Spencer's much later Regular Expression Library.

I've just discovered that Russ wrote two other papers in the series: Regular Expression Matching: the Virtual Machine Approach (2009) and Regular Expression Matching in the Wild (2010). The first of these discusses various virtual machine implementations for regular expressions. The first paper discussed an implementation based on Thompson's ideas but it worked by converting the regular expression into an explicit nondeterministic finite automaton (NFA) and executing that. The implementations in the second paper are closer to Thompson's actual implementation, which generated IBM 7094 machine code and executed it directly. Cox shows that nevertheless the two implementations are essentially the same and that each is revealing in its own way. This is a wonderful paper—in some ways better than the first—and is really a must read.

The final paper discusses the RE2 regular expression system used at Google and now released as an open source project. RE2 is based on the ideas discussed in the first two papers but is a real implementation meant for industrial strength applications.

If you've ever wondered how regular expressions work or even have the slightest interest in them, NFAs, or just enjoy excellent software engineering, you should definitely give these papers a read. You won't be sorry.

A New Org-mode Talk

On February 8, 2010, Carsten Dominik gave a talk about org-mode at the Max Plank Institute for Neurological Research. This talk is a bit different from the one he gave at Google in that the emphasis is more on how he uses org-mode than on the actual mechanics of its use.

It's a great talk and make a nice companion to Bernt Hansen's excellent writeup on how he uses org-mode to run his company and life. The talk is well worth 53 minutes of your time.

Diffie, Hellman, and Merkle get the Hamming Medal

Whitfield Diffie, Martin Hellman, and Ralph Merkle are the 2010 IEEE Richard W. Hamming Medalists. The men won the medal for their work in public key cryptography—in particular for the Diffie-Hellman key exchange algorithm. Although less well known (as an artifact of publication scheduling) Merkle is considered a co-inventor of the algorithm.

I've always considered the Diffie-Hellman algorithm one of the great hacks in cryptography. It's very easy to understand, yet accomplishes the seemingly impossible by allowing two parties to agree on a secret key even though the negotiation is carried out in public. Interestingly, Merkle was trying to prove that it was impossible to do so when he developed the method as an undergraduate at Berkeley. Diffie and Hellman developed the method independently at Stanford.

Congratulations to all three.

Apple Hatred

The other day I was reading a friend's post about the Apple iPad and was struck by the comments. Many of them rehashed complaints about Apple products going back to MacOS 6 and cited unhappiness with the way these ancient systems worked as reason enough not to want an iPad. Others noted that they haven't liked any Apple product yet so of course they won't like the iPad either.

Today, trawling through Hacker News I see a bunch of articles about how horrible the iPhone is and how the authors positively, absolutely, wouldn't own one and, anyway, Apple sucks. One author writes disparagingly and at length about The iPhone obsession. Even the The Guardian got in on that one.

What interests me about these articles is that people who neither own nor use Apple products feel nonetheless compelled to obsess over them; indeed to obsess over them in public and in print. Yes, there are Apple fan-boys who can also be annoying, but at least they actually use the devices they are commenting on.

Don't like Apple products? Fine, I hope you find happiness elsewhere. Just don't expect me to care about your obsessions.

Emacs support for Scheme

Here's a nice summary of the various Emacs packages supporting Scheme from Alex Ott. The list includes general packages covering all Scheme implementations as well as packages specific to a single implementation, such as GDS for Guile and Xscheme for MIT Scheme.

Sadly, only Kawa and MIT Scheme have SLIME support.

The New Luddites, Part 3

The New Luddites have stuck their heads up again. This time it's the Economist whining about information overload in mobile GPS units. The correspondent is, he assures us, a longtime lover and user of maps, but somehow all those curvy lines on the display just overwhelm him. He compensates by dimming the display and just listening to the spoken directions. The barely-below-the-surface theme is that maps have no business being digitized anyway. After all, people have been getting along with paper maps for centuries.

Is this a problem anyone else has? The GPS display seems perfectly clear and informative to me, even without a lifetime love affair with maps. I just don't get it. Every once in a while you glance at the display to see how far it is to your next waypoint. Actually, you don't even have to do that because the GPS unit will warn you in plenty of time.

If the GPS unit overwhelms you, turn the damn thing off and use paper maps or your memory or whatever. Just leave the rest of us in peace. Please.

Proof That Book Publishers Learned Nothing from the Music and Movie Industries

Rewire Redux

A few posts ago I ranted about gave a carefully reasoned analysis of an article about how computers were destroying our brains or something. Now Cory Doctorow makes the same points in a slightly different context. He even mentions the old “calculators are destroying our ability to do math” silliness and explains why that argument is not just wrong but the actually misses the point that by liberating us from spending years developing a facility to do arithmetic in our heads we are free to learn to think about mathematics at a more abstract and useful level.

The link takes you to an 11 minute video interview of Doctorow that is well worth your time. Doctorow's main thesis is that technology frees us from worrying about many of the mechanical details of writing and mathematics and allows us to concentrate on their more important aspects.

Another Slime for Vim

Over at Jonathan's Techno-tales Jonathan Palardy writes about using Vim for Lisp programming. His idea is to emulate some of the Slime functionality by using Gnu Screen to help communicate between the REPL and the Vim editing buffer. He's written a Vim plugin to automate the process but you don't need that to try the process out.

It's a nice hack but doesn't have anywhere near the functionality of Slime. Still, if you're a committed Vim user and program in Lisp this may be a good solution for you. The same technique should work with any language that uses a REPL-like mechanism.