(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") -- http://mail.python.org/mailman/listinfo/python-list
