<div dir="ltr">[Chris Angelico]<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If the concept is utterly unfamiliar and the word is familiar, it<br>creates a different problem: the false parallel. Let's suppose that,<br>instead of calling them "lambda expressions", we call them "bacon<br>expressions".</blockquote><div><br>Or maybe "curry expressions!"... (I really hate that jargon too)<br>I think this is a pretty ridiculous take on my argument.<br><br>[Chris Angelico]</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Technically this is true of "lambda" too, but for those who<br>know Greek, it's like calling something an "S-expression", which is<br>fairly obviously an abbreviation for something. ("Symbolic<br>expression", I think? Someone might correct me there.)</blockquote><div><br>No. The lambda in lambda calculus was chosen arbitrarily. It has no deeper meaning.<br><font face="arial, helvetica, sans-serif"><a href="https://www.youtube.com/watch?v=juXwu0Nqc3I&t=1m10s">According to Dana Scott, who was a Ph. D student under Alonzo Church: The choice was <span style="color:rgb(36,39,41)">"eeny, meeny, miny, moe"</span></a><br></font><br>[Chris Angelico]<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-im" style="color:rgb(80,0,80)">> I've also argued that the very form of lambda expressions is noisier than it<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> otherwise needs to be. It's not like noise is only distracting to novice<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> developers.</span><span class="gmail-im" style="color:rgb(80,0,80)"><br></span>Yes, you've asserted it. We've disputed it. You have yet to provide<br>real evidence.</blockquote><div><br>Why isn't my example comparing the pseudo code:<br><br><font face="monospace, monospace">hand = sorted(cards, by=card.suit)</font><br><br>to the actual code:<br><br><font face="monospace, monospace">hand = sorted(cards, key=lambda card: card.suit)</font><br><br>suitable to at least demonstrate the basic idea?<br><br>I can show you the noise right here:<br><br><font face="monospace, monospace">hand = sorted(cards, ke#=#############card.suit)</font><br><br>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.<br><br>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.<br>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.<br><br>[Chris Angelico]<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">it probably called it an "if-expression" or "conditional<br>expression" or something.</blockquote><div><br>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. <br><br>[Chris Angelico]<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What broad category of subjects?</blockquote><div><br>* Functions as first-class objects<br>* Callbacks & Event Handlers<br>* Passing functions as arguments<br>* the "semantics" as you put it<br><br>In other-words, when you said:<br><br>[Chris Angelico]<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Whether you spell it "function(arg) {...}" or "lambda arg: ...", it's<br>the semantics that are hardest to learn.</blockquote><div><br>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!<br>We were literally only talking about names.<br><br>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.<br><br>[Chris Angelico]<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Okay! What's been your experience?</blockquote><br>That students have trouble realizing that<br><br><font face="monospace, monospace">def f(x):<br>    return x*x</font><br><br>is exactly the same as:<br><br><font face="monospace, monospace">f = lambda x: x*x</font><br><br>yet have very little trouble learning how to write a function in JavaScript:<br><br><font face="monospace, monospace">f = function(x) {<br>    return x*x<br>}</font><br><br>Literally just that.</div></div></div></div></div></div>