Highly Opinionated Guide To Lisp

Pascal Costanza's "Highly Opinionated Guide to Lisp" (seen on the info-mcl mailing list) is an excellent introduction to lisp that focuses on teaching newbies about the context and culture of lisp as opposed to the definitions of car and cdr. This is the sort of resource I find myself more interested in when I learn a language--a guide to important features from the perspective of someone who is new to the language.

Since Pascal is not neccessarily a lisp expert yet I won't be surprised if people find things in his introduction that could be improved, but it looks pretty solid to me.

Nathan Froyd

Nathan Froyd has a thoughtful weblog with an occasional mention of common lisp. The software behind the weblog is written in lisp too.

Sunset Junction

This weekend the Sunset Junction street fair took place on Sunset Blvd., right outside my apartment. Like, right outside. There was no way I could not hear Chaka Khan tonight, on the stage a couple hundred feet away.

The coolest thing about it was the people watching. This article on the fair asks

Where else can you find tattooed and pierced skin-heads, Latino immigrant families with young children, hardcore gay leather "daddies", elderly retirees, "cholo" gang members, and liberal entertainment industry yuppies peacefully coexisting in the same area, much less all coming together to throw a party?

But that's not even half of it. Punks, geeks, girls made up like the Andrews Sisters hugging hipster guys that looked authentically homeless. All those subcultures, thrown together. And with three stages plus three or four record and clothes shops with DJs in front, pretty much anyone could find some music they liked. I thought it was really cool that I could walk 300 yards from my apartment and see Sonic Youth play.

I also like the fact that the variety of people at the fair actually matches pretty closely the makeup of my neighborhood.

New Version of Corman Lisp Coming Soon

Roger Corman is saying that Corman Lisp 2.0 should be out in the next week or two. [via Chris Double.]

OpenMCL 0.13

OpenMCL 0.13 has been released.

This version includes the following changes:

• Shared libraries can be opened and closed in Darwin
• A Cocoa-based inspector by Hamilton Link
• The socket API is exported from OPENMCL-SOCKETS to aid in compatibility with ACL's implementation.
• Many bug fixes (bignums, sockets, the condition hierarchy and more)

Gary Byers sent in a screenshot of the inspector in action:

No New Anything

John Wiseman here. Sorry about the recent lack of anything new to read here at lemonodor (and I like to think it is at least a lack that one could notice when compared to the usual problem which is to filter out the lisp or non-lisp content, as fits your preference), and I wish I had a good excuse. But I don't, I've just been working 11 hour days. There's almost nothing more boring than hearing someone say "I've been busy with work.".

What you should probably do is go read this Gavin guy and Juri person, see what this Langley fellow is up to, keep track of the SBCL wonder twins Dan and Christophe, and then be impressed by aaronsw.

Once that's done, you probably ought to check out the tripartite entity that represents itself as Fred, Jeff and Mister Pants.

And, as always, read boing boing every day.

ACL 6.2

ACL 6.2 has been released, and the trial version is available.

The release notes list maybe a couple hundred changes. Some interesting ones are

• A new XML-RPC module
• A GTK Interface on linux and solaris
• Lots of bug fixes (including the rename-file bug that Mike found)
• The lisp browser plugin no longer supported. It's not all that relevant these days, is it?
• A change to the process binding implementation that will make it easier to implement native threading later.

Four Days in Chicago

It feels both much longer and much shorter than just four months since I left Chicago. I went back this weekend and saw my friends and went to the Wisconsin state fair with my family (where I saw a girl sleeping, curled up in the hay with her cow as if it were just a big, big dog). The only aspect of the trip that didn't quickly become familiar was the humidity. I wonder if that means that excessive humidity is naturally foreign to the human body in a way that cheese on a stick is not.

The one other weird thing was that I could smell the dirt in Chicago. While I lived there the soil seemed crappy and sandy, but I guess crappy can be relative.

I still feel lucky to live in southern California. I can't remember who described Pasadena as "Too pleasant to work in", but it's true in the sense that Kurt Cobain would have ended up doing alt-country if he lived here.

Lisp Performance

Doug Bagley's well-known and contentious programming language "shootout" compares the performance of 30 different languages in 25 different benchmark tasks, with none of the tasks taking more than a few hundred lines of code at worst (and I don't think any of them requires more than 60 lines of lisp code).

Such a comparison is not completely useless. It does give some sense of the expressive power of each language, and there really are projects that need to fit in a couple megabytes of RAM (and a test like Bagley's does give you at least a rough lower bound on memory requirements). And I suppose if you didn't know that most lisps compile to native code while Ruby is interpreted, CMUCL's time of 0.33 seconds on the matrix multiplication test compared to Ruby's 47.20 seconds would clue you in pretty quickly.

But comparions using tasks more representative of larger and more complicated applications (which is the space in which lisp is usually assumed to come into its own) would be helpful.

This set of slides by Ken Anderson (from 1994, spotted recently on the ll1-discuss list) compares C and lisp implementations of two machine learning benchmarks using CASCOR1 and Genetic Programming. And the results are interesting, though not too surprising: Both benchmarks took at least twice as many lines of C code (about 8000) as lisp (about 3500). The lisp versions were initially considerably slower than the C implementation, but eventually both ACL and CMUCL were sped up to the point of being slightly faster than the gcc version (Lucid got close to gcc).

Another interesting statistic was that for the GP benchmark, the C code spent over 30% of it's time in malloc/free, while the lisp code spent about 15% of its time consing/gcing.

Ken Anderson has more information on lisp (and Java performance). Other sources of information that I've found helpful are the section on optimization in Norvig's PAIP and various columns from Jon Bentley (collected in Programming Pearls and More Programming Pearls, which don't mention lisp but are pretty good).

lispworks.com

Xanalys has launched www.lispworks.com dedicated to its LispWorks lisp environment.

From the press release:

The increasing demand for LispWorks over the last twelve months makes the decision to put LispWorks on a dedicated website a natural choice. This will affirm our focus on LispWorks as a product and improve our service to its users.

I like to see lisp vendor activity.

Never Fight a Land War in Asia... In Person

A Yahoo story on military land robots: "The war in Afghanistan is the first time robots are being used by the U.S. military as tools for combat." [via robots.net]

The robots being used are "semi-autonomous" PackBots from Rodney Brooks' iRobot, but again it seems like only a matter of time before they're mostly autonomous.