3 ms·

With professional Java8 and Scala experience, and as a published author of a book that uses both languages side by side, I strongly disagree. Look at how Java8

With professional Java8 and Scala experience, and as a published author of a book that uses both languages side by side, I strongly disagree. Look at how Java8 implements lambdas via a Single Abstract Method (SAM) - it's syntactic sugar. Or look at the streams api and collections library - Java8 IS the hack on top of Java. Scala is built from the ground up to be a better language. Java8 is not at all comparable with Scala. There is a giant gap in the quality of the core libraries and the quality of the language and implementations of functional features. Part of the problem is the history of the language. Bless java for the jvm but saying that scala is extrenous and that java should be improved to have those features ignores the evidence that it can't be done well ontop of what is already there.

randomThoughts9 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? 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.

randomThoughts9 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? 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.