Python vs. Lisp -- please explain

[Alexander Schmolck]

"Michele Simionato" <michele.simionato at gmail.com> writes:

> I replied to this message yesterday, but it did not appear, so let's
> try again.
> 
> I agree with your points, but I would not say that Lisp is
> intrinsically more dynamic than Python as a language;

Neither would I -- I don't think either is obviously more dynamic than the
other.

But since it has been implied that python's comparatively poor performance is
simply due to it being more dynamic than other languages, I wanted to point
out that one could with just as much justification claim CL to be more dynamic
than python (it is in some regards, but not in others -- how to weight them to
achieve some overall "score" is not obvious. I really doubt that python will
ever come remotely close to the level of dynamism that now defunct lispmachine
technology achieved, though).

> it is just more interactive and has more features (and more complexities
> too).

Indeed -- CL is much more complex than python and has many, many more warts.

As for common lisp being "just more interactive" -- all things being equal I
fail to see how "more interactive" cannot imply more dynamic -- IMO it doesn't
get much more dynamic than changing and inspecting things interactively. Also
not all the ways in which CL is more dynamic represent features that increase
complexity. For example in CL you could just write

  def foo(x, l=[], N=len(l)): [...]

and have it work as expected because defaults are evaluated on call (this is
one of the very rare occassions of an obvious design wart in python, IMO).

In other cases, of course, more dynamism seems to involve added complexity.
For example CL has sane (dynamically scoped) global variables (and local ones,
if you declare them "special"). I think python is somewhat broken in this
regard, but I must admit I have no idea how to implement dynamically scoped
variables simply and "pythonically", so I wouldn't call it an obvious design
flaw.

> BTW, regarding your first point on interactive sessions, are you aware
> of Michael Hudson's recipe
> "automatically upgrade class instances on reload()"
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/160164 ?

Thanks, it's nice to be aware of other solutions, I'll have a closer look at
some point. I've of course also written my own code for that purpose -- apart
from ipython.el and a couple of private utilities I even got sufficiently
pissed off by bugs introduced by python's poor support for serious interactive
work that I started writing some sort of versioned module system that kept
track of what was being imported from where to where, but I ran out of time
and ultimately for this and unrelated reasons switched to matlab in this
particular case.

Matlab sucks in countless ways, but it gives a superior interactive
environment. If you do experimental work where state is expensive to recompute
from scratch but where you need to tune various parameters to obtain the
desired results, problems introduced by changes not properly propagating are
very, very irritating -- especially if you want to keep a record of what changes
effected what, so that your experiments are repeatable.

'as