Erann Gat: "How Common Lisp Sucks"

Steve Yegge's recent post on Lisp inspired Erann Gat to post “How Common Lisp Sucks” to comp.lang.lisp:

I am writing this because of the debate surrounding Steve Yegge's recent blog entries on Lisp. It is unfortunate that he made so many technical mistakes in his posts because they distract people from the fact that underneath all the errors he is actually making a valid point, that being that CL has very significant problems that are barriers to its adoption. (Some people think this is a feature, that having a few obstacles to overcome keeps out the rif raf. I suppose this is a defensible position, but I don't subscribe to it.)

[..]

Now, for those of you who wish to respond I ask you to keep in mind the following:

1. The details of my criticisms are mostly irrelevant. What matters is that CL is far from perfect, and that it has no mechanism for change. So don't bother picking a nit about one of my specific criticisms unless you wish to argue that CL is perfect and doesn't need to change.

2. I know a lot more about Lisp that Steve Yegge. I spent twenty years programming in Lisp for a living. I have authored some highly referenced papers on Lisp. I am far from the world's foremost expert, but I'm no newbie. If you think I'm wrong about a technical point you should think twice.

3. I do not hate Lisp. It is and has always been my favorite programming languages. My love for Lisp pretty much destroyed my career as a programmer. My motivation for criticising Lisp is not to convince people not to use it. It is to effect changes that I believe are necessary to get more people to use it. To quote Paul Graham, "It's not Lisp that sucks, it's Common Lisp that sucks." And actually, I would soften that somewhat: it's not Common Lisp that sucks, it's some parts of Common Lisp that suck. But make no mistake, some parts of Common Lisp really do suck, and unless they are fixed a lot of people -- myself included -- won't be able to use it even though they may want to really badly.

And the very first response:

Ron Garret <rNOSPA...@flownet.com> wrote:
> trying to use Lisp for e.g. writing a Web server is an incredibly
> painful experience compared to doing the same thing in e.g. Python.

I could list some web servers written in Common Lisp. And one of them was the first HTTP 1.1 compliant server and used by the W3C to debug the HTTP 1.1 reference implementation. And the youngest of the Common Lisp web servers was first released on 2005-12-31.

Army's UAV Field Manual

The Army's new manual for UAV systems has some interesting little bits of info.

Switch polarity? It really is like a video game.

The bigger UAVs actually have UHF/VHF radios on board, so even while you're flying it from your bunker in Nebraska you can talk to the air traffic controller as you land at Baghdad International Airport.

“Did you try pressing ‘autoland’? Try it again. OK, this time hold the remote higher—yep, over your head, that's right.”

Any multi-national force headquarters?

“My final offer is two Kit Kats and a Watchamacallit for the flying robotic death machine. Nope, sorry kid, but they don't make Bar None anymore.” Actually this would make a good kite recovery kit, too.

New Lisp FAQ

The beginnings of Peter Seibel's new Lisp FAQ look promising. (The staging FAQ might be worth checking out, too, especially if you would like to provide feedback on questions and answers as they're being developed.)

I'm glad that the driving force behind this is the guy who wrote a book about Lisp with the word “practical” in the title. There don't seem to be canonical FAQs these days quite in the same way there were 10 or 15 years ago, and there have been several failed attempts before this to create an updated Lisp FAQ, but I'm hoping this one succeeds.

Benefits of Quitting

Almost immediately after quitting Lemonodor, you may notice the following benefits:

Lots of people don't make it to the magic 21 day mark, though.

HMPassphrase 1.1

I fixed a bug in my Movable Type anti-spam plugin, HMPassphrase (previous post) that prevented the junk scoring mode from working.

I had a few people email me to say it wasn't working for them, but it was kind of hard to debug until I hand-patched a bug in Movable Type itself that caused it to emit useless error messages when plugins failed.

HMPassphrase is the most effective anti-spam plugin for Movable Type that I know of.

Evolution Robotics and WowWee on Slashdot

Oh my god, I know System 370 assembler.

As an update to my earlier post, David Cohen, LA Lisper, let me know that slashdot posted about Evolution's partnership with Wowwee.

The thread is terrible, except for a followup from the original poster, a Caltech grad student with an interest in computer vision, in which he gives a nice short description of the actual technology that WowWee will be using.

The first bit of technology Evolution Robotics will probably be contributing is their ViPR [evolution.com] (Visual Pattern Recognition) tech, which allows for real-time recognition of objects in the environment. It's really quite impressive to see it in action -- it can learn how an object looks using just a single training example, has a high recognition rate, is resilient to occlusion/rotation/scale, and can operate at 15fps on an ordinary computer. It works by efficiently extracting a few hundred SIFT [wikipedia.org] (scale-invariant feature transform) features from an image, and then learns what affine arrangement of them indicate an object. A downloadable demo is available on the ViPR page.

