3 ms·

You do so by labeling anonymous functions "clunky" and continuing to pretend that the only use of lambdas is working with collections. Or, as I like to call i

You do so by labeling anonymous functions "clunky" and continuing to pretend that the only use of lambdas is working with collections. Or, as I like to call it, "The same lie they've been telling for a decade, that everyone knows is false because lots of people learn JavaScript and do not find it excessively complicated."

joshuamorton 8y ago
Except that the entire job ecosystem has been moving away from a lot of the ways they used anonymous functions (callbacks replaced by promises, replaced by async/await). It's pretty rare that I write multi expression anonymous functions in js, and the language appears to be doing everything in it's power to make them wholly unnecessary.
- KirinDave 8y ago
  > Except that the entire job ecosystem has been moving away from a lot of the ways they used anonymous functions (callbacks replaced by promises, replaced by async/await). This isn't true at all. Async/await is just a nice way to think about chaining callbacks. They're still callbacks. You can await raw promises and lambdas. Callbacks are still used when they ought to be used, which is in situations where there isn't an "end" to the deferred computation. > It's pretty rare that I write multi expression anonymous functions in js, and the language appears to be doing everything in it's power to make them wholly unnecessary. I don't agree with that assessment and I think a lot of Javascript programmers would too. You still see multi-expression lambdas used a lot, and as I've said elsewhere async/await is just a way of monadically handling lambdas with the appropriate call signature. Heck, the entire point of the PEP we're discussing is to try to make it easier to write what'd trivially be recognizable multi-expression lambdas into things like list comprehensions or for decls. What a victory! Now you have to read the entire list comprehension at least twice!
  - joshuamorton 8y ago
    I think that reducing async/await to just sugar for callbacks is reductive. They provide improved error handling and easier extension. Sure they don't do any more than callbacks, but they're not callbacks. They're an alternative to callbacks that allows you to better structure your code. And importantly, they tip the before towards named functions. As for this pep, I don't really like it, I think it adds dubious value and overly terse syntax. But that has nothing to do with the general idea that multi expression lambdas are unnecessary.
    - KirinDave 8y ago
      I think reducing lambdas to callbacks is reductive. They provide a lot more utility and often have returned values (which callbacks do not). The fact that the python community is proposing and approving PEPs like this is evidence they have a desire for multi expression lambda functionality. They've just made a decision they refused to go back on because of over a decade of pride. They end up rebuilding every use case as an ad hoc piece of syntax.
      - joshuamorton 8y ago
        >callbacks cannot This is wrong. Please fully inform yourself before making incorrect claims that I'm being reductive. Some callbacks may not return a value, but callbacks in general absolutely can and do. (A callback simply need conform to an interface, that interface can be whatever the enclosing code decides it should be). Either that, or async/await is more powerful than callbacks, because most of the `async` functions I've seen have a return value (coroutines can and do yield results, and async/await is a way of implementing coroutines). I also don't really think that this solves the same issue as multiline lambdas in all cases. Sure, one of the examples (the case of a double function invocation in a comprehension) can be solved with a multiline lambda (among other ways). But multiline lambdas don't particularly clean up `if (x := re.match(...)): process(x)`. Which I'd argue is the more motivating example. So sure, this doesn't solve your problem with the language in the best way possible, but it was never really intended to, it just sort of can as a side effect. (I don't really think this is a good thing, mind you, but it is a thing).

joshuamorton 8y ago

Except that the entire job ecosystem has been moving away from a lot of the ways they used anonymous functions (callbacks replaced by promises, replaced by async/await). It's pretty rare that I write multi expression anonymous functions in js, and the language appears to be doing everything in it's power to make them wholly unnecessary.

KirinDave 8y ago
> Except that the entire job ecosystem has been moving away from a lot of the ways they used anonymous functions (callbacks replaced by promises, replaced by async/await). This isn't true at all. Async/await is just a nice way to think about chaining callbacks. They're still callbacks. You can await raw promises and lambdas. Callbacks are still used when they ought to be used, which is in situations where there isn't an "end" to the deferred computation. > It's pretty rare that I write multi expression anonymous functions in js, and the language appears to be doing everything in it's power to make them wholly unnecessary. I don't agree with that assessment and I think a lot of Javascript programmers would too. You still see multi-expression lambdas used a lot, and as I've said elsewhere async/await is just a way of monadically handling lambdas with the appropriate call signature. Heck, the entire point of the PEP we're discussing is to try to make it easier to write what'd trivially be recognizable multi-expression lambdas into things like list comprehensions or for decls. What a victory! Now you have to read the entire list comprehension at least twice!
- joshuamorton 8y ago
  I think that reducing async/await to just sugar for callbacks is reductive. They provide improved error handling and easier extension. Sure they don't do any more than callbacks, but they're not callbacks. They're an alternative to callbacks that allows you to better structure your code. And importantly, they tip the before towards named functions. As for this pep, I don't really like it, I think it adds dubious value and overly terse syntax. But that has nothing to do with the general idea that multi expression lambdas are unnecessary.
  - KirinDave 8y ago
    I think reducing lambdas to callbacks is reductive. They provide a lot more utility and often have returned values (which callbacks do not). The fact that the python community is proposing and approving PEPs like this is evidence they have a desire for multi expression lambda functionality. They've just made a decision they refused to go back on because of over a decade of pride. They end up rebuilding every use case as an ad hoc piece of syntax.
    - joshuamorton 8y ago
      >callbacks cannot This is wrong. Please fully inform yourself before making incorrect claims that I'm being reductive. Some callbacks may not return a value, but callbacks in general absolutely can and do. (A callback simply need conform to an interface, that interface can be whatever the enclosing code decides it should be). Either that, or async/await is more powerful than callbacks, because most of the `async` functions I've seen have a return value (coroutines can and do yield results, and async/await is a way of implementing coroutines). I also don't really think that this solves the same issue as multiline lambdas in all cases. Sure, one of the examples (the case of a double function invocation in a comprehension) can be solved with a multiline lambda (among other ways). But multiline lambdas don't particularly clean up `if (x := re.match(...)): process(x)`. Which I'd argue is the more motivating example. So sure, this doesn't solve your problem with the language in the best way possible, but it was never really intended to, it just sort of can as a side effect. (I don't really think this is a good thing, mind you, but it is a thing).