Note I'm not a Python person and I have no axes to grind here.  This is
just a question for my general education.

http://norvig.com/python-lisp.html

seems to show that Python is a cut down (no macros) version of Lisp
with a worse performance.  The only substantial advantage I can see is
that GUI, and Web libraries are standard.  This confirms my suspicion
that Lisp is losing out to newbies because of its
lack of standard support for the things many people want to do.

 ??>> 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.

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

 IA> or maybe it shows that Lisp is an obfuscated version of Python

hell no, lisp's syntax is much easier than python's since it's homogenous
(and certainly lisp was invented much 30 years before Python, so that's
Python uses Lisp features)

 IA> with lots of parentheses,

that make logic more explicit

 IA>  backward logic,

??

 IA>  and complicated constructs that run faster.

no, there are no complicted constructs -- just it's designed with 30-year
history in mind, not like "let's make another simple scripting language".

Ouch.

hth,kt

--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

What do you want?

These two features reward the use of type declarations throughout
development, even when high performance is not a concern. Also, as
discussed in the chapter on performance (see Efficiency), the use of
appropriate type declarations can be very important for performance as
well."

http://www.sbcl.org/manual/Handling-of-Types.html#Handling-of-Types

Consumer choice can never be boiled down to one thing; there are so
many factors.  No one knows the whole answer.  I certainly don't.  (If
I did, I'd be courteously turning down the Nobel Prize for Economics on
account of being so rich I really didn't need the extra pocket change.)

I have no doubt that what you say is a contributing factor, but if I
had to guess the main reason why Lisp is losing out to newbies, I'd say
it's first impressions.  When newbies see Python they say, "Ok, I can
kind of follow that, it doesn't look too hard to learn."  When they see
Lisp they say, "WTF IS THAT???"

It's kind of sad, in a way, that a superficiality would be so crucial.
(Not that I think outward appearance is all superficial--I think humans
have evolved and/or learned to regard as beautiful that which minimizes
effort--but it's not the whole story and not basis for a whole
judgment.)

Pythons advantages are:

Faster startup-time which makes it a good scripting language.

More platforms, there is no Common Lisp on Nokia phones.

Some clever details, like using minus to index vectors from the right.
(aref "hello" -1) gives an error on Lisp, but the character o on
Python.

Another detail I like is that you can choose how to quote strings, in
Python you can write three double-quotes to start a string that can
include anything, quotes, doublequotes and newlines.
You can use double-quote if you want to embed single-quotes "john's" or
single-quote if you want to embed double-quotes '<id="2">'.

Talking about Lisps advantages will take me too long.

[many parentheses]

Regards,

Björn

Xpost cll,clp

--
BOFH excuse #166:

On the other hand can I see difficulties in adding macros to Python,
or inventing a new object system, or adding new keywords without
changing the sources of Python itself.

CL-USER> (< 1 2 3 4 5 6 7 8 9 10)
T
CL-USER> (< 1 2 3 4 5 6 7 8 9 10 9)
NIL

"Programmable syntax is not in Python's future -- or at least it's not
for Python 3000. The problem IMO is that everybody will abuse it to
define their own language. And the problem with that is that it will
fracture the Python community because nobody can read each other's code
any more."

http://mail.python.org/pipermail/python-3000/2006-April/000286.html.

 KS> http://www.sbcl.org/manual/Handling-of-Types.html#Handling-of-Types

 KS> If you'd read the docs of the tools you admire you might find the
 KS> answers yourself.

SBCL is a COMPILER that explains everything. it's interesting why
INTERPRETER like CLISP is faster.
well, it can be type declarations as well, but maybe something other too..

for example, in languages like Python, PHP and JavaScript, as i understand,
by semantics of the language interpreter MUST use dict to call objects
method -- at any time it can be changed, for any object instance. i'm not
sure whether it has to dynamically resolve package's methods doing lookup in
packages dict.

however, in Common Lisp object methods are dispatched on object types, that
is a special language entity, so as long as new types are not introduced,
interpreter can optimize calls how it wants to. the difference is that while
it's still dynamic, dispatch over types are more controlled/optimizable than
dispatch using dict.
then, symbols in common-lisp package cannot be changed according to spec,
thus compiler/interpreter is safe to do optimizations it wants when sees
that symbols (if we want symbols with same names, we can make other package
with them).

then, Common Lisp standard defines what inlining is. i bet most
optimizations in dynamic languages are not possible if inlining is not
enabled -- since any symbol that is not inlined can change it's meaning in
any time.

A Beginners' Meta FAQ for comp.lang.lisp:

  http://nostoc.stanford.edu/jeff/llisp/cllfaq.html

The purpose of this page is to help those new to Lisp (aka. "newbies")
gain some background before they enter the fray of comp.lang.lisp
(c.l.l). This is not a complete Lisp FAQ! Once you have a sense of Lisp

and of how c.l.l operates you should have no trouble finding all the
additional information you need, either by your own search efforts or
by asking the community. If you have issues with any of the below
please do not send me email. Rather, post on c.l.l in the weekly thread