Python's simplicity philosophy

[Douglas Alan]

BW Glitch <bwglitch at hotpop.com> writes:

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

> That's not what _I_ understand. There's room for powerful features,
> but when these features gives trouble to the people who just want
> something done, then another approach should be taken.

If there's a problem with people not understaning how to sum numbers
with reduce(), then the problem is with the documentation, not with
reduce() and the documentation should be fixed.  It is quite easy to
make this fix.  Here it is:

   FAQ
   ---
   Q: How do I sum a sequence of numbers?

   A: from operator import add
      reduce(add, seq)

Problem solved.

> And I'm not talking about stupid people. I'm talking about the
> microbiolgist/chemist/physics/etc who is programming because of
> need.

If a microbiologist cannot understand the above, they have no business
being a microbiologist.  I learned reduce() in high school, and it
didn't take me any longer than the 60 seconds I claim it will take
anyone with a modicum of intelligence.

>> If so, clearly this mantra is harmful, and will ultimately result
>> in Python becoming a bloated language filled up with "one obvious
>> way" to solve every particular idiom.  This would be very bad, and
>> make it less like Python and more like Perl.

> You feel ok? Perl's mantra is "More Than One Way To Do It"...

If both the mantras cause a language to have general features
replaced with a larger number of specialized features that accomplish
less, then both mantras are bad.

>> 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.  (For intance,
>> there may be a number of different ways that you might add together
>> vectors -- e.g, city block geometry vs. normal geometry.  Or you
>> may want to add together numbers using modular arithmetic, without
>> worrying about overflowing into bignums.)  So, a new feature will
>> be added to sum() to allow an alternate summing function to be
>> passed into sum().  Then reduce() will have effectively been put
>> back into the language, only its name will have been changed, and
>> its interface will have been changed so that everyone who has taken
>> CS-101 and knows off the top of their head what reduce() is and
>> does, won't easily be able to find it.

> I don't get you. There's a reason why special functions can be
> overloaded (__init__, __cmp__, etc.; I don't use others very
> often). That would allow for this kind of special
> treatments. Besides GvR would not accept your scenario.

There are often multiple different ways to add together the same data
types, and you wouldn't want to have to define a new class for each
way of adding.  For instance, you wouldn't want to have to define a
new integer class to support modular arithmetic -- you just want to
use a different addition operation.

> Also, whytf do you mention so much CS101?

Because anyone who has studied CS, which should include a significant
percentage of programmers, will know instantly where to look for the
summing function if it is called reduce(), but they won't necessarily
know to look for sum(), since languages don't generally have a
function called sum().  And everyone else will not know to look for
either, so they might as well learn a more powerful concept in the
extra 30 seconds it will take them.

> Maybe you took the course with LISP, assembly and Scheme, but AFAIK,
> not everyone has/had access to this course. Many people learned to
> program way before taking CS101.

As did, I, and I had no problem with reduce() when I learned it long
before I took CS-101.

> IMHO, you think that the only people that should make software
> is a CS major.

Did I say that?

>>>> To me, there is never *one* obviously "right way" to do anything

>>> Never? I doubt this very much. When you want to add two numbers in a
>>> programming language, what's your first impulse? Most likely it is
>>> to write "a + b".

>> Or b + a.  Perhaps we should prevent that, since that makes two
>> obviously right ways to do it!

> Even without any algebra, any kid can tell you that 1 + 2 is the same
> as 2 + 1. Replace 1 and 2 by a and b and you get the same result.

Yes, but they are still two *different* ways to to get to that result.
Starting with a and adding b to it, is not the same thing as starting
with b and adding a to it.  It is only the commutative law of
arithmetic, as any good second grade student can tell you, that
guarantees that the result will be the same.  On the other hand, not
all mathematical groups are albelian, and consequently, a + b != b + a
for all mathematical groups.

>> C'mon -- all reduce() is is a generalized sum or product.  What's
>> there to think about?  It's as intuitive as can be.  And taught in
>> every CS curiculum.  What more does one want out of a function?
>> |>oug

> It wasn't obvious for me until later. reduce() is more likely to be
> used for optimization. IIRC, some said that optimization is the root
> of all evil.

I don't know what you are getting at about "optimization".  Reduce()
exists for notational convenience--i.e., for certain tasks it is easer
to read, write, and understand code written using reduce() than it
would be for the corresponding loop--and understanding it is no more
difficult than understanding that a summing function might let you
specify the addition operation that you'd like to use, since that's
all that reduce() is!

> Just because it's _obvious_ to you, it doesn't mean it's obvious to
> people who self taught programming.

It was obvious to me when I was self-taught and I taught myself APL in
high-school.  It also seemed obvious enough to all the physicists who
used APL at the lab where I was allowed to hang out to teach myself
APL.

|>oug