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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
