The CRU Files

This is not a political blog so I have nothing to say here about the ethics of the hackers who broke into the CRU network, downloaded 60–70 megs of files and emails, and posted them on the Internet. I also have nothing to say about whether Anthropogenic Global Warming is real or not because (1) I don't have the necessary scientific knowledge to make an informed decision, and (2) again, this is not a political blog and the AGW debate has, it seems to me, devolved into a political question. Finally, we should be clear that the files and emails have not been verified to be authentic although several have apparently been corroborated and no one, to my knowledge, has disputed the authenticity of any of the files or emails.

What I want to discuss is the shocking betrayal of science and the search for truth that these emails reveal. If the emails are genuine then their authors have forfeited any right to call themselves “scientists.” Rather, they are revealed as agenda driven politicos and particularly nasty and small minded ones at that.

The details are all over the Internet (see here or here for example) so I won't bother rehashing them but it's all there: gloating about the death of a rival, cooking the books on their data and then refusing to release raw data so that it could be verified, conspiring to evade (at least) the spirit of the UK Freedom of Information act, deleting incriminating emails, plotting to prevent skeptics from getting published, and more.

Again, it's possible that some of the more incriminating emails are fabrications, although no one is saying this, and they may well be taken out of context, but if they turn out to be genuine then the actions of the principals are shameful and they should be removed from their positions and no longer be treated as members of the scientific community.

Help! Help! My brain is being rewired

I usually ignore twaddle such as this, but really, enough is enough. The new Luddites are at it again wailing about how spell checkers and contact lists are destroying our ability to remember and process details. I'm old enough to remember the exact same arguments being used against calculators: “Oh my gosh, pretty soon people won't be able to add two numbers.”

And you know what else? Some college students actually text each other during lectures. One wonders why their minds are wandering. There's even a line about “BART riders reaching furtively into their pockets thinking their iPhone has vibrated—even if it hasn't.” The horror, the horror!

The article goes on and on like this and so could I, but why bother? We've heard it all before and in a few years no one will remember or care about these doomsday predictions. Go read the article if you must, but it will probably be a better use of your time to check out your favorite Twitter feed.

UPDATE: Sadly, this sort of nonsense is nothing new.

Compiling DSLs

Recently I had occasion to revisit this post from Peter Seibel's blog about compiling queries in Lisp. It's a cliche in the Lisp world that “if you're using eval, you're doing something wrong.” A more helpful formulation is, “if you're using eval, you should probably rewrite your code to use macros instead.” This is generally good advice—see here for some contrary examples—but it does not tell the whole story; that's where Seibel's post comes in.

Seibel considers the problem of a DSL for performing simple keyword queries on a block of text. He gives the example

(or
 (and "space" "mission")
 (and (or "moon" "lunar") "landing"))

which tests whether the text contains the words space and mission, or moon and landing, or lunar and landing. It's pretty easy to translate the above into a Lisp expression such as

(or
 (and (word-in-string-p "space" text)
      (word-in-string-p "mission" text))
 (and
   (or (word-in-string-p "moon" text)
       (word-in-string-p "lunar" text))
   (word-in-string-p "landing" text)))

where word-in-string-p returns t if the first argument is a substring of the second and nil otherwise.

The next problem is to evaluate this expression. The naive way to do this is to pass it to eval, and you know what? The earth will still be orbiting the sun if you do. But Seibel goes on to show us a better way and to illustrate why the prejudice against eval is usually well-founded.

Instead of invoking eval, we turn the above expression into a function

(lambda (#:G1)
 (or
   (and (word-in-string-p "space" #:G1)
        (word-in-string-p "mission" #:G1))
   (and
     (or (word-in-string-p "moon" #:G1)
         (word-in-string-p "lunar" #:G1))
     (word-in-string-p "landing" #:G1))))

where the #:G1 is a gensym'd symbol. Now an immediate advantage of

this is that we have a function that we can pass to some other function or otherwise use in any of the ways that Lisp's first class functions can be used. This means that it can be called over and over again on a series of text blocks (the original problem is posed in terms of a database query). The key here is that we can take this function and compile it using compile-expression so that (for systems that support native compilation) we have a fast implementation compiled to machine language.

Notice that we're not talking about much more work than using eval. We merely have to wrap the code in the lambda form and then call compile-expression rather than eval. Seibel's got all the code in the post I linked above, so you should go take a look at it.

MobileOrg!

The remote Org mode application for the iPhone that I've written about previously is finally available at the AppStore. I've downloaded the app to my iPhone, but still have to set up the WebDAV server for syncing data to and from the iPhone. I'll write more when I have things fully configured. In the mean time, get over to the MobileOrg Website and marvel at Org mode on the go.

Tail Calls

I saw this post from Tim Bray at ongoing the other day and thought it was pretty silly. I was going to comment on it but decided that Bray is a serious and knowledgeable guy who is entitled to his opinion even if anyone with functional programming experience might find it snort-worthy.

Along comes Ezra Cooper at Ezra's Research with a response to Bray. It's too good to pass up and says everything that I wanted to say only better. He also points out that “tail-call optimization” is a misnomer. I liked that because the tail-call optimization nonsense has always annoyed me.

Cooper's blog has a lot of juicy content, so it's worth taking a look at even if you have no interest in the tail-call contretemps.