Python's simplicity philosophy

[Douglas Alan]

pmaupin at speakeasy.net (Patrick Maupin) writes:

> Douglas Alan wrote:

>> Describing reduce() in 10 seconds is utterly trivial to anyone with an
>> IQ above 100, whether or not they have ever used sum()

> Well, yeah, but they may not need or want to learn or remember it.
> And then there are the corner cases, e.g. sum([]) vs.
> reduce(operator.add,[]) (which throws an exception).

>> If someone can't understand this quickly, then they shouldn't be
>> programming!

> Again, it's not "can't", it's whether they need to or not.

If you don't want to learn a cool concept that will only take you 60
seconds to learn, then you shouldn't be programming!  Or you can stick
to loops.

The argument that some programmers might be too lazy to want to learn
powerful, simple, and elegant features that can be taught in seconds,
is no good reason to remove such features from Python and bloat Python
by replacing them with a plethora of less powerful, less elegant
features.

>> I'm sorry, but you are incorrect.  When I took CS-101, we learned
>> assembly language, then were assigned to write a text editor in
>> assembly language, then we learned LISP and were assigned to write
>> some programs in LISP, and then we learned C, and then we were
>> assigned to implement LISP in C.

>> If you can write a !$#@!!%# LISP interpreter in C, you no doubt can
>> figure out something as mind-achingly simple as reduce()!

> Ahh, the lisp background.  I _knew_ that would come out sometime :)

Knowing about reduce() doesn't come from a LISP background, since it
is uncommon to use reduce() in LISP.  There are few binary operators
in LISP, so instead of doing reduce(+, seq), in LISP, you would
typically do apply(+, seq).  Knowing about reduce() comes from the
part of your CS education in which they give you a small taste of what
it is like to program in a purely combinator-based style.  E.g., you
might have a problem set where they ask you to solve the same problem
in three different ways: (1) using iteration, (2) using recursion, (3)
using only combinators.

Besides, if you weren't exposed at all to LISP (or a LISP-like
language) while getting a CS degree, it wasn't a very good CS
program!  They're going to teach you AI techniques in a different
language?  That would be rather silly.

> As I and others have pointed out, it's not a matter of assuming they
> can't learn, it's a matter of assuming they have better things to
> do.  Many people can write all the useful programs they will ever
> need without reduce, and sum() makes the percentage of Python
> users who can do this even higher.

And as I have pointed out, it goes against the principle of simplicity
and expressiveness to remove an easy to use and easy to learn simple
and powerful feature with a slew of specific, tailored features.  If
reduce() can be relegated to a library or for the user to implement
for himself, then so can sum().  If the language is to only have one,
it should be reduce().

> I agree that I cannot know how the world would have turned out
> without C and Microsoft; but likewise, you cannot know for sure
> that computer science would be ten years farther along by now :)

I didn't say it held back Computer Science -- Computer Science went
along fine.  I said it held back software development.

That's not to say that something else wouldn't have taken C's place in
holding back software development, but, in that case, I'd be railing
against that instead.

> Here is one area where I think the genius of the design shows
> through.  Even _before_ the batteries were included, in a crowded
> field of other languages, Python was good enough to acquire enough
> mindshare to start the snowball rolling, by attracting the kind of
> people who can actually build batteries.

I think that Python always came with batteries, since it was designed
to be the scripting language for an OS called Amoeba that Guido was
working on.  There were precious few other well-designed,
well-implemented languages around that the time that were aimed at
being scripting languages (and didn't run only on Lisp machines or
what have you).

|>oug