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

[Abe Dillon]

[Michael Selik]

> The conversation about syntactic sugar for ``functools.partial`` led to a
> question about whether jargon like "lambda" makes the concept of an
> anonymous function more difficult to learn.


To clarify: The original statement by Steven D'Aprano, "although possibly a
less jargon name would be nicer..." indicated to me that he thought there
might be situations where less jargon terms are preferable to jargon terms.

The argument I tried to make is, "yes I believe there are cases where a
less jargon identifier is preferable and that I believe 'lambda' is an
example of a missed opportunity to use a less jargon (maybe 'esoteric' is a
better word here?), more descriptive name."

Subjectively, I don't like lambda expressions. I find the word 'lambda' to
be an eye-sore in an otherwise very elegant language.

That being said: I believe subjective valuations are rarely devoid of
subtle, underlying motivators that are at least grounded in logic if not
objective. It's just hard to put your finger on it most of the time. I
often try to root out those motivators for why I feel the way I do and
articulate them as best I can. At the end of the day, though; I can't
always provide a completely objective, logical proof for why I feel the way
I do.

For instance: when the iPhone was introduced, a lot of people praised it's
subjectively "slick" user interface. I believe that perception of slickness
is partly because the iPhone emulated physical interfaces very well so it
leveraged people's intuition about the physical world. It was delightfully
intuitive.

I believe that part of my distaste for lambda is that it's an esoteric word
that doesn't convey any meaning to someone who's never heard of a 'lambda
expression' (which was the case for me when I first encountered it). Even
after I had heard of a lambda expression, the fact that the word had little
other connection to anything relevant in my brain meant that I had to
mentally translate it every time I read for a couple of years.

[Steven Barnes]

> While NOT wanting to start another fight I feel that I must put my
> pedant hat on & point out that the above highlights why domain specific
> words are used and their specificity actually highlights important
> concepts, i.e.:
>   * Brakes are used to apply breaking, (i.e. to slow the vehicle,
> possibly to a stop), while stoppers STOP something.


I don't think this is comparable to calling a car's brakes, "stoppers" for
several reasons.

1) What we call something usually relates to how humans communicate to
other humans about that thing, not how we actually use the tool.

I'm not against the idea of jargon. It clearly serves a useful purpose for
humans to communicate to other humans both concisely and with precision.
When I tell someone at work that a service went down and they say, "I'll
take a look at the logs", I know they're not talking about lengths of cut
or fallen tree. I'm glad humans are so good at deducing context that we
don't have to constantly disambiguate everything. I also understand that
this practice of overloading words sometimes leads to strange results like
"currying". Maybe calling it "signature reduction" would have been too
unwieldy and/or caused confusion with the word "reduce" which is often used
in the same context.

None of that has to do with how I interact with a car. Few brake pedals say
"brake" on them. I don't have to use the word "brake" to slow down my car.
Few of the interfaces in my car even have words. There's no lever that says
"high beams". There's no dashboard indicator that says "high beams". I
don't have to use the phrase "high beams" to turn on my high beams. At the
same time, I don't need to use or know the word "ternary" to read or write
a ternary expression in Python. I don't think that was a mistake or a
missed opportunity to force people to look up the word "ternary".

Sometimes in highly specific contexts, we deal with nuanced concepts like
the difference between a parameter and an argument. So we use jargon to
distinguish between them. That's not as much of problem in a programming
language. The constructs in Python have to have an exact meaning by
default. Clearly defining and separating name-spaces is an inescapable fact
of life in programming. There's no chance of Python accidentally
misinterpreting which "log" you're talking about. There's no potential for
a "who's on first" gag <https://www.youtube.com/watch?v=kTcRRaXV-fg>.

2) Cars tend to actually use pretty sensible naming schemes.

A windshield shields you from the wind. A windshield wiper wipes the
windshield. Windshield wiper fluid is fluid that helps the windshield wiper
wipe the windshield, etc.
If they called windshield wiper solution "epsilon", it wouldn't cause more
crashes or anything, it would just be more confusing than it needs to be.

3) It's not like calling 'brakes' 'stoppers'. It's more like calling an
expression that makes a function by some random greek letter. I don't see
much need for a metaphor.

[Steven Barnes]

> * postprandial = after Lunch (not after eating any meal or after a snack).


Not according to Google
<https://www.google.com/search?q=postprandial+definition>, Merriam-Webster
<https://www.merriam-webster.com/dictionary/postprandial>, Oxford
<https://en.oxforddictionaries.com/definition/postprandial>, or Wikipedia
<https://en.wikipedia.org/wiki/Prandial>.

[Steven Barnes]

