merits of Lisp vs Python

[Paul Rubin]

Espen Vestre <espen at vestre.net> writes:
> > I'd say Python is more dynamic in the sense that the Python runtime
> > system has to actually concern itself about the dynamism all the time
> > in practice, i.e. on every object method invocation.  
> 
> Ok, but when you state that language A is more dynamic than language
> B, most programmers would interpret that as (or so I guess) "A offers
> more dynamism to the programmer than B" - not that it burdens the run
> time system implementor with more dynamism...

I'm sorry for any misunderstanding.  Maybe I should have said that
Python's dynamism is more pervasive: it can be activated in more
different ways and that creates an extra burden on the runtime system.
Remember that the context was whether Python could be compiled to
efficient machine code.  So I referred to "more dynamism" from the
implementers' point of view--the runtime has to pay attention to more
things and spend more resources dealing with the dynamism.

I think the Lispies see "more dynamism" as a good thing and are
therefore defending their language from suggestions that Python is
even more dynamic than Lisp.  I mean "dynamic" in a less good way--
there is a huge amount of state scattered all through a running Python
program, that the application can modify at random and whose contents
the working of really fundamental operations like method invocation.
It's just a big mess and I'd get rid of it if I could.  It reminds me
of like old time Lisp programs that pervasively used property lists on
symbols to attach random attributes to the symbol, instead of using
something like defstruct to make multi-field data values.

How about if I say Python and Lisp are both dynamic, but Lisp does a
better job of keeping its dynamism's potentially chaotic effects
contained.  Does that help?