David Alan Black wrote: 

# Hello --
# 
# On Mon, 12 Mar 2001, Conrad Schneiker wrote:
# 
# > Matz wrote:
# > 
# > # I'd like to put this particular one into RCR and get comments from
# > # people in the community.  Mike, Please?
# > # 
# > # Choices are:
# > # 
# > #   * partition
# > #   * bisect
# > #   * whatever else
# > #   * no, we don't need it.
# > 
# > FWIW, I vote for 'partition':
# >     * Compatibility with Haskell usage (presumably).
# >     * Nearly identical to C++ partition function.
# >     * Fairly natural term for native English programmers.
# 
# I'd go along with this, based on the word of people who know more
# about functional programming and Haskell than I do.  But the whole
# notion of Haskell compatibility worries me a little.  (See below.)
# 
# > 'bisect' -- I disagree:
# >     * Misleading, suggests cutting in half.
# >     * Not most commonly used term, AFAIK.
# 
# I agree -- I mean, I disagree -- I mean, I agree with Conrad,
# who disagrees with 'bisect' :-)
# 
# 
# > Don't need -- I disagree:
# >     * A matter of degree: C doesn't have min and max, but Ruby does.
# 
# I'm not sure about this.  I've never missed it. 

One of the things that make Perl, Python, and Ruby very  useful for
many common tasks is that they include lots of 'extra' functions with
respect to C, ksh, and so on, so that you don't have to waste time
reinventing semi-trivial wheels. (More important in many cases is that
you don't have to waste time checking other people's inevitable
variations on reinvented wheels to make sure they match your idea of
how the 'standard' variant should work when maintaining stuff written
by others.) 

This of course means that many people will often not find
several-to-many of these functions all that useful.  But on the
average, it makes the language overall more useful to more
people--that is, at least as long as you don't go completely 
hog wild--or should that be, as long as you don't go completely
mad cow. }8<D

# It can be added to
# Enumerable, already, in one line (though obviously core inclusion
# would mean speed).  There are certainly many other
# Enumerable/Array/Hash things that I would consider much more
# important [...].

Then by all means, please propose them.

# As for Haskell and functional programming:
# 
# I'm confused about the whole status of these things, with respect to
# Ruby.  There's been talk from time to time about borrowing standard
# functions from Haskell, or emulating a functional paradigm in Ruby.
# It always starts out sounding intriguing and well-defined, but then
# seems to end up as a kind of miscellany of possibly useful
# functions.

IMO, that is OK (and is to be expected whenever you are selecting some
subset of functions most likely to be useful in the borrowing
language).  Perl and Python (seem to have) copied useful functions
found in Lisp (with some renaming and modification)  that allow you to
do *some* things in a *somewhat* Lisp-like way, without emulating the
Lisp paradigm. IMO, Perl and Python are better for it. 

Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)