Python vs. Lisp -- please explain

[Kay Schluehr]

Alexander Schmolck wrote:
> "Kay Schluehr" <kay.schluehr at gmx.net> writes:
>
> > Alexanders hypothesis is completely absurd.
>
> You're currently not in the best position to make this claim, since you
> evidently misunderstood what I wrote (I certainly did not mean to suggest that
> Guido *deliberately* chose to make python slow; quite the opposite in fact).

Like everyone else. It's sometimes hard extract the intended meaning in
particular if it's opposed to the published one. I apologize if I
overreacted.

>
> Maybe I wasn't sufficiently clear, so if rereading my original post doesn't
> bring about enlightenment, I'll try a restatement.
>
> > It turned out over the years that capabilities of Python optimization are
> > lower than those of Lisp and Smalltalk. But its a system effect and
> > epiphenomenon of certain design decisions.
>
> The point is that the design decisions, certainly for Common Lisp, scheme and
> particularly for dylan where also informed by what could be done
> *efficiently*, because the people who designed these languages knew a lot
> about advanced compiler implementation strategies for dynamic languages and
> thought that they could achieve high levels of expressiveness whilst retaining
> the possibility of very fast implementations (IIRC dylan specifically was
> meant to be something like within 90% of C performance). CL and dylan were
> also specifically designed for building very large and sophisticated systems,
> whereas it seems Guido originally thought that python would scale to about 500
> LOC.

O.K. To repeat it in an accurate manner. Python was originally designed
by Guido to be a scripting language for a new OS as a more complete
version of a shell scripting language. Unlike those its design was
strongly influenced by the usability ideas of the ABC development team.
Therefore speed considerations were not the primary concern but an open
model that was easily extendable both on the C-API level and the
language level. So a VM architecture was chosen to achieve this. Adding
new opcodes should have been as simple as interfacing with the C-API.
After growing strongly in the late 90s large scale projects emerged
such as Zope and many users started to request more Python performance
since they wanted to escape from the dual-language model. Writing
C-code was not self evident for a new programmers generation grewn up
with Java and the ffi turned out to be a hurdle. After remodeling the
object core ( "new style classes" ) progressive optimizations came to
hold. In 2002 a new genius programmer entered the scene, namely Armin
Rigo, who came up with Psyco and launched the PyPy project together
with a few other Python hackers in order to aggressively optimize
Python using Pythons introspective capabilities. That's were we still
are.

Remembering the historical context we might draw some parallels to
other contexts and language design intentions. We might also figure out
parallels and differences between motives of language designers and
leading persons who drive language evolution. Python is not just Guido
although his signature is quite pervasive. In his latest musings he
comes back to his central idea of language design as a kind of user
interface design. It's probably this shift in perspective that can be
attributed as original to him and which goes beyond making things just
"simple" or "powerfull" or "efficient" ( at least he made this shift
public and visible ). It is also the most controversial aspect of the
language because it is still inseparable from technical decisions (
non-true closures, explicit self, statement-expression distinction,
anonymous function as an expression with limited abilities etc. )

Kay