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

[Patrick May]

aleax at mac.com (Alex Martelli) writes:
> ...an alleged reply to me, which in fact quotes (and responds to)
> only to statements by Brian, without mentioning Brian...
>
> Mr May, it seems that you're badly confused regarding Usenet's
> quoting conventions.

     It seems that someone pisses in your cornflakes nearly every
morning.

     For the record, I was attempting to respond to your post which I
only saw quoted in another message.  Please excuse any accidental
misquoting.

>>      Using lambda in an expression communicates the fact that it
>> will be used only in the scope of that expression.  Another benefit
>> is that declaration at the point of use means that all necessary
>> context is available without having to look elsewhere.  Those are
>> two pragmatic benefits.
>
> You still need to look a little bit upwards to the "point of use",
> almost invariably, to see what's bound to which names -- so, you DO
> "have to look elsewhere", nullifying this alleged benefit -- looking at
> the def statement, immediately before the "point of use", is really no
> pragmatic cost when you have to go further up to get the context for all
> other names used (are they arguments of this function, variables from a
> lexically-containing outer function, assigned somewhere...), which is
> almost always.

     It appears that you write much longer functions than I generally
do.  Requiring that all functions be named adds even more to the
clutter.

> And if you think it's an important pragmatic advantage to limit
> "potential scope" drastically, nothing stops you from wrapping
> functions just for that purpose around your intended scope

     Or, I could just use a language that supports unnamed functions.

> Your "pragmatic benefits", if such they were, would also apply to the
> issue of "magic numbers",

     That claim is, frankly, silly.  A function is far more
understandable without a name than a value like 1.19 in isolation.
The situations aren't remotely comparable.

>> >> 3. It adds another construction to the language.
>> 
>>      That's a very minimal cost relative to the benefits.
>
> To my view of thinking, offering multiple semantically equivalent
> ways (or, perhaps worse, "nearly equivalent but with subtle
> differences" ones) to perform identical tasks is a *HUGE* conceptual
> cost: I like languages that are and stay SMALL and SIMPLE.

     Like Scheme?

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc.    | The experts in large scale distributed OO
                         | systems design and implementation.
          pjm at spe.com    | (C++, Java, Common Lisp, Jini, CORBA, UML)