Common Lisp would sound like a miracle language if it wasn't real.

Can be configured to run almost as fast as C. Or dynamism that rivals Ruby and Python if you don't bother to specify types. An object system (and meta-object protocol) that rivals Smalltalk in sophistication. Full functional programming capabilities, and a syntax and libraries that favor that style. An entire sub-language for iteration that rivals Python's generation/comprehension facilities. The ability to be procedural when you really need to. Sophisticated built in data types. A facility for abstraction unrivaled by any other language that's not a Lisp.

The point is not necessarily that CL is the absolute best for every one of those points. But you can make a case for CL vs. another language based on that language's strong points, not its weak points.

Of course, don't get me started on the mess that is CL's community...

> Of course, don't get me started on the mess that is CL's community...

is or was? It is in fact changing into better.

Glad to hear it. Maybe I should check back in.

Specific developments I should be aware of...?

The article does not say why the Lisp code was faster in the float case. What bottleneck did GCC face there?

Btw does CL have OpenMP style parallel for loops?

Lisp is really the best of both worlds. It's a nice looking language (easy to read and write; and good tools available), and I would use it even if it were slow. But unlike the other slow langauges (Perl), it can be made to run fast.

Now if only there were some libraries.

You might want to look at Nu (http://programming.nu). It's a new Lisp built on Objective-C, designed to make it extremely easy to call C or Objective-C libraries and frameworks (particularly Cocoa). It's a wonderful merger of Lisp, Objective-C, and Ruby.

If you are working in a language that has significant development advantages but mediocre performance, I think it is reasonable to look for ways to improve its performance.

That is a truly horrible file viewer. Allow the user to define how they want their files. No lock in - whoever did this is evil or a moron.

The url I submitted is: http://www.lrde.epita.fr/~didier/research/verna.06.imecs.pdf

Not sure how or why it wound up at scribd.com

Properly because scribd is a YC company and HN does some form of automatic submit of pdf files.

I which case the problem should be solved relatively fast because somebody here likely knows the guys at scribd.

Ouch, yeah that's some kind of bug in scribd... the original is a nice LaTeX document. The scribd version is all fuzzy.

I can barely read the text. Is it my computer or the document?

It's scribd.

[citation needed]

And there are already standard mechanisms to provide type information to the compiler...

If you only optimize what you determined are the bottlenecks with the aid of a profiler, your code will run fast and won't be brittle.