Python's simplicity philosophy

[BW Glitch]

Douglas Alan wrote:

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

You are assuming way too much. Documentation is meant to clarify what a 
function does, not a tutorial on what a function is. That's why your 
CS101 professor should have taught you that the name of the function 
should state what the function does. sum() states clearly that it is 
meant to sum something (a connection is made with numbers, because 
that's what most people associate numbers). reduce(), OTOH, states 
nothing, it reduces. But what? Why should I care for a function that 
isn't clear?

>    FAQ
>    ---
>    Q: How do I sum a sequence of numbers?
> 
>    A: from operator import add
>       reduce(add, seq)
> 
> Problem solved.
> 

A: Guru.

Q: How a user that reads the manual is called?

;)

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

Why should he? Because he could care less about a function called 
reduce()? Because he just want to do his job, regardless on how a CS 
expert does it? Because he didn't learned LISP as his first language?

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

Please, get your fact straights.

Do you know that people learn in different ways? Just because you 
learned something one way doesn't mean everyone else should learn it 
(and understand it) the same way you do.

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

Mantras are cute names for design decisions (I know, mantras doesn't 
mean that, but in these context). When designing something, certain 
compromises must be made. Guido van Rossum (GvR or BDFL) made some 
decisions early on and have stayed with Python ever since. Good or bad, 
we have to stick with the decisions. Why? Because each decision 
represents a solution from many to a single problem. If we start making 
exceptions to the decision, the decision should be rethought. But more 
importantly, if it works, don't fix it.

Unless you go by the engineering mantra...

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

Define a class then. What you are describing is a specific case which 
most people don't face in everyday problems. If you have a set of tools, 
try to use the best combination for the given tool. If all you have is a 
hammer, everything start looking like a nail. ;) If you have to program 
in Java, everything start looking like a class.

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

False. Programmers come from many sources. Restraining yourself to CS 
people is bad enough. As Alex Martelli mentioned in another post of this 
thread, power should be demonstrable. It's quite amusing that no one has 
showed an example of the power of reduce() (by itself, not its side 
effects).

[snip]
>>IMHO, you think that the only people that should make software
>>is a CS major.
> 
> 
> Did I say that?

You didn't. But I infere that from what you've said in this thread.

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

This might be the case IF we were talking about Matlab/Octave, which are 
languages design towards mathematics.

This would be the case of concatenating strings ('Hello ' + 'World! ' <> 
'World! ' + 'Hello '), but you should expect that to happen.

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

Optimization was from somenone else in the thread whom I might 
misunderstood.

It's still not obvious. You need to understand 1) whattf does reduce() 
do and how, 2) what does the function passed does and 3) what the array 
is about.

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

Well, I learned TI-BASIC, C, C++ and then went on to learn Scheme, 
Prolog and Python. Most of these during the last 6 years. Have I missed 
something because I didn't know how to use reduce()? No. And more 
importantly, what is a real life scenario where I should go with 
reduce() instead of a loop? From what you've said, the only reason to 
use reduce() is to show mere mortals that I know how to use reduce(). 
Besides that, Martelli have pointed that it provides no advantage what 
so ever. And readability suffers because of the high abuse of this function.

-- 
Andres Rosado

-----BEGIN TF FAN CODE BLOCK-----
G+++ G1 G2+ BW++++ MW++ BM+ Rid+ Arm-- FR+ FW-
#3 D+ ADA N++ W OQP MUSH- BC- CN++ OM P75
-----END TF FAN CODE BLOCK-----

A plague upon all their houses!
         -- Scourge (BW)