5 ms·

What about the fact that Java didn't want lambda in the first places, only to hack anonymous inner classes that were never well promoted until 20 years down the

What about the fact that Java didn't want lambda in the first places, only to hack anonymous inner classes that were never well promoted until 20 years down the road people realize it's quite useful to express logic as functions ? :)

nextos 4y ago
This was a mistake. Actually, Gosling said he was planning to add lambdas but ran out of time. Some APIs were excessively verbose due to the lack of lambdas, which were emulated using anonymous inner classes.
- agumonkey 4y ago
  Interesting, not what I recall (but my readings on this were quick). AFAIK it was carefully not pursued because they wanted to make everything as classes so they went with AIC. If you have a link, please share.
  - nextos 4y ago
    There might be some better (primary) sources: Gosling say closures represent the realization of a dream that was postponed in Java's early days and resulted in the invention of inner classes - "an uncomfortable compromise" that failed to provide the desired level of simplification. He notes criticism that closures are too complex, but advises people to read "through all of what Neal has written". https://www.theregister.com/2008/02/01/java_closures/ https://www.theregister.com/2008/02/01/java_closures/
    - agumonkey 4y ago
      I think I read about early java design on c2. I might dig later.
  - Viliam1234 4y ago
    > they wanted to make everything as classes Java is mostly about interfaces. Classes are just a way to implement them. This is one of the differences between Java and C/C++.
  - kjeetgill 4y ago
    I mean, from your comments I don't expect you to like it, but lambdas are still mostly anonymous classes. The way lambdas bind to SAM interfaces and implement them is pretty different than say scala or even C/C++ function pointers where the necessary parameter/return type can be encoded into a variables type and referred to directly. I think that's cool enough but one of the subtle elements of design brilliance was how local variables must be final to be bound into a closure. There's a whole class of ambiguity removed and static guarantees in the face of concurrency that I think goes unappreciated.
    - kaba0 4y ago
      I’m not sure whether you mean semantically or in implementation, but from the latter point of view they are rather compiled as static functions and an invokedynamic instruction that will resolve to them at first occurrence.
      - kjeetgill 4y ago
        > I’m not sure whether you mean semantically or in implementation I'll have to mull over that. I guess to me they seem aligned enough, thats why it feels so elegant. Or maybe I haven't thought about it enough. > rather compiled as static functions and an invokedynamic instruction that will resolve to them at first occurrence Yea! but that invokedynamic calls the lambda metafactory which spins up bytecode for a class with 2 things: a) a constructor to bind the values captured from the scope the lambda was declared in to fields, and b) an instance method that feeds those fields to the static function you referred to. I'd argue that that class is essentially an anonymous class. Maybe I'm easily impressed, but that functional programming <-> OOP duality of lambdas/closures and SAM interfaces always felt profound. We can get along! There's no need for this feud!
        kaba0 4y ago
        I just wanted to add something I knew on the topic, but you seem to know much more! Thanks for the interesting read, and it is indeed a cool duality!
Tomte 4y ago
Who cares? Are you a programmer or a historian? Thing is, they turned it around.
- agumonkey 4y ago
  - kmonsen 4y ago
    I think parents comment is ok. I will evaluate it based on what it has today.
kaba0 4y ago
Because it came from a very different time, following closely in C++’s OOP madness footsteps.
PaulHoule 4y ago
Inner classes are pretty useful. This library contains a huge number of Iterables, each of which has at least one Iterator implementation. https://github.com/paulhoule/pidove https://github.com/paulhoule/pidove It is convenient to let the Iterator be immutable and the Iterator be an inner class that gets its configuration information out of the Iterable. (That said, if people really thought seriously about Iterator being a Supplier<Iterable> people might think more rationally about error handling. Also in a slightly parallel universe the Iterator would only have one method since remove() hardly ever gets used and having both hasNext() and next() methods is asking for bugs.)
- agumonkey 4y ago
  The issue is that it's anonymous logic recreated above classes. I think it obscures the purpose, making them quite verbose. Unlike FP languages where it's central and a convenient thinking and working tool. With added bonus of currying, it's really a different feel. The few years i had to operate in java it was seldom used and advertised.

