I sing the praises of lambda, my friend and savior!
jeff at ccvcorp.com
Thu Oct 14 02:31:52 CEST 2004
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?
Two minutes is a pretty long time if you're just sitting and thinking.
Even button1_callback() seems fairly readable and maintanable to me.
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...
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.
> 30s Verifying that a function name is not used more than once to
> verify that changing its definition, or if it is reused,
> making sure all the places where a change would affect is OK.
Good point, though well-modularized code should help with this. I can't
say that I have problems with intended-name clashes very often. Given
reasonable module sizes, I'd call 30s a maximum time rather than an
average time, but that *is* a valid consideration.
>In one of my files, I've got 20 or so lambdas, typically only a few
>characters to plug-in a computation. You're asking me to pay a 40
>minute price just to mint names in this file? Then, I've had, over
>the past year about 20 edits on that file, some of which change a
>few of these lambdas, say 2 changes per edit on average. That's
>another 20 minutes. So, over the last year, in this one file alone,
>not having lambdas would have cost me an additional hour of time!
>I've got 2 largish projects, each averaging about 20 files, so
>that's about 40 hours of time chewed up with small efficiency hits.
>Or, about $4,000 of billable time. I'd rather keep the money or
>take a vacation, thank you very much.
I suspect that you could find a moderately generic approach or two that
could conveniently replace most of those lambdas, and which would
require no more maintenance work (and possibly less) than the lambdas
do, in a lot less time than 40 hours. Given that many of your lambdas
are probably variations on a theme, making generic functions might even
*save* you time. (Not that I'm quite convinced about your figure of 40
hours even if you *did* insist on using named functions in the exact
same style that you now use lambdas, rather than refactoring to take
advantage of the benefits that full functions give you.)
More information about the Python-list