reduce() anomaly?

[Anton Vredegoor]

Re: Python's simplicity philosophy

David Eppstein <eppstein@ics.u ci.edu> wrote:
[color=blue]
>The argument is that reduce is usually harder to read than the loops it
>replaces, and that practical examples of it other than sum are sparse
>enough that it is not worth keeping it just for the sake of
>functional-language purity.[/color]

One argument in favor of reduce that I haven't seen anywhere yet is
that it is a kind of bottleneck. If I can squeeze my algorithm through
a reduce that means that I have truly streamlined it and have removed
superfluous cruft. After having done that or other code mangling
tricks -like trying to transform my code into a one liner- I usually
have no mental problems refactoring it back into a wider frame.

So some things have a use case because they require a special way of
thinking, and impose certain restrictions on the flow of my code.
Reduce is an important cognitive tool, at least it has been such for
me during a certain time frame, because nowadays I can often go
through the mental hoop without needing to actually produce the code.
I would be reluctant to deny others the chance to learn how not to use
it.

Anton

[Alex Martelli]

Re: reduce()--what is it good for? (was: Re: reduce() anomaly?)

Bob Gailer wrote:
...[color=blue]
> The use of zip(seq[1:], [:-1]) to me is more obscure, and[/color]

Very obscure indeed (though it's hard to say if it's _more_ obscure without
a clear indication of what to compare it with). Particularly considering
that it's incorrect Python syntax, and the most likely correction gives
probably incorrect semantics, too, if I understand the task (give windows
of 2 items, overlapping by one, on seq?).
[color=blue]
> memory/cpu-expensive in terms of creating 3 new lists.[/color]

Fortunately, Hettinger's splendid itertools module, currently in Python's
standard library, lets you perform this windowing task without creating any
new list whatsoever.

Wen seq is any iterable, all you need is izip(seq, islice(seq, 1, None)),
and you'll be creating no new list whatsoever. Still, tradeoffs in
obscurity (and performance for midsized lists) are quite as clear.


Alex

[Douglas Alan]

Re: Python's simplicity philosophy

"Dave Brueck" <dave@pythonapo crypha.com> writes:
[color=blue][color=green]
>> Of course I am not joking. I see no good coming from the mantra, when
>> the mantra should be instead what I said it should be:[/color][/color]
[color=blue][color=green]
>> "small, clean, simple, powerful, general, elegant"[/color][/color]
[color=blue]
> It's really a matter of taste - both "versions" mean about the same to me
> (and to me both mean "get rid of reduce()" ;-) ).[/color]

No, my mantra plainly states to keep general and powerful features
over specific, tailored features. reduce() is more general and
powerful than sum(), and would thus clearly be preferred by my
mantra.

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

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.

Yes, there are other parts of The Zen of Python that point to the
powerful and general, rather than the clutter of specific and
tailored, but nobody seems to quote them these days, and they surely
are ignoring them when they want to bloat up the language with
unneccessary features like overloaded sum() and max() functions,
rather than to rely on trusty, powerful, and elegant reduce(), which
can easily and lightweightedly do everything that overloaded sum() and
max() can do and quite a bit more.
[color=blue][color=green]
>> To me, there is never *one* obviously "right way" to do anything[/color][/color]
[color=blue]
> 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".[/color]

Or b + a. Perhaps we should prevent that, since that makes two
obviously right ways to do it!
[color=blue]
> Having said that though, part of the appeal of Python is that it hits the
> nail on the head surprisingly often: if you don't know (from prior
> experience) how to do something in Python, your first guess is very often
> correct. Correspondingly , when you read someone else's Python code that uses
> some feature you're not familiar with, odds are in your favor that you'll
> correctly guess what that feature actually does.[/color]

All of this falls out of "clean", "simple", and "elegant".
[color=blue]
> And that is why I wouldn't be sad if reduce() were to disappear - I don't
> use reduce() and _anytime_ I see reduce() in someone's code I have to slow
> way down and sort of rehearse in my mind what it's supposed to do and see if
> I can successfully interpret its meaning (and, when nobody's looking, I
> might even replace it with a for-loop!).[/color]

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

