[Python-ideas] Does jargon make learning more difficult?

[Abe Dillon]

[Stephen Turnbull]

> I was an economist then, and I'm an economist still, but I met lambda
> in 1977.  Surely lambda has had that role in computer languages since
> shortly before I was born.


According to Wikipedia <https://en.wikipedia.org/wiki/Anonymous_function> Lisp
was the first language to use anonymous functions (introduced in 1958).

[Stephen Turnbull]

> I would guess anybody above a certain age
> would reach for "lambda" first for a keyword to denote or define an
> anonymous function.  Not because of the lambda calculus, but because
> of Lisp.


Wikipedia lists the anonymous function syntax of 40+ languages
<https://en.wikipedia.org/wiki/Anonymous_function#Examples> and only 5
(Lisp, Scheme, Python, Ruby, and Maxima) use the "lambda" keyword.
Haskel uses a "\" which I'm pretty sure is supposed to look like the lambda
symbol, but even that syntax seems unpopular too.

[Stephen Turnbull]

> Maybe there's a better word than "regret".  After all, It's
> hard to see how you could prototype range better than "range([START,]
> END, [STRIDE])", and the same might be true for "def [NAME] ([ARG0,]
> ...):".


I wasn't aware that Guido considered "range" to be warty. I like the way it
mimics slicing syntax. It makes it easy for me to remember. It seems like a
very pragmatic design.

[Steven D'Aprano]

> Secure in the knowledge that Guido probably isn't reading this and won't
> contradict me *wink* I'm going to try channelling him.


SUMMON THE GREAT CREATOR!

I wonder if I say his name three times...
Guido Van Rossum! Guido Van Rossum! Guido Van Rossum!

[Steven D'Aprano]

> I think he would regret "def expressions", but not because of the range
> reason.

I think its because he likes the relatively strict demarcation between
statements
> and expressions.
> We have 4 statements that have a expression form:
> if...else versus ternary if expressions;
> for loops versus comprehensions;
> (soon) = assignment versus := assignment expressions; and
> def versus lambda.


(I don't know why Gmail's quotes screw up formatting...)

I don't think that's the reason those expressions have different formats
than their statement counterparts.
Expressions allow for more flexible arrangement than expressions because
the order of execution of an expression doesn't have to follow the order of
declaration.
While it's more natural to say "do something to each item in this
collection that meets some condition" you can't access variables before
they're declared in statements
so you have to tell the computer explicitly that you're looping over some
iterable first. Expressions allow you to be more expressive.

You don't have to put your edge-case checking up-front and in the way. When
99.9% of the time you just want:

x = y

you can shove the edge-case checking to the side and let the core logic
shine:

x = y   if not edge_case else special_value

# extra spaces added for emphasis

besides:

result = if condition expression else expression

is super awkward to read out loud. That's not how I think at least.
I've never hears someone say, "My child's name will be if it's a girl Sally
otherwise Billy."

All of the expressions use either the same or similar keywords or symbols
*except* def and lambda.

func = def <args>: <expression>

Is about as different from the statement form as "x := y" is from "x = y".
No name, no parentheses for the arguments.
Finally, I know you've heard the other half of my anti-lambda manifest, but
I don't know if Stephen Turnbull has, so I'll briefly present it again.

It's not just the name "lambda" that bothers me, it's the arrangement of
the logic and signature. I believe that the expressiveness that allows
comprehensions to put the core logic in front of the less important (for
readability) loop and filtering constructs, anonymous functions could have
been arranged to put the logic in front of the (almost always) less
important signature. The reason I say the signature is almost always less
important is because one almost always uses an anonymous functions as an
argument (key-function, callback, map, reduce, filter, etc.) to something
that already defines the call signature it expects.

Consider the alternate form: <expression> with <args>  (thought there are
many alternative possibilities)

hand = sorted(cards, key=lambda card: value[card.suit] if card is not wild
else max_value)

hand = sorted(cards, by=value[card.suit]     if card is not wild else
max_value with card)

# notice how unsurprising it is that the signature is "card"

Oh wait... Did I accidentally replace "key" with "by"? Huh... It seems to
make more sense even though the jargon is a "key function"... Oops! ;)

Note: if this were a full proposal, lambdas with complex arguments or in
certain situations would require parens: (<expression> with <args>)

On Tue, Aug 21, 2018 at 9:31 AM, Steven D'Aprano <steve at pearwood.info>
wrote:

> On Tue, Aug 21, 2018 at 02:07:33PM +0900, Stephen J. Turnbull wrote:
>
> > I was an economist then, and I'm an economist still, but I met lambda
> > in 1977.  Surely lambda has had that role in computer languages since
> > shortly before I was born.  I would guess anybody above a certain age
> > would reach for "lambda" first for a keyword to denote or define an
> > anonymous function.  Not because of the lambda calculus, but because
> > of Lisp.  (OK, that's indirectly because of the lambda calculus.)
>
> Its pretty much a term of art.
>
> (Aside: "term of art" is itself a term of art:
> https://legal-dictionary.thefreedictionary.com/Term+of+Art )
>
>
> I think that complaining about lambda is like complaining about "3-sigma
> versus 6-sigma processes" in process management. (Not computer
> processes, manufacturing processes and quality control.) Or for that
> matter, "mean" and "standard deviation" in statistics.
>
> The main difference is that most people are introduced to mean and stdev
> in secondary school, while functional programming idioms and lambda are
> generally stumbled across in the field. (I know that's how I learned of
> the term: through Python.)
>
>
> > Had Guido decided to change it to "def", I suspect he'd be regretting
> > it slightly today, for reasons similar to the regrets about "range":
> > we normally only allow omitting positional arguments at the end of the
> > list.  Maybe there's a better word than "regret".  After all, It's
> > hard to see how you could prototype range better than "range([START,]
> > END, [STRIDE])", and the same might be true for "def [NAME] ([ARG0,]
> > ...):".
>
> Secure in the knowledge that Guido probably isn't reading this and won't
> contradict me *wink* I'm going to try channelling him. I think he would
> regret "def expressions", but not because of the range reason. I think
> its because he likes the relatively strict demarcation between
> statements and expressions.
>
> We have 4 statements that have a expression form:
>
> if...else versus ternary if expressions;
>
> for loops versus comprehensions;
>
> (soon) = assignment versus := assignment expressions; and
>
> def versus lambda.
>
> (Did I miss any? I don't include technicalities like dot attribute
> access versus getattr and similar.) It's notable that in none of those
> cases the syntax is quite the same in the two forms. There's always
> enough differentiation between the statement and expression that there's
> never any ambiguity which is intended. We don't have:
>
>     result = if condition expression else expression
>
> where it is the lack of colons which hints that it is an expression, we
> have a completely different syntax. So I think Guido probably wouldn't
> like the idea of using def in expressions:
>
>     def function(arg, callback=def: None):
>         pass
>
>
> That's my guess, for what it's worth.
>
>
>
> --
> Steve
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180821/60e4c4ff/attachment-0001.html>