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

[Abe Dillon]

[Chris Angelico]

> If the concept is utterly unfamiliar and the word is familiar, it
> creates a different problem: the false parallel. Let's suppose that,
> instead of calling them "lambda expressions", we call them "bacon
> expressions".


Or maybe "curry expressions!"... (I really hate that jargon too)
I think this is a pretty ridiculous take on my argument.

[Chris Angelico]

> Technically this is true of "lambda" too, but for those who
> know Greek, it's like calling something an "S-expression", which is
> fairly obviously an abbreviation for something. ("Symbolic
> expression", I think? Someone might correct me there.)


No. The lambda in lambda calculus was chosen arbitrarily. It has no
deeper meaning.
According to Dana Scott, who was a Ph. D student under Alonzo Church: The
choice was "eeny, meeny, miny, moe"
<https://www.youtube.com/watch?v=juXwu0Nqc3I&t=1m10s>

[Chris Angelico]

> > I've also argued that the very form of lambda expressions is noisier
> than it
> > otherwise needs to be. It's not like noise is only distracting to novice
> > developers.
> Yes, you've asserted it. We've disputed it. You have yet to provide
> real evidence.


Why isn't my example comparing the pseudo code:

hand = sorted(cards, by=card.suit)

to the actual code:

hand = sorted(cards, key=lambda card: card.suit)

suitable to at least demonstrate the basic idea?

I can show you the noise right here:

hand = sorted(cards, ke#=#############card.suit)

I could come up with a hundred such examples if you need more "evidence" of
my point, but I'm not interested in nit picking how one should properly
represent or sort cards. I'm also not interested in discussing how I need
to check my privilege because my proposal might not help Hellen Keller
write better code.

Maybe I should put you on the defensive and make you prove that it's always
best to inject as much jargon as possible into Python and that there's no
better form of lambda.
We could be discussing this idea more deeply.  Jonathan Fine pointed out
some interesting ideas about this. But mostly you and D'Aprano seem
interested in being contrarians and denying that there might be any hint of
legitimacy to my point of view. I don't think it's unassailable, but it has
nothing to do with the proper way to represent a wild-card in a poker
simulation.

[Chris Angelico]

> it probably called it an "if-expression" or "conditional
> expression" or something.


I don't know how many times I have to reiterate this: I'm not talking about
what humans call it. I'm talking about how it's expressed in code.

[Chris Angelico]

> What broad category of subjects?


* Functions as first-class objects
* Callbacks & Event Handlers
* Passing functions as arguments
* the "semantics" as you put it

In other-words, when you said:

[Chris Angelico]

> Whether you spell it "function(arg) {...}" or "lambda arg: ...", it's
> the semantics that are hardest to learn.


Those are orthogonal concerns! All else being equal, a descriptive name is
better than a less descriptive alternative. It might not be on the same
scale as the confusion caused by semantics, but it also doesn't have
anything to do with the confusion caused by semantics. function.partial and
function.given have the exact same semantics!
We were literally only talking about names.

Like I've said to D'Aprano: It may be way harder to drive a car than to buy
windshield-wiper-solution for a car, but I can still prefer the name
"windshield-wiper-solution" to "zeta" because calling it "zeta" just causes
unnecessary confusion. Will it cause mass panic? Will it cause more car
accidents? No. But, my goodness, you guys seem to want to talk a lot about
that other stuff in order to convince me I'm wrong that
"windshield-wiper-fluid" should not be called "zeta". I can't go two
replies without you bringing it back up. It's really not worth the amount
of words I've put into defending what I thought was a pretty reasonable POV.

[Chris Angelico]

> Okay! What's been your experience?


That students have trouble realizing that

def f(x):
    return x*x

is exactly the same as:

f = lambda x: x*x

yet have very little trouble learning how to write a function in JavaScript:

f = function(x) {
    return x*x
}

Literally just that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180822/8bad5d1a/attachment-0001.html>