nextos 4y ago

This was a mistake. Actually, Gosling said he was planning to add lambdas but ran out of time. Some APIs were excessively verbose due to the lack of lambdas, which were emulated using anonymous inner classes.

agumonkey 4y ago
Interesting, not what I recall (but my readings on this were quick). AFAIK it was carefully not pursued because they wanted to make everything as classes so they went with AIC. If you have a link, please share.
- nextos 4y ago
  There might be some better (primary) sources: Gosling say closures represent the realization of a dream that was postponed in Java's early days and resulted in the invention of inner classes - "an uncomfortable compromise" that failed to provide the desired level of simplification. He notes criticism that closures are too complex, but advises people to read "through all of what Neal has written". https://www.theregister.com/2008/02/01/java_closures/ https://www.theregister.com/2008/02/01/java_closures/
  - agumonkey 4y ago
    I think I read about early java design on c2. I might dig later.
- Viliam1234 4y ago
  > they wanted to make everything as classes Java is mostly about interfaces. Classes are just a way to implement them. This is one of the differences between Java and C/C++.
- kjeetgill 4y ago
  I mean, from your comments I don't expect you to like it, but lambdas are still mostly anonymous classes. The way lambdas bind to SAM interfaces and implement them is pretty different than say scala or even C/C++ function pointers where the necessary parameter/return type can be encoded into a variables type and referred to directly. I think that's cool enough but one of the subtle elements of design brilliance was how local variables must be final to be bound into a closure. There's a whole class of ambiguity removed and static guarantees in the face of concurrency that I think goes unappreciated.
  - kaba0 4y ago
    I’m not sure whether you mean semantically or in implementation, but from the latter point of view they are rather compiled as static functions and an invokedynamic instruction that will resolve to them at first occurrence.
    - kjeetgill 4y ago
      > I’m not sure whether you mean semantically or in implementation I'll have to mull over that. I guess to me they seem aligned enough, thats why it feels so elegant. Or maybe I haven't thought about it enough. > rather compiled as static functions and an invokedynamic instruction that will resolve to them at first occurrence Yea! but that invokedynamic calls the lambda metafactory which spins up bytecode for a class with 2 things: a) a constructor to bind the values captured from the scope the lambda was declared in to fields, and b) an instance method that feeds those fields to the static function you referred to. I'd argue that that class is essentially an anonymous class. Maybe I'm easily impressed, but that functional programming <-> OOP duality of lambdas/closures and SAM interfaces always felt profound. We can get along! There's no need for this feud!
      - kaba0 4y ago
        I just wanted to add something I knew on the topic, but you seem to know much more! Thanks for the interesting read, and it is indeed a cool duality!

Tomte 4y ago

Who cares? Are you a programmer or a historian? Thing is, they turned it around.

agumonkey 4y ago
- kmonsen 4y ago
  I think parents comment is ok. I will evaluate it based on what it has today.

kaba0 4y ago

Because it came from a very different time, following closely in C++’s OOP madness footsteps.

PaulHoule 4y ago

Inner classes are pretty useful. This library contains a huge number of Iterables, each of which has at least one Iterator implementation. https://github.com/paulhoule/pidove https://github.com/paulhoule/pidove It is convenient to let the Iterator be immutable and the Iterator be an inner class that gets its configuration information out of the Iterable. (That said, if people really thought seriously about Iterator being a Supplier<Iterable> people might think more rationally about error handling. Also in a slightly parallel universe the Iterator would only have one method since remove() hardly ever gets used and having both hasNext() and next() methods is asking for bugs.)

agumonkey 4y ago
The issue is that it's anonymous logic recreated above classes. I think it obscures the purpose, making them quite verbose. Unlike FP languages where it's central and a convenient thinking and working tool. With added bonus of currying, it's really a different feel. The few years i had to operate in java it was seldom used and advertised.