merits of Lisp vs Python

[Paul Rubin]

Bruno Desthuilliers <bdesth.quelquechose at free.quelquepart.fr> writes:
> Strictly speaking, only first-class functions are required, and
> tail-recursion optimisation is only an implentation detail. Now it's
> obvious that when it comes to real-life-size programs, this is a
> *very* important detail !-)

I don't buy this.  One of my favorite quotes about specifications
(http://www.sgi.com/tech/stl/drdobbs-interview.html):

    Let's take an example. Consider an abstract data type stack. It's not
    enough to have Push and Pop connected with the axiom wherein you push
    something onto the stack and after you pop the stack you get the same
    thing back. It is of paramount importance that pushing the stack is a
    constant time operation regardless of the size of the stack. If I
    implement the stack so that every time I push it becomes slower and
    slower, no one will want to use this stack.

    We need to separate the implementation from the interface but not at
    the cost of totally ignoring complexity. Complexity has to be and is a
    part of the unwritten contract between the module and its user. The
    reason for introducing the notion of abstract data types was to allow
    interchangeable software modules. You cannot have interchangeable
    modules unless these modules share similar complexity behavior. If I
    replace one module with another module with the same functional
    behavior but with different complexity tradeoffs, the user of this
    code will be unpleasantly surprised. I could tell him anything I like
    about data abstraction, and he still would not want to use the
    code. Complexity assertions have to be part of the interface.