A critic of Guido's blog on Python's lambda

[Paul Rubin]

aleaxit at yahoo.com (Alex Martelli) writes:
> > (|(| "your Lisp /is/ rusty.")
> 
> Interestingly, the SECOND lisper to prove himself unable to read the
> very text he's quoting.  Reread carefully, *USE THE ***SINGLE***
> CHARACTER* ... *AS AN ORDINARY IDENTIFIER*.  What makes you read a
> ``PART OF''  that I had never written?  You've shown how to use the
> characters as *PART* of an identifier [[and I believe it couldn't be the
> very start]], and you appear to believe that this somehow refutes my
> assertion?

The identifier there is a single paren.  The vertical bars are used to
escape the paren, so that the reader doesn't get confused.  The Pythonic
equivalent would be something like  

   \( = 5

where the backslash escapes the paren.  In real Python you could say:

   locals()['('] = 5

In Lisp you could get rid of the need to escape the paren if you
wanted, using suitable read macros.  Whether that's a good idea is of
course a different matter.  

> Yes, we are, because the debate about why it's better for Python (as a
> language used in real-world production systems, *SCALABLE* to extremely
> large-scale ones) to *NOT* be insanely extensible and mutable is a
> separate one -- Python's uniformity of style allows SCALABILITY of
> teams, and teams-of-teams, which is as crucial in the real world ...

My current take on Lisp vs Python is pretty close to Peter Norvig's
(http://www.norvig.com/python-lisp.html):

    Python has the philosophy of making sensible compromises that make
    the easy things very easy, and don't preclude too many hard
    things. In my opinion it does a very good job. The easy things are
    easy, the harder things are progressively harder, and you tend not
    to notice the inconsistencies. Lisp has the philosophy of making
    fewer compromises: of providing a very powerful and totally
    consistent core. This can make Lisp harder to learn because you
    operate at a higher level of abstraction right from the start and
    because you need to understand what you're doing, rather than just
    relying on what feels or looks nice. But it also means that in
    Lisp it is easier to add levels of abstraction and complexity;
    Lisp makes the very hard things not too hard.
> 
> It's hard to attribute feelings to a programming language, but, if you
> really must, I'd say Pyton aspires to be *useful* -- if all you need is
> "just a scripting language", it will be content to be one for you, and
> if your need SCALE, well then, PYTHON IS SCALABLE, and will remain a
> *SIMPLE, CLEAN, LITTLE AND POWERFUL LANGUAGE* (letting nobody do
> anything INSANE to it;-) while scaling up to whatever size of project(s)
> you need (including systems so large that they redefine the very concept
> of "large scale" -- believe me, once in a while at a conference I make
> the mistake of going to some talk about "large scale" this or that, and
> invariably stagger out once again with the realization that what's
> "large scale" to the world tends to be a neat toy-sized throwaway little
> experiment to my current employer).
    
I've heard many times that your current employer uses Python for all
kinds of internal tools; I hadn't heard that it was used in Very Large
projects over there.  I'd be interested to hear how that's been
working out, since the biggest Python projects I'd heard of before
(e.g. Zope) are, as you say, toy-sized throwaways compared to the
stuff done regularly over there at G.