[David Eppstein]

Re: reduce()--what is it good for? (was: Re: reduce() anomaly?)

In article <%Fcsb.10225$hV .422723@news2.t in.it>,
Alex Martelli <aleaxit@yahoo. com> wrote:
[color=blue][color=green]
> > The use of zip(seq[1:], [:-1]) to me is more obscure, and[/color]
>
> Very obscure indeed (though it's hard to say if it's _more_ obscure without
> a clear indication of what to compare it with). Particularly considering
> that it's incorrect Python syntax, and the most likely correction gives
> probably incorrect semantics, too, if I understand the task (give windows
> of 2 items, overlapping by one, on seq?).
>[color=green]
> > memory/cpu-expensive in terms of creating 3 new lists.[/color]
>
> Fortunately, Hettinger's splendid itertools module, currently in Python's
> standard library, lets you perform this windowing task without creating any
> new list whatsoever.
>
> Wen seq is any iterable, all you need is izip(seq, islice(seq, 1, None)),
> and you'll be creating no new list whatsoever. Still, tradeoffs in
> obscurity (and performance for midsized lists) are quite as clear.[/color]

If I'm not mistaken, this is buggy when seq is an iterable, and you need
to do something like
seq1,seq2 = tee(seq)
izip(seq1,islic e(seq2,1,None))
instead.

--
David Eppstein http://www.ics.uci.edu/~eppstein/
Univ. of California, Irvine, School of Information & Computer Science

[Jeremy Fincher]

Re: Python's simplicity philosophy

Douglas Alan <nessus@mit.edu > wrote in message news:<lc4qxau8h 7.fsf@gaffa.mit .edu>...[color=blue]
> Well, perhaps anything like "only one way to do it" should be removed
> from the mantra altogether, since people keep misquoting it in order
> to support their position of removing beautiful features like reduce()
> from the language.[/color]

I don't know what your definition of beautiful is, but reduce is the
equivalent of Haskell's foldl1, a function not even provided by most
of the other functional languages I know. I can't see how someone
could consider it "beautiful" to include a rarely-used and
limited-extent fold and not provide the standard folds.

You want to make Python into a functional language? Write a
functional module. foldl, foldr, etc; basically a copy of the Haskell
List module. That should give you a good start, and then you can use
such facilities to your heart's content.

Me? I love functional programming, but in Python I'd much rather read
a for loop than a reduce or probably even a fold. Horses for courses,
you know?

Jeremy

[Douglas Alan]

Re: Python's simplicity philosophy

Alex Martelli <aleax@aleax.it > writes:
[color=blue][color=green]
>> no disagreement, reduce is in line with that philosophy sum is a
>> shortcut and as others have said is less general.[/color][/color]
[color=blue]
> 'sum' is _way simpler_: _everybody_ understands what it means to sum a
> bunch of numbers, _without_ necessarily having studied computer science.[/color]

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."
[color=blue]
> 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],[/color]

Then you weren't taught Computer Science -- you were taught Fortran
programming. Computer Science teaches general concepts, not specific
languages.
[color=blue]
> 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].[/color]

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.)
[color=blue]
> Python's purpose is not, and has never been, to maximize the generality
> of the constructs it offers.[/color]

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.
[color=blue]
> 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:[/color]

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.
[color=blue]
> Keep the language small and simple.[/color]
[color=blue]
> Provide only one way to do an operation.[/color]

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

[Dave Brueck]

Re: Python's simplicity philosophy

> >> Of course I am not joking. I see no good coming from the mantra, when[color=blue][color=green][color=darkred]
> >> the mantra should be instead what I said it should be:[/color][/color]
>[color=green][color=darkred]
> >> "small, clean, simple, powerful, general, elegant"[/color][/color]
>[color=green]
> > It's really a matter of taste - both "versions" mean about the same to[/color][/color]
me[color=blue][color=green]
> > (and to me both mean "get rid of reduce()" ;-) ).[/color]
>
> No, my mantra plainly states to keep general and powerful features
> over specific, tailored features.[/color]

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.
[color=blue]
> reduce() is more general and
> powerful than sum(), and would thus clearly be preferred by my
> mantra.[/color]

