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

[Joe Marshall]

Alex Martelli wrote:
>
> Your "pragmatic benefits", if such they were, would also apply to the
> issue of "magic numbers", which was discussed in another subthread of
> this unending thread; are you therefore arguing, contrary to widespread
> opinion [also concurred in by an apparently-Lisp-oriented discussant],
> that it's BETTER to have magic unexplained numbers appear as numeric
> constants "out of nowhere" smack in the middle of expressions, rather
> than get NAMED separately and then have the names be used?  If you
> really believe in the importance of the "pragmatic benefits" you claim,
> then to be consistent you should be arguing that...:
>
>     return total_amount * 1.19
>
> is vastly superior to the alternative which most everybody would deem
> preferable,
>
>     VAT_MULTIPLIER = 1.19
>     return total_amount * VAT_MULTIPLIER
>
> because the alternative with the magic number splattered inexplicably
> smack in the middle of code "communicated the fact" that it's used only
> within that expression, and makes all context available without having
> to look "elsewhere" (just one statement up of course, but then this
> would be identically so if the "one statement up" was a def, and we were
> discussing named vs unnamed functions vs "magic numbers").

Most languages allow `unnamed numbers'.  The `VAT_MULTIPLIER' argument
is a
strawman.  Would you want to have to use a special syntax to name the
increment
in loop?

 defnumber zero 0
 defnumber one { successor (zero); }

 for (int i = zero; i < limit; i += one) { ...}

If you language allows unnamed integers, unnamed strings, unnamed
characters, unnamed arrays or aggregates, unnamed floats, unnamed
expressions, unnamed statements, unnamed argument lists, etc.  why
*require* a name for trivial functions?
Wouldn't all the other constructs benefit by having a required name as
well?

>
> 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.

Then why not stick with S and K combinators?  There are few languages
SMALLER and
SIMPLER.