VIlisp

What got me to try Emacs/SLIME was the ability to send code from the editor to the REPL. There are many other benefits, but that was the big one for me. Thanks to VIlisp, I can get the functionality I want with Vim.

The documentation is very good, so I'll just outline how I integrated it into my environment. Although it has only been tested with CMUCL, it does work out of the box with SBCL. However, I noticed that the REPL wasn't always quitting properly, so I changed $QUIT in funnel.pl to "(quit)" and it works fine now. On OS X, I changed the shebang line to use the Perl from macports; there's nothing wrong with the Perl that comes with the OS, I just didn't feel like adding packages with CPAN.

I placed VIlisp.vim and lisp-thesaurus in ~/.vim/VIlisp-2.3 and added the following line to my .vimrc:

autocmd BufRead,BufNewFile *.lisp so $HOME/.vim/VIlisp-2.3/VIlisp.vim

I put funnel.pl in my path, and placed the following alias for SBCL in my .bashrc:

alias sbcl="PERL_RL=gnu funnel.pl $HOME/.lisp-pipe sbcl"

A nice side-effect of using funnel.pl is that your REPL will be "wrapped" by the GNU Readline library, so you'll get the benefit of command history and other line editing tools. Many programs use Readline, so it's worth being familiar with the user interface.

Perl: Officially Unparseable

I came across a formal proof that Perl cannot be parsed. It is an interesting read if you're into computing theory and programming languages. I hadn't considered the dynamic nature of Perl's grammar before, or the fact that it is impossible to parse unless you execute it.

KDE 4.0

Ars Technica has a great review of KDE 4.0.

I installed the Kubuntu/KDE4 Live CD on my laptop (using Parallels), and overall I agree with the review; it's a great step forward, but not quite ready for everybody. I've ben a GNOME guy for a lot of years, but I think I'll be switching to KDE in the near future.

I'm having some trouble with screen repainting (it doesn't), but that's most likely a Parallels/Xorg problem. Otherwise, provided that you follow the directions for Ubutntu 7.10 as a Guest OS, it works fine.

OLPC

The OLPC "Give One, Get One" program has been extended through December 31^st! I've been really tempted to snap one up, given that it's a cool machine in particular, and a cool idea in general. Now I have more time to hem and haw over it.

There are a lot of really neat software being written for the OLPC... Check out wiki.laptop.org and dev.laptop.org for details on what's out there.

Common Lisp and Vim

Don't get me wrong, there's a lot to be said for Emacs and SLIME. The fact that so many Lispers use it is hardly a coincidence — it makes for a very powerful and extensible development environment. I have used the Emacs/SLIME combination long enough to know the following:

• It's very nice.
• I don't like it.
• No, I'm not trying to start a flame war.
  

Now, opinions change over time, and perhaps mine will too. I think the barrier to acceptance is the fact that my current setup with gVim and SBCL is good enough that I can't justify spending the time to become an efficient Emacs user. It turns out that Rob Warnock can't either, and he's a guy who really knows where his towel is.

I came across this message posted on comp.lang.lisp, and ended up writing my own version of the LOAD* function Rob talks about. It's really a very handy tool, and makes it a lot easier to work with the REPL and your editor of choice. I keep LOAD* and a few other frequently-used tools loaded in a custom core file, which I create using a file called make-core.lisp. To create and use a core file, do the following:

$ sbcl --load make-core.lisp
$ sbcl --core ./sbcl.core

Bear in mind that LOAD* is rather naive and hasn't been tested much, so if there are any suggestions for improvement I'd be glad to hear them.

OpenSocial

There has been a lot of chatter lately about OpenSocial. Tim O'Reilly nicely summarizes my biggest problem with it:

... If all OpenSocial does is allow developers to port their applications more easily from one social network to another, that's a big win for the developer, as they get to shop their application to users of every participating social network. But it provides little incremental value to the user, the real target. We don't want to have the same application on multiple social networks. We want applications that can use data from multiple social networks.

OpenSocial needs to be more than just a middleware for application development. The web is the platform, not Facebook or MySpace or anything else, and what's really needed are applications that share and leverage all of the information we've put out there. There is a ton redundant data on the web, and it's not limited to just social networks. For example, both Amazon.com and Netflix have recommendation systems. If I want accurate results from both, I have to rate the same movies twice on both sites, and keep both lists up to date. And if I want to list my favorite movies in my Facebook profile? Yep, I have to enter them in again. I'm barely inclined to do this activity once, let alone three times, and that's just for movies! If I want to add books, music, video games, etc. then the dance continues ad nauseam.

One solution is to create a common user database, where users can grant participating applications access to whatever parts of their profile they want. This would allow applications to share data, and it provides users with a single account for all of the sites they visit. There are a million pros, cons, and technical challenges to this idea, but everything else seems to fall short.

memcached & Common Lisp

My friend Sean and I are working on a web site written mainly in Common Lisp. Since there will be a lot of database reads, we are planning on using memcached to reduce the load. I looked around and was glad to find CL-MEMCACHED, but in the end I decided to write my own client. Sometimes you just have to reinvent the wheel when you're new to a language, and I'd rather make my mistakes early on in the development process. I figure that since I know exactly how to write a memcached client in C, Perl, and Python, doing it in Common Lisp will allow me to focus on one thing (using the language correctly) rather than two (using the language and designing new code).

I recently read Lamport, Shostak, and Pease's paper on the Byzantine Generals' Problem, and it gave me an idea on how to improve test coverage. The memcached client must be tolerant of a server going down — not too tolerant, mind you — and one way to simulate this is to write a dummy server who takes the role of a traitorous lieutenant. When issued a command, this server could

• send a valid (but fake) reply
• send a valid error message
  
• send garbage
• close the connection

I want to be sure that the library can handle errors appropriately. Common Lisp has a very powerful condition mechanism — much more versatile than exceptions — and I would like to make the most of it.