Yes, and eval() would clearly be preferred over them all.
[color=blue]
> 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().[/color]

I completely disagree - I see no evidence of that. We're looking at the same
data but drawing very different conclusions from it.
[color=blue]
> 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.[/color]

Not gonna happen - this _might_ happen if Python was a design-by-committee
language, but it's not.
[color=blue]
> Yes, there are other parts of The Zen of Python that point to the
> powerful and general, rather than the clutter of specific and
> tailored, but nobody seems to quote them these days,[/color]

'not quoting' != 'not following'
and
'what gets debated on c.l.py' != 'what the Python developers do'
[color=blue][color=green]
> > Having said that though, part of the appeal of Python is that it hits[/color][/color]
the[color=blue][color=green]
> > nail on the head surprisingly often: if you don't know (from prior
> > experience) how to do something in Python, your first guess is very[/color][/color]
often[color=blue][color=green]
> > correct. Correspondingly , when you read someone else's Python code that[/color][/color]
uses[color=blue][color=green]
> > some feature you're not familiar with, odds are in your favor that[/color][/color]
you'll[color=blue][color=green]
> > correctly guess what that feature actually does.[/color]
>
> All of this falls out of "clean", "simple", and "elegant".[/color]

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.
[color=blue][color=green]
> > And that is why I wouldn't be sad if reduce() were to disappear - I[/color][/color]
don't[color=blue][color=green]
> > use reduce() and _anytime_ I see reduce() in someone's code I have to[/color][/color]
slow[color=blue][color=green]
> > way down and sort of rehearse in my mind what it's supposed to do and[/color][/color]
see if[color=blue][color=green]
> > I can successfully interpret its meaning (and, when nobody's looking, I
> > might even replace it with a for-loop!).[/color]
>
> C'mon -- all reduce() is is a generalized sum or product. What's
> there to think about? It's as intuitive as can be.[/color]

To you, perhaps. Not me, and not a lot of other people. To be honest I don't
really care that it's in the language. I'm not dying to see it get
deprecated or anything, but I do avoid it in my own code because it's
non-obvious to me, and if it were gone then Python would seem a little
cleaner to me.

Obviously what is intuitive to someone is highly subjective - I was really
in favor of adding a conditional operator to Python because to me it _is_
intuitive, clean, powerful, etc. because of my previous use of it in C. As
much as I wanted to have it though, on one level I'm really pleased that a
whole lot of clamoring for it did not result in its addition to the
language. I *like* the fact that there is someone making subjective
judgement calls, even if it means I sometimes don't get my every wish.

A good programming language is not the natural by-product of a series of
purely objective tests.
[color=blue]
> And taught in
> every CS curiculum.[/color]

Doubtful, and if it were universally true, it would weaken your point
because many people still find it a foreign or awkward concept. Besides,
whether or not something is taught in a CS program is a really poor reason
for doing anything.

-Dave

[Douglas Alan]

Re: Python's simplicity philosophy

"Dave Brueck" <dave@pythonapo crypha.com> writes:
[color=blue]
> 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.[/color]

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.
[color=blue][color=green]
>> reduce() is more general and powerful than sum(), and would thus
>> clearly be preferred by my mantra.[/color][/color]
[color=blue]
> Yes, and eval() would clearly be preferred over them all.[/color]

And, damned right, eval() should stay in the language!
[color=blue][color=green]
>> 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().[/color][/color]
[color=blue]
> I completely disagree - I see no evidence of that. We're looking at
> the same data but drawing very different conclusions from it.[/color]

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.
[color=blue][color=green]
>> 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.[/color][/color]
[color=blue]
> Not gonna happen - this _might_ happen if Python was a design-by-committee
> language, but it's not.[/color]

