map/filter/reduce/lambda opinions and background unscientific mini-survey

[Steven D'Aprano]

On Tue, 05 Jul 2005 09:46:41 -0500, Terry Hancock wrote:

> On Tuesday 05 July 2005 08:17 am, Steven D'Aprano wrote:
>> Sorry, but you are mistaken. "lambda" is a _reserved_ word in the
>> Python language, while "function" etc are not, but they are certainly
>> part of the language. Try explaining what def and import do without
>> using the words "function" or "module". Maybe you can do it, using
>> circumlocutions, but it isn't easy, and costs clarity.
> 
> This is still a relevant distinction.   One relevant point is that I am
> perfectly free to use, say, the Spanish or Chinese word to describe
> "module" or "function", but the keywords "def" and "import" will
> remain the same.

No, that isn't relevant. That's just localisation. I'm also free to fork
Python and change the keywords. 

[snip]
> The "Python sense" is not arbitrary.  There are very direct visual or
> logical (i.e. INTUITIVE) connections between these words' *English*
> meanings (not just mathematical, either) and their meanings in Python.

I had NEVER even heard the word "tuple" before learning Python. I spent
weeks mispelling it as "turple", and I finally had to look it up in a
dictionary to see if it was a real English word. Out of the four English
dictionaries in my house, none of them have the word.

Let's dump tuple from the language too, its just "a stupid name for a list
that can't change". Agreed?

[snip]
> Similarly, "decorate" is 'make more attractive by adding ornament,
> colour, etc.' In Python, a "decorator" applies a wrapper to a function
> to provide it with some additional functionality.

Which is certainly NOT decoration, since the point of decoration is that
it is not functional! Plain bathroom tiles are functional. Decorating them
with leaves or flowers or patterns is not functional.

[snip]
> Now, if you are armed ONLY with the English definition, you will
> possibly run into some trouble, because the programming usage is a
> *specialization* of the term -- we strictly take only *one* of the
> English definitions to apply, and we narrow its meaning a bit.

Yes. Every specialization has its own jargon, and computer programming is
no different. One of the things new programmers have to learn is the
jargon.

[snip]
> "lambda" has no such advantage.  Here's the *entire* gcide definition:

Nonsense. All that means is that lambda in the programming sense is too
specialized to make it into most ordinary dictionaries. Just like tuple.

[snip]

>> Think back to when you were a schoolboy at your first day of school.
>> Unless you had a very unusual upbringing, you probably had never heard
>> the word "function" before.
> 
> Total BS.  I knew the word "function" in it's English language sense,
> probably by the time I was 6.  I *know* my kids know it.

Okay, maybe my memories of being five are faulty. 

But if not six, then five, or four, or three, or two. At _some_time_
function was entirely unknown to you, and you had to just learn it.

[snip]

>> You had to learn that word, discover what it means, and then it becomes
>> familiar. You don't notice the process only because it happened so long
>> ago, at an age that your brain was operating in "language acquisition
>> mode" and picking up vocabulary at an incredible rate.
> 
> If you're arguing that language is acquired rather than innate, you are
> bludgeoning an obvious point. The point is that *jargon* should ideally
> derive in a natural way from commonly-used language, 

That's a bonus, sure. It is an important rule to follow, but not at the
expense of distorting the language:

t = immutable_list(L)
map(anonymous_function x: x+1, L)

versus:

t = tuple(L)
map(lambda x: x+1, L)

> if we want it to be
> easy to acquire for people who don't learn programming between the ages
> of 1 and 5 as we learn our native languages.  Even in the 21st century,
> I think this includes just about all of us. ;-)

If they can't memorize one or two things, they aren't going to be much
good at programming no matter how easy the language is to use.

>> There is nothing about the word "string" that especially brings to mind
>> "an array of bytes representing characters". The analogy of "string of
>> characters" to "string of beads" breaks down as soon as you have
>> multiple lines of text.
> 
> Ah, but that's useful.  "Strings" AREN'T "multiple lines of text" in the
> computer's memory, are they?  '\n' is just another bead.  The "multiple
> lines" is a representation, or way of laying out the beads.  Very useful
> distinction, and immediately driven by the choice of analogy.

Who cares about the implementation details of how the bytes are laid out
in the computer's memory? Unless you are programming in a low level
language like C or assembly, this is entirely irrelevant. You have
characters laid out along lines, and lines laid out in a second dimension.
The natural way to work with text is something like this:

for line in text:
    for word in line: # or character
        do_something()

[snip]

>> I won't say that the anonymous function meaning of lambda comes to my
>> mind before the Greek letter, but it isn't very far behind, and rapidly
>> catching up. (I use lambda a lot more than I speak Greek.) It wouldn't
>> surprise me if one day I think of Python programming before the Greek
>> letter, just as the world aleph brings to my mind the sense of infinity
>> before the sense of it being a Hebrew letter.
> 
> Then it is clearly *not you* who should be served by the naming scheme.
> Anyone so deeply trained and experienced should be expected to adapt,
> you have the wherewithall to do so.  It is the new user for whom the
> clarity of the jargon is so important.
> 
> Personally, I find the term "anonymous function" to be a whole lot
> clearer than "lambda" or "lambda function".  Indeed, if asked what
> "lambda" means, my reply is it's a "stupid name for an anonymous
> function", and if my listener is less savvy "for a function that doesn't
> have a name,  because you only use it once".

And any half-way experienced Python programmer will say, "What are you
talking about?"

add_one = lambda x: x+1

Yes, I know that the name "add_one" is not the same as the name for a
function when you use def, but the function still has a name. The
difference might be an important difference, but it is not one you care
about unless you are doing introspection.

> Having said that, I too will miss the *concept* of an anonymous
> function, although I wouldn't mind at all if its name changed, or if it
> were somehow integrated into the "def" keyword's usage.

Def would be short for ... defend? defile? defer? defame? default? deflect?

There's always *something* to learn. Why def instead of define? Because
"easy to write" beats "instantly obvious to a beginner", if the word is
used all the time and is easy to memorize.

> Using backticks
> or some other syntax delimiter also sounds promising, 

Ew, perl :-(

> although we're sort of running out of them. ;-)

-- 
Steven.