(Apparently the slashdot editors cut all that interesting stuff from the original submission because it didn't have anything to do with beer. Way to stay interesting, guys.)

“I was a homeless teenage girl living in the back alleys of Cupertino in 1982”

I wish I had Patrick Farley's dreams:

I was a homeless teenage girl living in the back alleys of Cupertino in 1982. A sleazy computer programmer (Jeff Bridges' character from the movie Tron, exhibiting a side of him we didn't see in the movie) kidnapped me and used me as his first experiment in the “digitizing of people.”

It'd be nice if I could draw like that, too.

(Google currently has one hit for “sleazy computer programmer”; can you guess what it references?)

SBCL Wins

Tagged “white men” and “lots of them”.

I think SBCL 0.9.11, from March 26, 2006, is the first offical release of a Common Lisp with native support for OS X on Intel (though the support is labeled “experimental”).

Peter Norvig on Google's Hiring Practices

Peter Norvig on Google's approach to hiring: “You can see how hire-above-the-min leads to a precipitous drop in skill level; one we've been able to avoid.”

I don't think I've ever seen a quantitative comparison of hiring strategies before. Of course it's a lot easier if it's possible to quantify a candidate's quality.

(Gavin: “With all the stats available, it would be cool if google could actually point to the person/hire who brought the overall intelligence down.”)

I like to interview programmer candidates. Maybe it's like having a standard geeky conversation except that the context demands that both interviewer and interviewee have extra special focus on the conversation and try harder than usual to be smart (except that there's also pressure not to be an arrogant asshole—take that, nerd!). Ever since Will gave me a neat programming exercise as part of the hiring process at Intell/Agent, I've been a big fan of using take-home programming assignments as the best way to get a feel for the person's grasp of programming. The exercise I use is actually an exact copy of the one Will gave me in 1995 or so, including the Lisp data files. For the past few years I've mostly been involved in hiring C++ programmers, so I throw in some C++ code to read the data.

The exercise takes a good programmer somewhere around 5 or 6 hours, which I think is substantial enough to get a good feel for the candidate's design skills as well as their raw coding ability. The instructions for the assignment and the data include some minor inconsistencies and areas of vagueness which were not originally intended, but which have explicitly not been fixed, so I get to see how people deal with that too (emailing me with questions is a great response, as just one example). HR departments have, at times, not wanted to ask candidates to spend so much effort and time on the exercise, which I think is pretty misguided. It's too hard to judge someone's coding ability without seeing significant chunks of code, and it's not common for people to have a significant chunk of code that isn't legally encumbered in some way that prevents them from showing it to other people (working on an open source project might be one way to solve this problem, but I wonder if there are other good solutions, too).

I used to ask candidates what they don't like about their favorite programming languages, but too often people didn't have any good answers. Which kind of blows my mind, and depressed me enough to create a pain barrier to even asking. Don't forget, every language sucks, man, and if you don't realize that you better start wondering why not. As Steve Yegge says,

The very best Ruby programmers, as with any language, are the ones who can think outside Ruby; i.e., they know its limitations as well as its strengths. It’s extremely uncommon for average programmers or language novices to be able to speak intelligently about their favorite language’s weaknesses, because the language books and tutorials rarely focus on the weaknesses.

One of these days I'll finish my “20 True Reasons Lisp Sucks” post.

Trac Syntax Coloring for Lisp

I've been experimenting with Trac, which integrates a wiki with simple bug tracking and subversion repository browing.

Trac supports syntax coloring of any programming language that either GNU Enscript or SilverCity support, which seems to include every single thing other than Common Lisp. Sometimes I use Lisp, so this annoyed me. I used XML-RPC to glue Brian Mastenbrook's colorize (which is used by the paste service at paste.lisp.org) to Trac.

The result:

colorization-server.tar.gz has the Lisp side of the XML-RPC glue, a small patch to colorize to add the option of not doing fancy paren matching (which didn't fit into Trac's output very well) and a little SBCL-specific startup script.

trac-lisp.py is the Python/Trac side glue. Drop it into Trac's mimeview directory, rename it to lisp.py, change the COLORIZER_URL to point to the machine you're going to run the colorization server on, add a 'lisp':'text/x-lisp' entry to MIME_MAP in mimeview/api.py, add 'trac.mimeview.lisp' to the default_components in db_default.py.

Copy the CSS that's in colorize's *coloring-css* variable into a file called lisp.css and put that file in Trac's htdocs/css directory. Start up a lisp running the colorization server, restart Trac and you're set.

I put in a small LRU cache to avoid hitting the XML-RPC server every single time Trac needs to render a page containing Lisp source code, but even with cache misses the XML-RPC roundtrip is barely noticeable. I use Trac in standalone mode, which is probably the only reason the caching works—if you use CGI mode, you're on your own.

Of course, trac-lisp.py could easily be modified to be a more general interface between Trac and colorize, with support for any language colorize understands.

Later: I didn't realize Trac had syntax to turn on language-specific coloring of code blocks on wiki pages, in which case my caching would do the bad thing. I've fixed the code.