4 ms·

This talk explains why: https://www.youtube.com/watch?v=MLksirK9nnE https://www.youtube.com/watch?v=MLksirK9nnE

revelation 12y ago
Read "people wouldn't stop harassing us for lambdas after we decided to delay them again and again, and so we half-assed a solution that is easy for us and binds into all the overengineered class hierarchies you have lying around".
- BrandonM 12y ago
  I believe Hacker News calls this a Minimum Viable Product.
  - mateuszf 12y ago
    MVP and 100% backward compatibility don't go with each other well.
    - BrandonM 12y ago
      The linked talk actually does a pretty good job describing how Java 8's Lambda is both backwards compatible and forward thinking. 1. The idea of @FunctionalInterface leveraged practices that were already in use--interfaces with a single method--for Comparator, Runnable, Callable, and external libraries. This meant that users could use lambdas to implement such interfaces immediately, with no changes to existing libraries. 2. The actual implementation of a lambda in bytecode is a single invokedynamic call. They went that route to avoid tying the bytecode representation to their initial implementation. A future change could add true function types, and have them automatically instantiate a target functional interface (provided that they have the same "shape"). That would require a language change (adding function types), but not a bytecode change. That would have the nice result that all the code that people are writing now could work with new function types, and new code could be written to accept the function types instead of functional interfaces. My library would become unnecessary at that point, and I would be pretty happy about that. That is, Java 8's lambda implementation does not preclude fully-backwards-compatible "real" lambdas in the future. Personally, I think the Lambda project was a well-reasoned, intelligent step forward. The video is really worth watching, because I wasn't aware of how flexible their future directions are until I watched it.
      - mateuszf 12y ago
        Thanks. But that is totally compatible with what I said. Java lambdas were well thought out, doing MVP style development would highly likely blow it.
      - frowaway001 12y ago
        > That is, Java 8's lambda implementation does not preclude fully-backwards-compatible "real" lambdas in the future. No, it just made them a lot harder to achieve, because any decent "real" lambda implementation requires now the introduction of another language feature: type aliases.

Read "people wouldn't stop harassing us for lambdas after we decided to delay them again and again, and so we half-assed a solution that is easy for us and binds into all the overengineered class hierarchies you have lying around".

BrandonM 12y ago
I believe Hacker News calls this a Minimum Viable Product.
- mateuszf 12y ago
  MVP and 100% backward compatibility don't go with each other well.
  - BrandonM 12y ago
    The linked talk actually does a pretty good job describing how Java 8's Lambda is both backwards compatible and forward thinking. 1. The idea of @FunctionalInterface leveraged practices that were already in use--interfaces with a single method--for Comparator, Runnable, Callable, and external libraries. This meant that users could use lambdas to implement such interfaces immediately, with no changes to existing libraries. 2. The actual implementation of a lambda in bytecode is a single invokedynamic call. They went that route to avoid tying the bytecode representation to their initial implementation. A future change could add true function types, and have them automatically instantiate a target functional interface (provided that they have the same "shape"). That would require a language change (adding function types), but not a bytecode change. That would have the nice result that all the code that people are writing now could work with new function types, and new code could be written to accept the function types instead of functional interfaces. My library would become unnecessary at that point, and I would be pretty happy about that. That is, Java 8's lambda implementation does not preclude fully-backwards-compatible "real" lambdas in the future. Personally, I think the Lambda project was a well-reasoned, intelligent step forward. The video is really worth watching, because I wasn't aware of how flexible their future directions are until I watched it.
    - mateuszf 12y ago
      Thanks. But that is totally compatible with what I said. Java lambdas were well thought out, doing MVP style development would highly likely blow it.
    - frowaway001 12y ago
      > That is, Java 8's lambda implementation does not preclude fully-backwards-compatible "real" lambdas in the future. No, it just made them a lot harder to achieve, because any decent "real" lambda implementation requires now the introduction of another language feature: type aliases.