3 ms·

> as one-element arrays of anonymous subclasses in Java. When's the last time you used Java? I remember having to use anonymous classes but we've had lambdas f

> as one-element arrays of anonymous subclasses in Java. When's the last time you used Java? I remember having to use anonymous classes but we've had lambdas for a good 8 years now? Or is it that you don't like how lambdas "fullfil" a SAM interface instead of having a true Function representation. If it's the latter, I'm sincerely very curious what we're missing out on since I'm mostly used to it.

SeanLuke 4y ago
Just last night I put out the latest versions of two open source tools totaling about 500K lines in Java. Sure I enforce an old style but I think I'm up to date with the latest in Java. It's funny how Java developers perceive "lambdas" as (param, param) -> { code } blocks to be used in consumers and iterators etc. This is a weird mutation of the general concept due to Java's lack of functions: as a Lisp developer I don't perceive lambda expressions like that at all. The use of lambda expressions is much more general than this: it's simply the creation of function pointers for many tasks. For me, nearly 100% of the time it's to create them to be stashed away as callbacks. And in Java, the only realistic way to do this still is with anonymous classes.
- kjeetgill 4y ago
  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

Just last night I put out the latest versions of two open source tools totaling about 500K lines in Java. Sure I enforce an old style but I think I'm up to date with the latest in Java. It's funny how Java developers perceive "lambdas" as (param, param) -> { code } blocks to be used in consumers and iterators etc. This is a weird mutation of the general concept due to Java's lack of functions: as a Lisp developer I don't perceive lambda expressions like that at all. The use of lambda expressions is much more general than this: it's simply the creation of function pointers for many tasks. For me, nearly 100% of the time it's to create them to be stashed away as callbacks. And in Java, the only realistic way to do this still is with anonymous classes.

kjeetgill 4y ago
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.