UserLinux chooses Python as "interpretive language" of choice

[Skip Montanaro]

    John> On the other hand, claiming that sum() is an adequate replacement
    John> for reduce() is so silly that it borders on the absurd. 

    >> No, operationally that's a correct statement.  People have looked at
    >> the use of reduce() in a number of different contexts.  In all but
    >> the rarest of cases, reduce() was used to sum a list of numbers.
    >> sum() is a perfectly adequate replacement in all but those rare cases
    >> and is easier to read as well.  As Guido mentioned in the talk I
    >> referenced above:
    >> 
    >> reduce()
    >>     nobody uses it,  few understand it
    >>     a for loop is clearer & (usually) faster

    HV> I think no one even tries to understand the very concept of reducing
    HV> sequence to a single object using a rule . Sum is not a replacement
    HV> of this *concept*.  Just what is so wrong with having such a general
    HV> tool available in a programming language ? Doesn't it hurt to
    HV> understand how to use it?

It doesn't hurt to understand the concept of reduce(), but if it's never (or
very rarely) used, it's just extra (nearly dead) code which has to be
maintained.  It's easy enough to write reduce() in Python, and if/when PyPy
is a reality shouldn't be any less efficient than the current C version.

    >> No, it's simply not used very much.  Python never has been a very
    >> strong functional language.  It's always been a very strong
    >> object-oriented language.  Use it the way it's strongest.

    HV> I think Guido should put his money where his mouth is and simply
    HV> eliminate functions as first class objects then !

There are lots of use cases for functions as first class objects which don't
intersect with the usual notions of functional programming.  Here's one
rather silly example:

    l = []
    append = l.append
    for i in range(25):
        append(i)

Another less silly example is os.walk().  It's in some sense a specialized
map() function, so does overlap a bit more with the usual notion of
functional programming.

    HV> If python ever gets very fast, people will reimplement things like
    HV> reduce in their own code or in a functional module.

As well they should.  It's a five-liner in Python.  I've never used it for
anything but summing a list of numbers.  That appears to be true of most
people.

    John> There is no replacement for lambda in sight, even though lambda is
    John> arguably the ***largest single*** one of the functional constructs
    John> that needs work, and has obviously needed work for a long time.

    >> Once again, you desire Python to be something it is not.  If you want
    >> a strong functional language, program in Lisp or Haskell.

    HV> Functions are supposedly first class, regular objects in python. Why
    HV> can't they be sometimes anonymous, just like tuples, lists and user
    HV> defined objects can ? One doesn't even need to consider other
    HV> languages to make this point.

Having functions as first-class objects doesn't mean you have to be able to
define anonymous functions.  Functions as first-class objects worked just
fine before Guido introduced lambda to the language in Python 1.0.

    HV> Does anyone care about consistency in python ? For real, if you
    HV> don't want functional programming, make functions non first class
    HV> and stop claiming that they are objects just like every object.

As I indicated above, "functions as first-class objects" is not synonymous
with "functional programming".  There are plenty of uses for function
objects without considering map(), apply(), lambda(), filter(), reduce() and
friends.

Skip