> In all of these cases there is a specificity to the word used that is
> missing from the alternative offered that will, hopefully, be raised by
> the use of that word. Unfortunately many people, when trying to explain
> what the word means fail to highlight where it is different (the number
> of times that I have heard people "explain" port and starboard as left
> and right without mentioning the word bow or forward is countless).


I understand the potential benefit of jargon as stated above, but even this
isn't always true. Sometimes jargon is created that is counterintuitive and
then it just sticks because changing it would be a huge hassle. In
electrical engineering, current is supposed to be the "flow of positive
charge", but charge conventions were established before we knew how atoms
work and learned that positively charged particles don't often move in
circuits. Dinosaurs are another good example. Sometimes jargon is a mistake.

[Steven Barnes]

> Using a slightly unfamiliar word can cause people to ask, or think
> about, why this is different & what the difference is while also drawing
> a parallel that can help the user/student to understand & remember the
> concept.


It depends on if it's easy to tie said word into a broader understanding.
It's easy for me to remember that "agua" means "water" in Spanish because
it's very similar to a words that relate to water in english like
"aquifer". I have trouble remembering that "izquierda" means "left" because
I don't know any word like it. I have to pause and think about it every
time without fail! Similarly, I can guess that "anonymous function" means a
function without a name, but it took me a while to get used to "lambda"
because it was just dangling there with no other connection to its context.
Even when I learned about lambda calculus it didn't help much because the
"lambda" was an arbitrary choice. There wasn't any way for me to tie it
into a richer context.

[Steven Barnes]

> Also, picking a label for something, and using it consistently, can
> vastly simplify things like manual searches (or on-line searches).


Yes, Steven D'Aprano mentioned this and it's a fair point. I think it'd
have to be pretty horrendous jargon to justify "create [an] association
from scratch" as Steven put it. I've since gone back on my original push
for "partial" over "given" because I don't think it meets that criteria. I
think that "lambda" is a different case because there already existed
several better alternatives in other languages and, in the case of "def",
in Python itself.

[Chris Angelico]

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


Naming and semantics are essentially orthogonal. Sure callbacks and the
like can require some painful mental gymnastics, but that's independent of
choosing "function" or "lambda". When I talk about students having more
trouble learning lambdas than I expect, I'm specifically talking about
lambdas, as in:

>>> func = lambda x: x*x

Even students that seemed to quickly grasp functions as first-class objects
would stumble on basic lambda expressions. Not as much trouble as callbacks
and other, more complex concepts, but more trouble than regular function
definition.

Anyway, the question should be "Is it always best to use jargon in the
implementation of Python features? If so, how do you figure? If not, when
and why should it be avoided?"

On Wed, Aug 15, 2018 at 12:21 AM, Steve Barnes <gadgetsteve at live.co.uk>
wrote:

>
>
> On 14/08/2018 20:42, Michael Selik wrote:
> >
> > Good comparisons can be found in other fields:
> > * Driving -- brakes vs stoppers
> > * Sailing -- starboard vs right-side
> > * Medicine -- postprandial vs after-meal
> > * Biology -- dinosaur vs direlizard
> >
> While NOT wanting to start another fight I feel that I must put my
> pedant hat on & point out that the above highlights why domain specific
> words are used and their specificity actually highlights important
> concepts, i.e.:
>
>   * Brakes are used to apply breaking, (i.e. to slow the vehicle,
> possibly to a stop), while stoppers STOP something.
>   * Starboard = to the right when facing the bow (front of the vessel)
> not "my right", "your right" or "their right" (which depends on which
> way you, I & they are facing).
>   * postprandial = after Lunch (not after eating any meal or after a
> snack).
>   * A dinosaur is specifically an extinct terrible (formerly considered)
> lizard where as a Gila Monster is definitely a scary & dangerous (dire)
> lizard.
>
> In all of these cases there is a specificity to the word used that is
> missing from the alternative offered that will, hopefully, be raised by
> the use of that word. Unfortunately many people, when trying to explain
> what the word means fail to highlight where it is different (the number
> of times that I have heard people "explain" port and starboard as left
> and right without mentioning the word bow or forward is countless).
>
> Using a slightly unfamiliar word can cause people to ask, or think
> about, why this is different & what the difference is while also drawing
> a parallel that can help the user/student to understand & remember the
> concept.
>
> Also, picking a label for something, and using it consistently, can
> vastly simplify things like manual searches (or on-line searches).
>
> The English language has, historically, always borrowed, co-opted and
> sometimes perverted words from other languages to allow distinct
> concepts to be expressed concisely - which I personally, (admittedly as
> a native speaker), find rather useful.
>
> --
> Steve (Gadget) Barnes
> Any opinions in this message are my personal opinions and do not reflect
> those of my employer.
>
> ---
> This email has been checked for viruses by AVG.
> https://www.avg.com
>
> _______________________________________________
> 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/20180817/c5646b2a/attachment-0001.html>