Home Original page

Python's simplicity philosophy

Douglas Alan nessus at mit.edu
Tue Nov 11 17:56:06 EST 2003 
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
sum(), only with reduce() you can specify whatever addition function
you would like."

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

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

> 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
is "small, clean, simple, general, powerful, elegant", then clearly
there will come times when one must ponder on a trade-off between, for
example, elegant and powerful.  But if you end up going and removing
elegant features understood by anyone who has studied Computer Science
because you think your audience is too dumb to make a slight leap from
the specific to the general that can be explained on one simple
sentence, then you are making those trade-off decisions in the
*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.

> But not with the parts that I quoted from the "spirit of C", and I
> repeat them because they were SO crucial in the success of C as a
> lower-level language AND are similarly crucial in the excellence of
> Python as a higher-level one -- design principles that are *VERY*
> rare among computer languages and systems, by the way:

I sure hope that Python doesn't try to emulate C.  It's a terrible,
horrible programming language that held back the world of software
development by at least a decade.

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

The reason for Python's wide acceptance isn't because it is
particularly well-designed compared to other programming languages
that had similar goals of simplicity and minimality (it also isn't
poorly designed compared to any of them -- it is on par with the
better ones) -- the reason for its success is that it was in the right
place at the right time, it had a lightweight implementation, was
well-suited to scripting, and it came with batteries included.

|>oug
More information about the Python-list mailing list