3 ms·

I'm not disagreeing with you, but regarding your examples, am I the only one that prefers the way lambdas and streams are implemented in Java? First of all, t

I'm not disagreeing with you, but regarding your examples, am I the only one that prefers the way lambdas and streams are implemented in Java? First of all, the way lambdas are implemented at the JVM level was a big improvement on what others were doing. And Scala is actually moving in that direction, if I'm not mistaken. And regarding streams, I prefer one clean interface to having all the collection interfaces polluted with 1000 methods. Not to mention that in scala you have those traps, like when you are applying a map over a set and you end up with less elements than expected.

lmm 11y ago
> I'm not disagreeing with you, but regarding your examples, am I the only one that prefers the way lambdas and streams are implemented in Java? I think you're the only one that prefers not having FunctionN interfaces. I remember someone releasing a library of all the separate cases in Java pretty soon after the functionality came out. Optimizing lambdas with a JVM opcode is cool. Delaying implementing them until you can add an opcode for it is not cool. I feel like Java should have been able to implement them like Scala did, and add the optimization later if necessary. > And regarding streams, I prefer one clean interface to having all the collection interfaces polluted with 1000 methods. Agreed for methods that are "secondary", but I think many of those methods are fundamental to being a collection. It's very weird to me if I have to change my List into something else to do a basic list operation on it. And even for secondary operations I think a typeclass is a much more elegant way of separating those operations than having to wrap and unwrap. > Not to mention that in scala you have those traps, like when you are applying a map over a set and you end up with less elements than expected. Any polymorphic method will behave differently on different types - that's the whole point of polymorphism. I'd agree that map is a bad name for something with the semantics of the Scala method. Unfortunately at this point that's not realistically something we can change.

lmm 11y ago

> I'm not disagreeing with you, but regarding your examples, am I the only one that prefers the way lambdas and streams are implemented in Java? I think you're the only one that prefers not having FunctionN interfaces. I remember someone releasing a library of all the separate cases in Java pretty soon after the functionality came out. Optimizing lambdas with a JVM opcode is cool. Delaying implementing them until you can add an opcode for it is not cool. I feel like Java should have been able to implement them like Scala did, and add the optimization later if necessary. > And regarding streams, I prefer one clean interface to having all the collection interfaces polluted with 1000 methods. Agreed for methods that are "secondary", but I think many of those methods are fundamental to being a collection. It's very weird to me if I have to change my List into something else to do a basic list operation on it. And even for secondary operations I think a typeclass is a much more elegant way of separating those operations than having to wrap and unwrap. > Not to mention that in scala you have those traps, like when you are applying a map over a set and you end up with less elements than expected. Any polymorphic method will behave differently on different types - that's the whole point of polymorphism. I'd agree that map is a bad name for something with the semantics of the Scala method. Unfortunately at this point that's not realistically something we can change.