merits of Lisp vs Python

Alex Mizrahi udodenko at users.sourceforge.net
Fri Dec 8 09:43:23 EST 2006


(message (Hello 'Richard)
(you :wrote  :on '(Fri, 8 Dec 2006 14:08:09 -0000))
(

 ??>> seems to show that Python is a cut down (no macros) version of Lisp
 ??>> with a worse performance.

 RB> Performance claims are always controversial. So, Python is much slower
 RB> doing array multiplication, when you hand roll it, instead of using the
 RB> standard numerical packages available.

heh, do you have "standard numeric packages" for everything? maybe then 
we'll make standard programs for everything -- that will obsolete "slow" 
"custom scripts" and we'll just use shell to select what program we want to 
run?
certainly, it's possible to write code in C and use FFI to access it, but 
it's not suitable for rapid prototyping/fast development, when requirements 
may change, or you're just experimenting with different methods.

it's interesting than as of bare "interpreter overhead", python is aprox 
order of magnitude (10 times) slower than lisp interpreters. it's also 
interesting, that python, perl, php and ruby show very similar peformance, 
while lisp and scheme implementations show large improvements -- it makes me 
think that there's something "pathalogically scripting" in their 
specifications (maybe some obligatory use of strings for method dispatch?).

note that i've mentioned "lisp interpreters" above. as for lisp _compilers_, 
they run lots faster than lisp interpreters.

please check http://shootout.alioth.debian.org/
to compare Python to Lisp SBCL. lisp is faster more then 10 times in many 
benchmarks, and even more than 100 times faster in two benchmarks.
unfortunately there's no lisp interpreters (CLISP) in the benchmark.

)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity") 





More information about the Python-list mailing list