4 ms·

Not trying to be defensive or anything: do you have any examples? I'd love to take a peek at what patterns and designs Java's lambdas don't work well for.

SeanLuke 4y ago
I can't build one right now, but one big item for me is true closures: Java lambdas are only closed over values, not over variables. Let's say you want to make a ActionListenerPair builder which sets up a writable local variable to be shared by two lambdas, all of which are ActionListeners and will be used as callbacks when you press buttons. This is extremely awkward in Java because lambdas cannot (or could not) write to variables in outer lexical scope. But there's a workaround. You can't (or shouldn't) have a non-final int x = 4 in the outer lexical scope, but you can have a final int[1] x = { 4 }, and have all the lambdas access that instead. What an ugly hack, thanks to Java's poor consideration of how closures work. At this stage, the syntax for closures is little more than a trick to reduce typing rather than an advantage over just explicitly declaring the anonymous class, and its clarity is poor, lost in the twisty syntax. Tricks make code hard to read: C is full of them.
- kjeetgill 4y ago
  Y'know that's really funny.I often refer to the way lambdas only capture final variables as an example of the absolute brilliance of Java's language design. Rather than a poor consideration I think it's a hallmark of how the obvious choice would be the worse choice in language design. It a) preserves a principled confinement that the local scope provides, and b) removes all ambiguity around variables across lambdas, assignments inside or outside a closure before or after a stack frame collapses.
  - SeanLuke 4y ago
    > Y'know that's really funny.I often refer to the way lambdas only capture final variables as an example of the absolute brilliance of Java's language design. This was done not for any principled reason at all: but rather because real closures would require heap allocation, and early users were spooked that heap allocation would be too slow. Otherwise Guy Steele (of Scheme and CL fame) would have definitely inserted them. He supposed that one day Java would fix this. https://web.archive.org/web/20090309081331/http://article.gmane.org/gmane.comp.lang.lightweight/2274 https://web.archive.org/web/20090309081331/http://article.gm...
    - kjeetgill 4y ago
      > This was done not for any principled reason at all In light of all my praise for it that's devastating to hear, haha. I still think it was a brilliant move but now I can't fawn over it. Edit: on reading this I don't get it what they're taking about, we do get a heap allocation per lambda, identically to a record with the captured variables. Thanks for filling me in on dinner of the history of all of this.

SeanLuke 4y ago

I can't build one right now, but one big item for me is true closures: Java lambdas are only closed over values, not over variables. Let's say you want to make a ActionListenerPair builder which sets up a writable local variable to be shared by two lambdas, all of which are ActionListeners and will be used as callbacks when you press buttons. This is extremely awkward in Java because lambdas cannot (or could not) write to variables in outer lexical scope. But there's a workaround. You can't (or shouldn't) have a non-final int x = 4 in the outer lexical scope, but you can have a final int[1] x = { 4 }, and have all the lambdas access that instead. What an ugly hack, thanks to Java's poor consideration of how closures work. At this stage, the syntax for closures is little more than a trick to reduce typing rather than an advantage over just explicitly declaring the anonymous class, and its clarity is poor, lost in the twisty syntax. Tricks make code hard to read: C is full of them.

kjeetgill 4y ago
Y'know that's really funny.I often refer to the way lambdas only capture final variables as an example of the absolute brilliance of Java's language design. Rather than a poor consideration I think it's a hallmark of how the obvious choice would be the worse choice in language design. It a) preserves a principled confinement that the local scope provides, and b) removes all ambiguity around variables across lambdas, assignments inside or outside a closure before or after a stack frame collapses.
- SeanLuke 4y ago
  > Y'know that's really funny.I often refer to the way lambdas only capture final variables as an example of the absolute brilliance of Java's language design. This was done not for any principled reason at all: but rather because real closures would require heap allocation, and early users were spooked that heap allocation would be too slow. Otherwise Guy Steele (of Scheme and CL fame) would have definitely inserted them. He supposed that one day Java would fix this. https://web.archive.org/web/20090309081331/http://article.gmane.org/gmane.comp.lang.lightweight/2274 https://web.archive.org/web/20090309081331/http://article.gm...
  - kjeetgill 4y ago
    > This was done not for any principled reason at all In light of all my praise for it that's devastating to hear, haha. I still think it was a brilliant move but now I can't fawn over it. Edit: on reading this I don't get it what they're taking about, we do get a heap allocation per lambda, identically to a record with the captured variables. Thanks for filling me in on dinner of the history of all of this.