|
> But then, they added their "bulk operations" to collections and started to realize they were in trouble, because there didn't exist any SAM types they could use _and_ coming up with names for anonymous function literals was kind of idiotic. But with function types already ruled out and time running short, they decided to make up ad-hoc function types. This is simply not true. Doug Lea, the author of java.util.concurrent, and of ForkJoin in particular, was one of the main driving forces behind lambdas; he requested them about 7 years ago precisely for those bulk operations. The same Doug Lea rejected function types way back then in favor of CICE. Already back in 2007-2008 it became clear that function types are a bad fit for Java. Java's designers explicitly mentioned currying, general functional-style programming, and user-defined control structures as things they wanted to avoid. These things may very well have a place in other programming languages, but not in Java. If you don't want a blue-collar programming language then Java is simply not meant for you. Java, like Clojure or Haskell, has a very specific flavor. A feature can be right for one language but not for another. > A bit later, they also realized that all the boxing had a non-negligible impact on performance, so they started to add _some_ ad-hoc specializations to the already ad-hoc function types, but of course not _all_ of them. Not even mentioning that the naming is just completely out of whack. Again, not true. Java's designers are extremely focused on performance, and did not "realize" all of a sudden boxing has a non-negligible impact on performance. Also, those are not "ad hoc" specializations. All they did was pre-define some small subset of possible function types that they figured will be widely used. Again, the idea is always do the least "powerful" thing possible that will give you the most benefit. |
How is this in any way disagreeing with what I said? Did you actually look at Doug Lea's reasoning back then? I don't think he would defend any of his claims today. Back then, the issues caused by not having function types just weren't anticipated. This would be obvious if one followed the appropriate mailing lists where this was discussed in depth.
> Already back in 2007-2008 it became clear that function types are a bad fit for Java. Java's designers explicitly mentioned currying, general functional-style programming, and user-defined control structures as things they wanted to avoid.
Beating down your own straw men seems to be your hobby, I guess?
> Again, not true. Java's designers are extremely focused on performance, and did not "realize" all of a sudden boxing has a non-negligible impact on performance.
No, they were just betting the house that the JVM engineers would save their asses, but as we know that didn't work out so well. They didn't really have a plan B, so they started to manually duplicate code for some primitive types.
> Again, the idea is always do the least "powerful" thing possible that will give you the most benefit.
This hasn't worked out at all and is one of the reasons why Java is incredibly hard to evolve. One just can't keep piling half-assed ideas on top of each other forever.
Anyway, I'm not sure why you are so defensive. Yes, Java will ship with some kind of lambdas, but they will be inferior to pretty much anything out there in terms of usability, readability, maintainability, performance and will be a major pain point when evolving the language in the future.
Why not just accept it and move on?