The graph is useless (don't use a log scale, please choose a better range)
The code is somewhat frightening (C implementation totally naïve, and I'm not much of a Lisper, but the nesting level there scares me)
It's 'bizarre' syntax, it's alleged ability to ... facing it's almost vertical cliff face of ... (I hope English isn't your native language; you should be using its, the possessive form)
Lisp being an implementation of Lambda Calculus (what?)
and a functional language (no?)
To sum it all up : The small factor in difference between C and Lisp really does not matter. As the Lisp compilers improve in the code that they generate over the coming years the gap will close without much work on the Lisp hacker's part.
Conclusion: [some banality]
Now, pretend I had written the above more eloquently and inefficiently, and I'll pretend Safari didn't die. Oh well :(
The C version is not fully optimized (yes it's naive) and this was intentional and stated in the article (perhaps not clearly enough).
A fully optimized C version would run in under 5 seconds for the 1000x1000 board on the same hardware using all the 'idiomatic' tricks using bit masks etc.
A similarly optimized Lisp version would also run faster using different data structures and/or algorithms.
You've missed the point.
Learn to read logarithmic graphs without prejudice, you may discover much useful information around you that you assumed was 'useless'.
Yes Lisp is an implementation of Lambda Calculus : horrific isn't it ?
I don't know how many times I have to say this :
Lisp is a functional language but also allows for imperative programming.
You're only valid point was the misuse of "it's" instead of "its". Good job.
If speed is that important, use foreign function calls (or, better yet, Haskell).
And I say this as a long time CL coder who has written several highly perfomant lisp libraries. See, for example, polygon.lisp, color.lisp, and bitmap.lisp at http://github.com/smanek/ga/tree/master. In order to get decent performance you have to give up many of CL's advantages (not using half of CLOS's features, providing type hints, bit twiddling, imperative style, etc).
For example, both Python and Ruby have less-than-ideal implementations, and the avoidable flaws in their design are well known. Despite that, it's taken a long time to get to the point where anyone is even motivated to work on a reimplementation.
And on the other hand, Lisp has had scores of implementations, but it still can't reliably earn the prized "equal/better to C" benchmark scores. This if nothing else should inform us that performance considerations definitely do come into play at the language-design level.
In the next paragraph you state that because Lisp does not match C in performance this somehow proves that language-design directly effects the ability for a Lisp compiler to generate optimized code comparable to generated code from a C compiler.
This is a bizarre conclusion. What is your reasoning for this ?
Also, Lisps are imperative. setf, setq and the like.
"system maintenance" for the url that you posted.
When one says "imperative", one hardly means "an smalltalk influenced, pure object oriented language", but more like a statically-typed Algol variant, usually a derivative of C, Fortran, Pascal or Ada.
I don't think the Io counter-example is valid, just as an Icon counter-example would be valid (yes, Icon is "imperative", but it's also an Snobol derivative with goal-oriented execution, generators and perl-like text processing prowess :-)
list(1, 2, 3, 4) select(isEven) map(+(1))
==> list(3, 5)
isEven and +(1) are messages that select and map evaluate.