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

[Alex Martelli]

Bill Atkins <NOatkinwSPAM at rpi.edu> wrote:
   ...
> Does Python have any support for closures?  If so, ignore this point.

Ignored, since closures are there.

> Being able to keep pass around state with functions is useful.

Sure, but naming the functions doesn't hamper that.

> There are also cases where a function is so trivial that the simplest
> way to describe it is with its source code, where giving it a name and
> putting it at the beginning of a function is just distracting and
> time-consuming.  E.g.:
> 
>   (remove-if (lambda (name)
>                (find #\- name :test #'char=))   
>              list-of-names)
> 
> What's the sense of giving that function its own name?  It's much
> clearer to simply write it in place.  Yes, it's _possible_ to use
> named functions, but in this case its functionality is so simple that
> it's clearer to simply type it in place.  Why is this expressiveness a
> bad thing, aside from its power to wreck an indentation-significant
> language?

Offering several "equivalently obvious" approaches to performing just
one same task is bad for many reasons: you end up with a bigger language
(with all the attending ills) with no extra power, and you diminish the
style uniformity of programs written in the language, hampering the
ability of many people to work in the same codebase with no "ownership".

Like most all design principles, "there should be one, and preferably
only one, obvious way to perform a task" is an _ideal_, unattainable in
its perfect form in this sublunar world; but I find it an extremely
helpful guideline to design, and it does pervade Python (many of the
planned improvements for the future Python 3.0, which will be allowed to
be backwards-incompatible with 2.*, involve *removing* old features
made, in this sense, redundant by enhancements in recent versions; my
only beef here is that _not enough_ is scheduled for removal, alas).


> people are used to ALGOL-like languages does not mean that ALGOL-like
> languages are more aesthetically pleasing on their own merits.

"on their own merits" can't be the case -- as Wittgenstein pointed out,
we ARE talking about the natural history of human beings.  A frequently
observed aestethic preference for X over Y says nothing about X and Y
``on their own merits'' (if such noumena could even be envisaged), but
it's empirically important about X and Y _when many human beings must
interact with them_.

Being "used to" some kinds of languages has nothing to do with it: when
I met Python I was most "used to" perl (and cognizant of Forth, scheme,
pre-common Lisp, sh, APL, ...), nevertheless Python immediately struck
me as allowing particularly beautiful coding. And I specifically named
many Lisp experts as acknowledging exacty the same thing, further
demolishing your "used to" strawman...


Alex