Python's simplicity philosophy

[Anton Vredegoor]

David Eppstein <eppstein at ics.uci.edu> wrote:

>The argument is that reduce is usually harder to read than the loops it 
>replaces, and that practical examples of it other than sum are sparse 
>enough that it is not worth keeping it just for the sake of 
>functional-language purity.

One argument in favor of reduce that I haven't seen anywhere yet is
that it is a kind of bottleneck. If I can squeeze my algorithm through
a reduce that means that I have truly streamlined it and have removed
superfluous cruft. After having done that or other code mangling
tricks -like trying to transform my code into a one liner- I usually
have no mental problems refactoring it back into a wider frame.

So some things have a use case because they require a special way of
thinking, and impose certain restrictions on the flow of my code.
Reduce is an important cognitive tool, at least it has been such for
me during a certain time frame, because nowadays I can often go
through the mental hoop without needing to actually produce the code.
I would be reluctant to deny others the chance to learn how not to use
it.

Anton