Python's simplicity philosophy

[Douglas Alan]

"Dave Brueck" <dave at pythonapocrypha.com> writes:

> And I disagree that that's necessarily a Good Thing. Good language
> design is about finding that balance between general and
> specific. It's why I'm not a language designer and it's also why I'm
> a Python user.

It's surely the case that there's a balance, but if you assume that
your audience is too stupid to be able to be able to cope with

   reduce(add, seq)

instead of

   sum(seq)

then you are not finding the proper balance.

>> reduce() is more general and powerful than sum(), and would thus
>> clearly be preferred by my mantra.

> Yes, and eval() would clearly be preferred over them all.

And, damned right, eval() should stay in the language!

>> The mantra "there should be only one obvious way to do it" apparently
>> implies that one should remove powerful, general features like
>> reduce() from the language, and clutter it up instead with lots of
>> specific, tailored features like overloaded sum() and max().

> I completely disagree - I see no evidence of that. We're looking at
> the same data but drawing very different conclusions from it.

Well, that's the argument you seem to be making -- that reduce() is
superfluous because a sum() and max() that work on sequences were
added to the language.

>> I can already see what's going to happen with sum(): Ultimately,
>> people will realize that they may want to perform more general types
>> of sums, using alternate addition operations.

> Not gonna happen - this _might_ happen if Python was a design-by-committee
> language, but it's not.

According to Alex Martelli, max() and min() are likely to be extended
in this fashion.  Why not sum() next?

>> All of this falls out of "clean", "simple", and "elegant".

> Not at all - I cut my teeth on 6502 assembly and there is plenty
> that I still find clean, simple, and elegant about it, but it's
> horrible to program in.

I think we can both agree that not all of programming language design can
be crammed into a little mantra!

>> C'mon -- all reduce() is is a generalized sum or product.  What's
>> there to think about? It's as intuitive as can be.

> To you, perhaps. Not me, and not a lot of other people.

Well, perhaps you can explain your confusion to me?  What could
possibly be unintuitive about a function that is just like sum(), yet
it allows you to specify the addition operation that you want to use?

Of course, you can get the same effect by defining a class with your
own special __add__ operator, and then encapsulating all the objects
you want to add in this new class, and then using sum(), but that's a
rather high overhead way to accomplish the same thing that reduce()
lets you do very easily.

> I *like* the fact that there is someone making subjective
> judgement calls, even if it means I sometimes don't get my every wish.

Likewise.

> A good programming language is not the natural by-product of a series of
> purely objective tests.

>> And taught in every CS curiculum.

> Doubtful, and if it were universally true, it would weaken your point
> because many people still find it a foreign or awkward concept.

I doubt that anyone who has put any thought into it finds it a foreign
concept.  If they do, it's just because they have a knee-jerk reaction
and *want* to find it a foreign concept.

If you can cope with modular arithmetic, you can cope with the idea of
allowing people to sum numbers with their own addition operation!

> Besides, whether or not something is taught in a CS program is a
> really poor reason for doing anything.

No, it isn't.  CS is there for a reason, and one should not ignore the
knowledge it contains.  That doesn't mean that one should feel
compelled to repeat the mistakes of history.  But fear of that is no
reason not to accept its successes.  Those who don't, end up inventing
languages like Perl.

|>oug