According to Alex Martelli, max() and min() are likely to be extended
in this fashion. Why not sum() next?
[color=blue][color=green]
>> All of this falls out of "clean", "simple", and "elegant".[/color][/color]
[color=blue]
> 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.[/color]

I think we can both agree that not all of programming language design can
be crammed into a little mantra!
[color=blue][color=green]
>> C'mon -- all reduce() is is a generalized sum or product. What's
>> there to think about? It's as intuitive as can be.[/color][/color]
[color=blue]
> To you, perhaps. Not me, and not a lot of other people.[/color]

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.
[color=blue]
> I *like* the fact that there is someone making subjective
> judgement calls, even if it means I sometimes don't get my every wish.[/color]

Likewise.
[color=blue]
> A good programming language is not the natural by-product of a series of
> purely objective tests.[/color]
[color=blue][color=green]
>> And taught in every CS curiculum.[/color][/color]
[color=blue]
> Doubtful, and if it were universally true, it would weaken your point
> because many people still find it a foreign or awkward concept.[/color]

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!
[color=blue]
> Besides, whether or not something is taught in a CS program is a
> really poor reason for doing anything.[/color]

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

[Andrew Dalke]

Re: Python's simplicity philosophy

Douglas Alan:[color=blue]
> Then you weren't taught Computer Science -- you were taught Fortran
> programming. Computer Science teaches general concepts, not specific
> languages.[/color]

I agree with Alex on this. I got a BS in CS but didn't learn about
lambda, reduce, map, and other aspects of functional programming
until years later, and it still took some effort to understand it.
(Granted,
learning on my own at that point.)

But I well knew what 'sum' did.

Was I not taught Computer Science? I thought I did pretty well
on the theoretical aspects (state machines, automata, discrete math,
algorithms and data structures). Perhaps my school was amiss in
leaving it out of the programming languages course, and for
teaching its courses primarily in Pascal. In any case, it contradicts
your assertion that anyone who has studied CS knows what
reduce does and how its useful.
[color=blue]
> 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.)[/color]

Strangely enough, I didn't see an entry for 'functional programming'
in Knuth's "The Art of Computer Programming" -- but that's just
programming. ;)
[color=blue]
> But if you end up going and[/color]
removing[color=blue]
> 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.[/color]

Your predicate (that it's understood by anyone who has studied
CS) is false so your argument is moot. In addition, I deal with a
lot of people who program but didn't study CS. And I rarely
use reduce in my code (even rarer now that 'sum' exists) so would
not miss its exclusion or its transfer from builtins to a module.

Andrew
dalke@dalkescie ntific.com

[Patrick Maupin]

Re: Python's simplicity philosophy

Douglas Alan wrote:
[color=blue]
> 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."[/color]

Maybe reduce() can be explained in 10 seconds to someone who has used
sum() a few times, but that has no bearing whatsoever on trying to
explain reduce() to someone if sum() is not available and hasn't
been used by them.
[color=blue][color=green]
> > 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].[/color]
>
> 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.)[/color]

I'm sorry, but from a pure CS viewpoint, reduce() is way off the
radar screen. Especially for a 101 course. If either of my daughters
wanted to discuss reduce() while taking such a course, I'd want to
see the curriculum to figure out what they _weren't_ being taught.
[color=blue]
> You should be assuming that your audience are the smart people
> that they are, rather than the idiots you are assuming them to be.[/color]

Ignorance is not stupidity. I have yet to see a language which
can be used by stupid people with consistent success; however I
have seen a great deal of evidence that Python can be used very
successfully by ignorant people. It gently eases them in and
allows them to perform useful work while slowly reducing their
ignorance.
[color=blue]
> 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.[/color]

