

PicoLisp SBCL Benchmarks - user0
http://picolisp.com/5000/-2-F.html

======
dmm
I don't really understand the author's point. He asks what the point of
supporting a compiler is when the result is not any faster when his own
benchmarks show that the SBCL compiler is significantly faster.

Also, any combination of lisp and CamelCase should be avoided on principle.

~~~
dman
The key to the authors point is this sentence - "One of the greatest mysteries
in the history of computer language comparisons is to me the question why most
people are more interested in the relative speed of a language implementation,
rather than in features like expressiveness, flexibility and orthogonality.".
The author appears to believe having a lisp which ~5x-10x slower is a
worthwhile tradeoff to make if the underlying lisp is simpler, more flexible
and more expressive. PS: I am not suggesting that picolisp is simpler, more
flexible or more expressibe.

------
ericbb
Having skimmed the PicoLisp interpreter a long time ago, I remember it being
like Emacs Lisp in that common performance-critical functions like mapcar were
implemented in C. It seems like a very pragmatic way to get the performance
you need without getting into byte codes or machine language. And since you
are still interpreting the s-exprs directly, debugging and introspection
remain easy.

