"Michele Simionato" <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list