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

[Abe Dillon]

[Steven D'Aprano]

> As educators, if we fail to teach the technical language of a field to
> our students, we are failing to prepare those students to enter that
> field. Technical jargon is the language of the field.


It's not the responsibility of the tool to teach. My socket wrench doesn't
have the history of socket wrenches inscribed on it, nor does it have any
description of the different kinds of nuts and bolts. That's called the
Single Responsibility Principal or SRP for short. Your job may be to
educate, but that's not Python's job.

[Steven D'Aprano]

> We should not focus too heavily on the earliest and most ignorant stage
> of people's programming life.


The problem goes beyond just learning the term lambda, it can increase
mental load on an already mentally demanding activity to have to translate
an unfamiliar word every time you see it. It's lack of relation to anything
else makes it hard to remember and hard to recall later.

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.

[Steven D'Aprano]

> That stage makes up probably less than 10%
> of their life as a programmer.


My argument has never been about the high magnitude of the opportunity
cost, just that there is one (IMHO) compared to a less jargon option.
Better is better. period. Even if only improves the first 10% of your
programming career. That's why I've said I don't ever think this discussion
will lead to action.

[Steven D'Aprano]

> Python is a general purpose programming
> language and we shouldn't shy from the appropriate use of technical
> terms in the documentation and the language itself.


A Caterpillar Bulldozer is a professional piece of equipment. That doesn't
mean they throw out basic tenants of good user interface design
<https://en.wikipedia.org/wiki/Principles_of_user_interface_design> and
take it upon themselves to teach the operator construction jargon through
the interface. They still find it's better to use a red break light symbol
with the aim of clearly communicating to non-experts. Just like a child's
go kart! Even Python didn't find it necessary to teach me the word
"ternary" for ternary expression.

[Steven D'Aprano]

> And the experience of educators like Chris teaching Javascript suggests
> strongly that no, it doesn't, since Javascript learners have just as
> much trouble learning the concept of "function" as Python learners have
> with "lambda".


I don't think that one person's anecdotal evidence could be considered
"strong" in the face of scientific studies.
Especially when it's become clear that Chris was referring to a broad
category of subjects that are only tangentially related to lambda
expressions.

[Steven D'Aprano]

> Chris' conclusion is that anonymous functions are inherently hard for
> many beginners to learn, regardless of whether the syntax is called
> "lambda" or "function".


That's not been my experience.

[Steven D'Aprano]

> I believe that many people have a lot of trouble grasping the concept of
> functions as first-class values capable of being passed to other
> functions as data. It requires a major rethink of the way we think of
> functions.


Those topics have nothing to do with lambda expressions. You can
demonstrate them without ever writing a lambda expression.
The difficulty of those concepts doesn't inform the choosing of the name.
You might as well name it "schubalu" and when I say "that's unnecessarily
confusing" just say "well it's easier to learn the word 'schubalu' than it
is to learn how Bloom Filters work!"

Yup. I can't argue with that. I guess we should stick with "schubalu"...

[Steven D'Aprano]

> Aside from having to learn the correct spelling ("lamdba"?) it
> was never the *name* that gave me trouble.


Maybe not for you, but it's fresh enough in my mind that the name itself
caused confusion.
I know it seems minor, but back in the 'partial' thread, I was literally
just talking about the name: lambda.

Nothing else matters because it's all invariant. Callbacks will still be
hard to learn. Functions as first class objects will still be confusing.
All I'm talking about is a missed opportunity to choose a moderately better
name. Just like function.partial vs. function.given. I didn't think my
opinion would spawn 6 threads and hours of nit-picking.

None of your discussion about the difficulty of functional programming
informs the value of jargon over less jargon. When is it better to favor
more common language, if ever?

[Steven D'Aprano]

> that cost is paid for, with interest, later,
> as a journeyman or journeywoman programmer.


Yeah, or never. My friend used to say he was in IT, then it was Dev Ops,
now there's a new term. Or it may be that everyone knows what you mean when
you say "anonymous function" and you didn't earn any interest for learning
"lambda". After I graduated with my EE degree, I bought a bunch of
vocabulary flash cards so that I could take the GRE and go to grad school.
I remember wondering, "why the hell does every flash-card set have
'numismatics' in it?! I can never remember that damn word!" now I know it.
It's never paid interest...

[Steven D'Aprano]

> Nevertheless, it is important that I teach them the technical terms too.


I find that beyond the basics: class, object, function, variable, argument,
parameter, etc.
Having students memorize jargon has limited value.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180822/11335c81/attachment-0001.html>