Now that lots of people are piling onto the Python bandwagon, it's amusing that many of them don't realize that they are using a language which has many similarities to Lisp. So as a service to both language communities, I'm posting references to a pair of pages written by Peter Norvig. The first is called Python for Lisp Programmers, and tries to help Lisp hackers map concepts they know on to Python. It also works in the reverse direction. There are also a few microbenchmarks, as well as a bunch of things that will trip up Lispers coming to Python.

The second page is called Retrospective on Paradigms of AI Programming and includes reflection on whether or not Lisp is still unique.

Those who commented on the Lunacy post left behind some other interesting tidbits. I've taken some of the links and reproduced them here. One of the things that interested me about Lunacy was the possibility of turning the decades of Lisp compiler research towards improving the performance of Python. Unfortunately, this pair of messages from Matthias Felleisen makes me a little less optimistic that this will be possible. The standard response to performance criticisms of Python is that you can always rewrite your code in C. Now, this is true, but I'd prefer not to rewrite working code if I can avoid it.

Bagley's Computer Language Shootout has some interesting micro benchmark results. Unfortunately, it hasn't been updated, so some of the numbers are out of date. If someone is looking for a worthy project to take on, reviving this would be great. It would be wonderful to keep it up as the various language communities improve their programs and implementations.

Here's Eric Raymond's account of how he discovered Python.

Lastly, there's Denys Duchier's on article continuations, which shows how to to continuations in Python by rewriting programs in continuation passing style. This is a good example for Python folks who are wondering what the big deal about continuations is.

1. Disallow connections to port 25 from inside the firewall
This is long overdue since lots of e-mail worms like to install their own SMTP server. The only way you're going out via SMTP is via our SMTP server.
2. Enable SMTP AUTH via SASL
Only authorized users should be able to use our SMTP server. This turned out to be a major headache since postfix on Debian runs chrooted, and was having trouble talking to saslauthd's socket. I ultimately gave up on using saslauthd and hacked around it using the sasldb method of checking passwords. But even that took me way too long to figure out. It would be nice if the Debian maintainers for postfix or SASL would include some documentation on how to do SASL based SMTP auth inside the postfix chroot environment (using SASL2).
3. Enable TLS support for postfix
I've grabbed the postfix-tls deb and installed. Next I need to generate the certificates. The problem is that I already have certifications for Apache and UW-IMAP (although I'm probably going to junk that in favor of Dovecot). I also want the SMTP TLS to require a client certificate (yes, I'm paranoid). So I pretty much need to setup my own CA to issue client and server certificates. What I'm not clear about is whether I need a server cert for each service (www, imaps, smtp) that I plan to offer -- I only have a single IP address. There's also the small matter of which of the many different HOWTO's or documents to follow to generate the certificates properly. Last time I used the makecert.sh that comes with Debian's modssl.