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

[M Jared Finder]

Alex Martelli wrote:
> Stefan Nobis <snobis at gmx.de> wrote:
> 
>> aleax at mac.com (Alex Martelli) writes:
>>
>>> if anonymous functions are available, they're used in even more
>>> cases where naming would help
>> Yes, you're right. But don't stop here. What about expressions? Many
>> people write very complex expression, that are hard to understand. A
>> good language should forbid these abuse and don't allow expressions
>> with more than 2 or maybe 3 operators!
> 
> That would _complicate_ the language (by adding a rule).  I repeat what
> I've already stated repeatedly: a good criterion for deciding which good
> practices a language should enforce and which ones it should just
> facilitate is _language simplicity_.  If the enforcement is done by
> adding rules or constructs it's probably not worth it; if the
> "enforcements" is done by NOT adding extra constructs it's a double win
> (keep the language simpler AND push good practices).

Your reasoning, taken to the extreme, implies that an assembly language, 
by virtue of having the fewest constructs, is the best designed language 
ever.  But we know that not to be the case -- rarely do even embedded 
developers program in assembly language any more.  Why?

Because assembly language is so simple that it's very tedious to write. 
   There's no function call primitive -- you have to manually generate a 
function call pattern yourself.  There's no looping primitive -- you 
have to manually generate a looping pattern yourself.  I feel sorry for 
the person who's debugging an assembly program using manually generated 
code that implements a vtable-based dynamic dispatch.

Any feature that allows me to write less code to do the same thing has a 
huge positive -- the reduction of human generated, and therefore error 
prone, code.  I think the advantages of anonymous functions:
a) explicitly documenting that the function is used in only one place
b) enabling generic iteration and looping routines
c) not having to maintain a unique name for the function
d) making the language more elegant
e) making the language simpler to implement
greatly outweigh the small disadvantage of adding one additional 
construct to the language.

   -- MJF