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

[Steven D'Aprano]

Michael makes some reasonable points, but I think the very premise of 
this thread is putting the cart before the horse.

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.

If it makes teaching beginners more difficult, well, so it goes. Lots of 
things make teaching more difficult e.g.:

- technical jargon;

- expecting students to write code that runs;

- expecting the code to run correctly;

- having them do input validation and error handling;

- and write documentation and comments for their code.

Lambda is becoming a standard technical term in computing, even in 
languages which don't use that keyword. The official name for Java's 
anonymous functions is "lambda expressions":

https://www.oracle.com/webfolder/technetwork/tutorials/obe/java/Lambda-QuickStart/index.html

Ruby has no fewer than three separate kinds of anonymous callable, 
blocks, procs and lambdas:

https://medium.com/@AdamKing0126/ruby-whats-the-deal-with-procs-and-lambdas-165450cdf573

and the term is now used in C++, C#, LINQ and others, even if they don't 
use it as a keyword.

https://duckduckgo.com/?q=lambda+expressions

We should not focus too heavily on the earliest and most ignorant stage 
of people's programming life. That stage makes up probably less than 10% 
of their life as a programmer. 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.

Python is not Scratch and the primary focus of Python the language is 
not education. Many people come to Python for the first time with one, 
two or ten other languages under their belt, and some of them even have 
a good grasp of computer science. We should not talk down to those 
experienced coders for the sake of those in the first year or so of 
their programming life.

Scratch, for example, doesn't use the word "function" to describe 
functions. They use "blocks" (but not in the Ruby sense). This is, I 
suppose, fine for the average kid of age 8, if you think talking down to 
kids is okay (or necessary). But if we were designing Python from 
scratch today (pun intended), we surely ought not follow their lead.

https://en.scratch-wiki.info/wiki/Custom_Blocks


More comments below, following Michael's comments.


On Tue, Aug 14, 2018 at 12:42:29PM -0700, Michael Selik wrote:

> 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.

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".

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 matches my own observations, interacting with newbies on various 
mailing lists, as well as my own personal experience.

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. We go from treating them purely as verbs:

    sort the list

to nouns in their own right:

    process the sort  # the what now?


Not "process the sorted list", but reify the sort verb into an actual 
thing (an object or value) and then process that thing itself.

This is mind-bending when you think about it, far more mind-blowing than 
the normal linguistic process of nouning verbs and verbing nouns. No 
wonder people take a while to get fully comfortable with the concept. It 
took me a long time to stop writing code like this:

    map(lambda x: len(x), sequence)

instead of simply map(len, sequence). I doubt it would have taken any 
less time if it were 

    map(function x: len(x), sequence)

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

Of course there is a cost for beginners to having to learn a name, and 
the less often the name is used, the longer it takes (unless it is 
extremely memorable). But that cost is paid for, with interest, later, 
as a journeyman or journeywoman programmer.


> In my own experience teaching, I find that many concepts are easier to
> introduce if I avoid the Python jargon until after I've explained what it
> does. This is supported by education research. Some light Googling found a
> study on the topic [0] that is consistent with my own observations.

I agree. When I teach my students function transformations in maths, any 
time I use the technical terms translation, dilation and reflection, I 
follow up with the common terms shift, stretch, and flip, and vice 
versa. I make a point of always associating the imprecise plain English 
words with the precise technical terms.

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


-- 
Steve