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