I used to hate C. But then, when it borrowed enough good concepts
from Pascal and other languages, and the compilers got smart enough
to warn you (if you cared to see the warnings) about things like
"if (x = y)" I stopped using Modula-2. C held software back 10
years in the same manner as Microsoft did, e.g. by helping to
standardize things to where I can buy a $199 system from WalMart
which would cost over $20,000 if everybody kept writing code like
the pointy-headed ivory tower academics thought it ought to be written.
For certain problem domains (where domain includes the entire system
of software, hardware, real-time constraints, portability, user
expectations, maintainability by a dispersed team, etc.), C is an
excellent implementation language. But don't take my word for it --
open your eyes and look around. Could there be a better implementation
language? Sure. Would C acquire the bare minimum features needed
to compete with the new language? Absolutely.

(But I freely admit I'm a luddite: I prefer Verilog to VHDL, as well.)
[color=blue]
> 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.[/color]

I'd vote this as the statement in this group most likely to start
a religious flamewar since the lisp threads died down.

I'm not particularly religious, but I _will_ bite on this one:

1) In what way was it at the "right place at the right time?" You
didn't name names of other languages, but I'll bet that if you can
name 5 which are similar by your criteria, at least two of them
were available when Python first came out.

2) What part of "lightweigh t implementation, well suited to scripting"
contradicts, or is even merely orthorgonal to "particular ly well-designed"?

3) Do you _really_ think that all the batteries were included when
Python first came out? Do you even think that Python has more batteries
_right_ _now_ than Perl (via CPAN), or that some competing language
couldn't or hasn't already been designed which can coopt other languages'
batteries?

I can accept the premise that, for Python to enjoy the acceptance
it does today, Guido had to be lucky in addition to being an excellent
language designer. But if I were to accept the premise that Python's
popularity is due to sheer luck alone, my only logical course of action
would to be to buy Guido a plane ticket to Vegas and front him $10,000
worth of chips, because he has been extremely lucky for many years now.

Pat

[Michele Simionato]

Re: Python's simplicity philosophy

Douglas Alan <nessus@mit.edu > wrote in message news:<lcvfpqsgs k.fsf@gaffa.mit .edu>...[color=blue]
> 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[/color]

Others pointed out that 'reduce' is not taught in every CS curriculum
and that many (most?) programmers didn't have a CS curriculum as you
intend it, so let me skip on this point. The real point, as David Eppstein
said, is readability:

reduce(operator .add, seq)

is not readable to many people, even if is readable to you.
That's the only reason why I don't use 'reduce'. I would have preferred
a better 'reduce' rather than a new ad hoc 'sum': for instance something
like

reduce([1,2,3],'+')

in which the sequence goes *before* the operator. It is interesting to
notice that somebody recently suggested in the Scheme newsgroup that

(map function sequence)

was a bad idea and that

(map sequence function)

would be better!

Of course, I do realize that there is no hope of changing 'reduce' or 'map'
at this point; moreover the current trend is to make 'reduce' nearly
useless, so I would not complain about its dead in Python 3.0.
Better no reduce than an unreadable reduce.

Also, I am not happy with 'sum' as it is, but at least it is
dead easy to read.

Michele Simionato

[Michele Simionato]

Re: Python's simplicity philosophy

Douglas Alan <nessus@mit.edu > wrote in message news:<lcsmkusee x.fsf@gaffa.mit .edu>...[color=blue]
> 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.
>[/color]

.... and it is free!!! ;)

More seriously, the fact that it has a standard implementation and a
BDFL ensuring the consistency of the language (not committee for Python!)
is also a big plus. Moreover, it got a good documentation, a very active
community and a wonderful newgroup. Also, the time scale between the
submission of a bug (there are very few of them, BTW) and its fixing
is surprisingly short. This is something I value a lot. Finally, the
language is still evolving at fast pace and you feel the sensation
that is has a future. Probably the same things can be said for Ruby
and Perl, so you have a choice if you don't like the Zen of Python ;)

Michele Simionato

[Georgy Pruss]

Re: Python's simplicity philosophy


"Michele Simionato" <mis6@pitt.ed u> wrote in message news:2259b0e2.0 311112248.3be2d 304@posting.goo gle.com...
| <...>
| in which the sequence goes *before* the operator. It is interesting to
| notice that somebody recently suggested in the Scheme newsgroup that
|
| (map function sequence)
|
| was a bad idea and that
|
| (map sequence function)
|
| would be better!
|
| <...>

