3 ms·

Because sometimes I want to have logic that spans multiple lines and I don't want to assign it a name. An easy example might be something with a `map` or a fil

Because sometimes I want to have logic that spans multiple lines and I don't want to assign it a name. An easy example might be something with a `map` or a filter. For example, in JavaScript [1,2,3,4].filter(x => { let z = x * 2; let y = x * 3; let a = x / 2; return (z + x * a) % 27 == 2; }); Obviously I know I could name this function and feed it in, but for one-off logic like this I feel a lambda is descriptive enough and I like that it can be done in-place. You're free to disagree, but I think there's a reason that most languages do allow multi-line lambdas now, even Java.

frutiger 1y ago
Off topic: you didn’t use y.
- tombert 1y ago
  You are right! Obviously this is just an ad hoc thing I wrote to show a point but I shouldn't be using superfluous variables.
ddejohn 1y ago
> Obviously I know I could name this function and feed it in, but for one-off logic like this I feel a lambda is descriptive enough and I like that it can be done in-place. FWIW, you'd also have the benefit of being able to unit test your logic.
- tombert 1y ago
  I mean, maybe, that's why your lambdas shouldn't be too long. I have done a lot of Haskell and F#, and I'm very familiar with the concept of "lifting", and yeah being able to individually test the components is nice, but even within Haskell it's not too uncommon to use a lambda if the logic doesn't really need to be reused or is only a couple lines. If you have a huge function, or you think there's any chance of the logic being reused, of course don't use a lambda, use a named function. I'm just saying that sometimes stuff that has 2-4 lines is still not worthy of having a name.
dec0dedab0de 1y ago
Honestly, I don't really see the appeal of unnamed functions in general. I so rarely use lambdas that I wouldn't really miss them if they were gone. Just occasionally as a sort key, or in a comprehension. I have seen people do this in JavaScript quite often, but I always assumed there was some kind of underlying performance benefit that I didn't know about. As I think about it I guess it makes sense if you're passing a function to a function and you just want it to be concise. I could imagine using something like that off the top of my head, but then pulling it apart and giving it a name the moment I had to troubleshoot it. Which is how I currently use nested comprehensions, just blurt them out in the moment but refactor at the first sign of trouble. I think maybe I just have trouble seeing some of the braces and stuff, and it's easier for me to reason about if it's named. I guess that's why we have 32 flavors. Thanks for answering me honestly I really do appreciate it, even if my tone came off as dismissive. Sometimes I don't realize how I sound until after I read it back.
- tombert 1y ago
  Obviously it's totally fine to have a difference of opinion for something like this. > I have seen people do this in JavaScript quite often, but I always assumed there was some kind of underlying performance benefit that I didn't know about. I don't think so, at least I haven't heard of it if there is. I tend to have a rule of thumb of "if it's more than 6-7 lines, give it a name". That's not a strict rule, but it's something I try and force myself to do. Like in Python, most lambdas can be done in one line, but that also kind of gets into a separate bit of gross logic, because you might try and cram as much into an expression as possible. Like, in my example, it could be written like this: [1,2,3,4].filter(x =>((x * 2) + x * (x/2)) % 27 == 2); But now I have one giant-ass expression because I put it all into one line. Now where previously I had two extra names for the variables, I have the ad-hoc logic shoved in there because I wanted to squeeze it into a lambda.
  - dec0dedab0de 1y ago
    And I think that's where the reasoning behind only allowing one line lambdas came from. I believe I read a thread a long time ago where GVR didn't even want to include lambdas at all, if I have time I might look for it and edit in a link. At it's core, I think it's fair to say Python is about forcing the user into formatting their code in a readable way. It's gotten away from it over the years for practicality reasons, and to increase adoption by people who disagree on which ways are more readable. Sometimes I wish they would take nested comprehensions away from me, I am too lazy to avoid them in the heat of the moment, and I get a thrill out of making it work, even though I know they're disgusting.

frutiger 1y ago

Off topic: you didn’t use y.

tombert 1y ago
You are right! Obviously this is just an ad hoc thing I wrote to show a point but I shouldn't be using superfluous variables.

ddejohn 1y ago

> Obviously I know I could name this function and feed it in, but for one-off logic like this I feel a lambda is descriptive enough and I like that it can be done in-place. FWIW, you'd also have the benefit of being able to unit test your logic.

tombert 1y ago
I mean, maybe, that's why your lambdas shouldn't be too long. I have done a lot of Haskell and F#, and I'm very familiar with the concept of "lifting", and yeah being able to individually test the components is nice, but even within Haskell it's not too uncommon to use a lambda if the logic doesn't really need to be reused or is only a couple lines. If you have a huge function, or you think there's any chance of the logic being reused, of course don't use a lambda, use a named function. I'm just saying that sometimes stuff that has 2-4 lines is still not worthy of having a name.

dec0dedab0de 1y ago

Honestly, I don't really see the appeal of unnamed functions in general. I so rarely use lambdas that I wouldn't really miss them if they were gone. Just occasionally as a sort key, or in a comprehension. I have seen people do this in JavaScript quite often, but I always assumed there was some kind of underlying performance benefit that I didn't know about. As I think about it I guess it makes sense if you're passing a function to a function and you just want it to be concise. I could imagine using something like that off the top of my head, but then pulling it apart and giving it a name the moment I had to troubleshoot it. Which is how I currently use nested comprehensions, just blurt them out in the moment but refactor at the first sign of trouble. I think maybe I just have trouble seeing some of the braces and stuff, and it's easier for me to reason about if it's named. I guess that's why we have 32 flavors. Thanks for answering me honestly I really do appreciate it, even if my tone came off as dismissive. Sometimes I don't realize how I sound until after I read it back.

tombert 1y ago
Obviously it's totally fine to have a difference of opinion for something like this. > I have seen people do this in JavaScript quite often, but I always assumed there was some kind of underlying performance benefit that I didn't know about. I don't think so, at least I haven't heard of it if there is. I tend to have a rule of thumb of "if it's more than 6-7 lines, give it a name". That's not a strict rule, but it's something I try and force myself to do. Like in Python, most lambdas can be done in one line, but that also kind of gets into a separate bit of gross logic, because you might try and cram as much into an expression as possible. Like, in my example, it could be written like this: [1,2,3,4].filter(x =>((x * 2) + x * (x/2)) % 27 == 2); But now I have one giant-ass expression because I put it all into one line. Now where previously I had two extra names for the variables, I have the ad-hoc logic shoved in there because I wanted to squeeze it into a lambda.
- dec0dedab0de 1y ago
  And I think that's where the reasoning behind only allowing one line lambdas came from. I believe I read a thread a long time ago where GVR didn't even want to include lambdas at all, if I have time I might look for it and edit in a link. At it's core, I think it's fair to say Python is about forcing the user into formatting their code in a readable way. It's gotten away from it over the years for practicality reasons, and to increase adoption by people who disagree on which ways are more readable. Sometimes I wish they would take nested comprehensions away from me, I am too lazy to avoid them in the heat of the moment, and I get a thrill out of making it work, even though I know they're disgusting.