I sing the praises of lambda, my friend and savior!

[Antoon Pardon]

Op 2004-10-14, Jeff Shannon schreef <jeff at ccvcorp.com>:
> Clark C. Evans wrote:
>
>>Assume for a moment the following programming costs:
>>
>>  2m  Minting a name, that is, finding a name that is not 'foo'
>>      which semantically adds to the readability and maintainability
>>      of the code.
>>  
>>
>
> Does it *really* take you two whole minutes to find a meaningful name?  

I can't speak for Clarc but yes it does for me, Because sometimes there
just isn't a meaningfull name IMO and the best you can come up with is
frase what the function does in words what would be easier expressed in
a formula.

> Two minutes is a pretty long time if you're just sitting and thinking.  
> Even button1_callback() seems fairly readable and maintanable to me.  

But that is not a meaningfull name. It doesn't add any information.
That it is a callback for button1 can be easily inferred from the
fact that it is used as the callback parameter.

IMO this is just as usefull as:

  parameter = [3,5,8,23]
  lng = len(parameter)

> And anyhow, a fair number of the examples of lambda usage that I've seen 
> can be easily replaced with a reference to an existing function -- 
> operator.mul() isn't that difficult...

I agree that my need for using lambda's has diminished as python has
evolved. But a reference to operator.xxx only helps if you want a
single operator as a function. As soon as you need to combine
operators you need to construct a new callable.

> To be honest, if I were worrying about programming costs, I'd be looking 
> at the time I'd spend trying to refactor my problem into something where 
> I could use (perhaps curried versions of) more generic callbacks.  That 
> might be a pretty significant investment of time, actually.  Of course, 
> it might (or might not) pay off with a cleaner and clearer overall 
> architecture...   But perhaps this is a particular weakness of mine, 
> where I want to try to generalize things as much as practical.
>
> Given the presumption that many, if not most, uses of lambda could be 
> generalized to some degree, I don't think it would be necessary to mint 
> a new name for each and every lambda that you currently use, even in 
> those cases where there *isn't* a pre-existing standard-lib function 
> that serves the same purpose as the lambda.

I do wonder whether it would add readabilty. My impression is that
curried functions are not that easily understood and I fear that
those who have problems with lambda's will not be helped if the
lambda's are replaced with curried functions. IMO generalizing
when it isn't necessary can detract from readability too. If you
have need specific functionality and have a function that provides
just that specific functionality, you just need to understand that
function. If you have a more general function, you need to understand
that function and how the use of certain parameters transforms the
general case into your specific case.


Not that I'm against the use of curried functions or the use of
general functions.

-- 
Antoon Pardon