Yes, that's right. Some scientific studies proved that humans think and
express their thoughts in order subject/object-action. So OOP is very
"human" in this aspect, btw.

G-:

[Robin Becker]

Re: Python's simplicity philosophy

In article <17lsb.109042$f l1.4548960@twis ter.southeast.r r.com>, Georgy
Pruss <SEE_AT_THE_END @hotmail.com> writes[color=blue]
>
>"Michele Simionato" <mis6@pitt.ed u> wrote in message news:2259b0e2.0 311112248.3b
>e2d304@posting .google.com...
>| <...>
>| in which the sequence goes *before* the operator. It is interesting to
>| notice that somebody recently suggested in the Scheme newsgroup that
>|
>| (map function sequence)
>|
>| was a bad idea and that
>|
>| (map sequence function)
>|
>| would be better!
>|
>| <...>
>
>Yes, that's right. Some scientific studies proved that humans think and
>express their thoughts in order subject/object-action. So OOP is very
>"human" in this aspect, btw.
>
>G-:
>
>[/color]
on oop in this thread nobody has pointed out that we could have

sequence.sum()
sequence.reduce (operator.add[,init])

or even

sequence.filter (func) etc etc

and similar. That would make these frighteningly incomprehensibl e ;)
concepts seem less like functional programming. Personally I wouldn't
like that to happen.
--
Robin Becker

[Douglas Alan]

Re: Python's simplicity philosophy

pmaupin@speakea sy.net (Patrick Maupin) writes:
[color=blue]
> Douglas Alan wrote:[/color]
[color=blue][color=green]
>> 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."[/color][/color]
[color=blue]
> Maybe reduce() can be explained in 10 seconds to someone who has used
> sum() a few times, but that has no bearing whatsoever on trying to
> explain reduce() to someone if sum() is not available and hasn't
> been used by them.[/color]

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

"To add a sequence of numbers together:

reduce(add, seq)

To multiply a sequence of numbers together:

reduce(mul, seq)

To subtract all of the numbers of a sequence (except the first
number) from the first number of the sequence:

reduce(sub, seq)

To divide the first number in a sequence by all the remaining
numbers in the sequence:

reduce(div, seq)

Any two-argument function can be used in place of add, mul, sub, or
div and you'll get the appropriate result. Other interesting
examples are left as an exercise for the reader."


If someone can't understand this quickly, then they shouldn't be
programming!
[color=blue]
> I'm sorry, but from a pure CS viewpoint, reduce() is way off the
> radar screen. Especially for a 101 course.[/color]

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()!
[color=blue][color=green]
>> You should be assuming that your audience are the smart people
>> that they are, rather than the idiots you are assuming them to be.[/color][/color]
[color=blue]
> Ignorance is not stupidity.[/color]

Assuming that your audience cannot learn the simplest of concepts is
assuming that they are stupid, not that they are ignorant.
[color=blue][color=green]
>> 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.[/color][/color]
[color=blue]
> I used to hate C. But then, when it borrowed enough good concepts
> from Pascal and other languages, and the compilers got smart enough
> to warn you (if you cared to see the warnings) about things like
> "if (x = y)" I stopped using Modula-2. C held software back 10
> years in the same manner as Microsoft did, e.g. by helping to
> standardize things to where I can buy a $199 system from WalMart
> which would cost over $20,000 if everybody kept writing code like
> the pointy-headed ivory tower academics thought it ought to be written.[/color]

You score no points for C by saying that it is like Microsoft. That's
a strong damnation in my book. And you really don't know how the
world would have turned out if a different programming language had
been adopted rather than C for all those years. Perhaps computers
would be more expensive today, perhaps not. On the other hand, we
might not have quite so many buffer overflow security exploits.
Perhaps we'd have hardware support for realtime GC, which might be
very nice. On the other hand, perhaps people would have stuck with
assembly language for developing OS's. That wouldn't have been so
pretty, but I'm not sure that that would have made computers more
expensive. Perhaps a variant of Pascal or PL/1 would have taken the
niche that C obtained. Either of those would have been better, though
no great shakes either.

