Python's simplicity philosophy

[Alex Martelli]

Douglas Alan wrote:

> Alex Martelli <aleax at aleax.it> writes:
> 
>>> no disagreement, reduce is in line with that philosophy sum is a
>>> shortcut and as others have said is less general.
> 
>> 'sum' is _way simpler_: _everybody_ understands what it means to sum a
>> bunch of numbers, _without_ necessarily having studied computer science.
> 
> Your claim is silly.  sum() is not *way* simpler than reduce(), and
> anyone can be explained reduce() in 10 seconds: "reduce() is just like

As you hedged elsewhere, anyone can be EXPLAINED it, but not anyone
will UNDERSTAND the explanation instantly.  Now THAT hedging is way
silly, and of course Shakespeare did it best:

"""
Glendower: I can call spirits from the vasty deep.

Hotspur: Why, so can I, or so can any man; But will they come when you do
call for them?
"""

> sum(), only with reduce() you can specify whatever addition function
> you would like."

This explanation is misleading by overqualification (that "addition" is
the overqualification).  A non-overqualified explanation would have to
mention that ANY callable that can accept two arguments, and return a
result suitable to be its first argument next, can be passed; and it would
have to touch on what happens when the sequence is empty, and the optional
third argument.  Yes, you COULD cram it into 10 seconds -- people won't
UNDERSTAND what you're saying, of course, but clearly you don't care
about such trifles, as you have abundantly shown.


>> The claim, made by somebody else, that _every_ CS 101 course teaches the
>> functionality of 'reduce' is not just false, but utterly absurd:
>> 'reduce', 'foldl', and similar higher-order functions, were not taught to
>> me back when _I_ took my first university exam in CS [it used Fortran as
>> te main language],
> 
> Then you weren't taught Computer Science -- you were taught Fortran
> programming.  Computer Science teaches general concepts, not specific
> languages.

CS teaches general concepts and in all decent CS 101 course it starts
doing so with concrete examples (because THAT is how most people learn
best), ideally with an executable computer language so you can TRY things.
It is quite likely that higher-order functions won't be taught yet in
CS 101, or that only a very few specific cases will be shown and reduce
(or foldr or however you want to call it) will not be one of them.

Your false and utterly absurd claim about the content of _every_ CS 101
course has been totally demolished by now -- by many people, including
CS majors.  I'm sure you'd be happy to "undo" it, but you've invested
so much emotional energy on it and made it a lynchpin of your argument
in favour of 'reduce' that I understand that's just too hard.  Still,
by standing on such rotten foundations, your argument is reduced (heh)
to near-absurdity...


>> they were not taught to my son in _his_ equivalent course [it used
>> Pascal], and are not going to be taught to my daughter in _her_
>> equivalent course [it uses C].
> 
> Then your children were done a great diservice by receiving a poor
> education.  (Assuming that is that they wanted to learn Computer
> Science, and not Programming in Pascal or Programming in C.)

They wanted to learn enough computer science to get on with their
real interests in life -- telecom engineering and financial economics
respectively.  They may well take second or third courses on CS issues
in the future.  But within the confines of a Bachelor (3-years degree)
in such disciplines, heavily different from computer science but able to
use several CS conceptual and practical tools effectively for other
purposes, I think they were served perfectly well by "Foundations
of Informatics" (aka CS 101 -- we don't number things like that here,
and "Informatics" is strongly preferred over "CS", and in particular
it's the preference of local computer scientists) covering a lot of
important concepts AND practical exercises, but not ALL higher-order
functions.  Personally I think that they wasted effort in teaching
about pointers, but I guess that's debatable.


>> Python's purpose is not, and has never been, to maximize the generality
>> of the constructs it offers.
> 
> Whoever said anything about "maximizing generality"?  If one's mantra

Your only argument FOR reduce is its maximal generality (and the falsehood
that it's taught in every CS 101 course).

> elegant features understood by anyone who has studied Computer Science

If a CS 101 course (passed with top marks) counts as having "studied
Computer Science", then 'reduce' is not such a feature.  It's not very
elegant either, btw, but that's a subjective opinion -- the fact that
CS 101 courses mostly do NOT teach reduce/foldl is a FACT.  So, by
this reasoning of yours, but based on realities rather than falsehoods,
reduce should go away.

> *utterly* wrong manner.  You should be assuming that your audience are
> the smart people that they are, rather than the idiots you are
> assuming them to be.

They're smart _and pragmatical_, NOT interested in (very arguable...)
elegance _for its own sake_, for the most part.  So, they ask for GOOD
use cases for reduce, if they're taught it -- and... none can be found
throughout the Standard Python library and everywhere else I've checked
into real programs (written by me or my clients, or downloaded from
the net).  Every single use of reduce I've found would be faster,
cleaner, simpler with sum, an explicit loop, or other ways yet.


>>     Keep the language small and simple.
> 
>>     Provide only one way to do an operation.
> 
> It is not true these principles are rare among computer languages --
> they are quite common.  Most such language (like most computer
> languages in general) just never obtained any wide usage.

URLs please (or non-URL references if you must).  I had never seen
these two principles written down for a general-purpose language
before I met C -- and haven't, since, except for Python.  I'll be
quite interested in being able to quote other languages explicitly
adopting them as design criteria.


> place at the right time, it had a lightweight implementation, was

The lightweight implementation clearly follows from the two
principles above -- C had very-lightweight, fast, portable
compilers early on for just the same reason.


Alex