Paul Rubin wrote: > Despite the shrieks of the "Python is not Lisp!" crowd, Python > semantics and Lisp semantics aren't THAT different, and yet compiled > Lisp implementations com completely beat the pants off of interpreted > Python in terms of performance.
I know little about Lisp compilation, so I could be mistaken, but I was under the impression that one of the differences between Python & Lisp is directly relevant to compilation issues. Python, as a procedural language, makes extensive use of globals & mutable variables. Not only can the contents of a variable change, but that change can non-explicitly affect a function in a "remote" part of the program, hence the requirement for the Global Interpreter Lock. Tracking how changes propagate in Python is non-trivial, as evidenced by the difficulty of replacing the GIL with a less "obtrusive" alternative. IIUC, in Lisp, as a functional language, "all politics is local." Global-like variables are much rarer, and mutability is severely limited. In this case it is much easier to track how a piece of code alters the program's state - the propagation of those changes are handled explicitly, and once you have a reference to a piece of data, you don't have to worry about some other function changing the value on you. As such, it's a lot easier to write an optimizing compiler - you can place much greater limits on what is known at compile time. It's been quite a while since I've looked at Lisp/functional languages, though, so I could be misunderstanding what I remember. -- http://mail.python.org/mailman/listinfo/python-list