Many of the pointy-headed ivory tower academics, by the way, thought
that code should look something like Python. The reason these
languages are not widely used is because typically they either did not
come with batteries, or there was no lightweight implmentation
provided, or they only ran on special hardware, or all of the above.
[color=blue][color=green]
>> 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.[/color][/color]
[color=blue]
> I'd vote this as the statement in this group most likely to start
> a religious flamewar since the lisp threads died down.[/color]

The only way it could start a religious flamewar is if there are
people who wish to present themselves as fanboys. I have said nothing
extreme -- just what is obvious: There are many nice computer
programming languages -- Python is but one of them. If someone
wishes to disagree with this, then they would have to argue that there
are no other nice programming languages. Now that would be a flame!
[color=blue]
> I'm not particularly religious, but I _will_ bite on this one:[/color]
[color=blue]
> 1) In what way was it at the "right place at the right time?"[/color]

Perl was in the right place at the right time because system
administrators had gotten frustrated with doing all their scripts in a
mishmash of shell, awk, sed, and grep, etc. And then web-scripting
kicked Perl into even more wide acceptance. Python was in the right
place in the right time because many such script-writers (like yours
truly) just could not stomach Perl, since it is an ugly monstrocity,
and Python offered such people relief from Perl. If Perl had been a
sane OO language, Python would never have had a chance.
[color=blue]
> You didn't name names of other languages, but I'll bet that if you
> can name 5 which are similar by your criteria, at least two of them
> were available when Python first came out.[/color]

I'm not sure what you are getting at. There were many nice
programming languages before Python, but not many of them, other than
Perl, were portable and well-suited to scripting.

Oh, yeah, I forgot to mention portability in my list of reasons why
Python caught on. That's an essential one. Sure you could elegantly
script a Lisp Machine with Lisp, and some Xerox computers with
Smalltalk, but they didn't provide versions of these languages
well-suited for scripting other platforms.
[color=blue]
> 2) What part of "lightweigh t implementation, well suited to
> scripting" contradicts, or is even merely orthorgonal to
> "particular ly well-designed"?[/color]

Again, I'm not sure what you are getting at. "Lightweigh t
implementation" and "well-suited to scripting" do not contradict
"well-designed", as Python proves. Lightweightedne ss and capability
at scripting are certainly orthogonal to the property of being
well-designed, however, since there are a plethora of well-designed
languages that are not suited to scripting. They just weren't
designed to address this niche.
[color=blue]
> 3) Do you _really_ think that all the batteries were included when
> Python first came out?[/color]

It certainly was not a particularly popular language until it came
with pretty hefty batteries. There are many other languages that
would have been equally popular before Python started coming with
batteries.
[color=blue]
> Do you even think that Python has more batteries _right_ _now_ than
> Perl (via CPAN), or that some competing language couldn't or hasn't
> already been designed which can coopt other languages' batteries?[/color]

Um, the last time I checked Perl was still a lot more popular than
Python, so once again I'm not sure what you are getting at. Regarding
whether or not some future language might also come with batteries and
therefore steal away Python's niche merely due to having more
batteries: Anything is possible, but this will be an uphill battle for
another language because once a language takes a niche, it is very
difficult for the language to be displaced. On the other hand, a new
language can take over a sub-niche by providing more batteries in a
particular area. PHP would be an example of this.
[color=blue]
> I can accept the premise that, for Python to enjoy the acceptance it
> does today, Guido had to be lucky in addition to being an excellent
> language designer. But if I were to accept the premise that
> Python's popularity is due to sheer luck alone my only logical
> course of action would to be to buy Guido a plane ticket to Vegas
> and front him $10,000 worth of chips, because he has been extremely
> lucky for many years now.[/color]

I never claimed *anything* like the assertion that Python's popularity
is due to luck alone!

|>oug