Looking Past Lambda
With Java 7 recently released, plans for Java8 are well underway. One of the key features pushed from Java7 to Java8 was Project Lambda, but not through lack of interest; mailings on the lambda-dev and the compilation group have continued apace.
There have been many changes to Project Lambda's reach over the years; the Lambda analysis InfoQ article largely covers initial proposals which have since changed. However, in a recent mail, Brian Goetz offers a look past the current iteration of the Lambda project towards a more functional future:
There is plenty of evidence in the ecosystem to support the hypothesis that, if given the tools to do so easily, object-oriented programmers are ready to embrace functional techniques (such as immutability) and work them into an object-oriented view of the world, and will write better, less error-prone code as a result. Simply put, we believe the best thing we can do for Java developers is to give them a gentle push towards a more functional style of programming. We're not going to turn Java into Haskell, nor even into Scala. But the direction is clear.
Lambda is the down-payment on this evolution, but it is far from the end of the story. The rest of the story isn't written yet, but preserving our options are a key aspect of how we evaluate the decisions we make here.
This is why I've been so dogged in my insistence that lambdas are not objects. I believe the "lambdas are just objects" position, while very comfortable and tempting, slams the door on a number of potentially useful directions for language evolution.
One of the reasons for removing the (erased) function types from earlier iterations of the proposal was because the current Java type erasure system renders these kind of function types less than useful:
The lambda strawman offered at devoxx had function types. I insisted we remove them, and this made me unpopular. But my objection to function types was not that I don't like function types -- I love function types -- but that function types fought badly with an existing aspect of the Java type system, erasure. Erased function types are the worst of both worlds. So we removed this from the design.
But I am unwilling to say "Java never will have function types" (though I recognize that Java may never have function types.) I believe that in order to get to function types, we have to first deal with erasure.
Whilst the current design has lambdas being used to provide single access method types (e.g. Runnable), it doesn't preclude the ability to add other functional types at a later stage.
All the the time the same thing
In this case the designer of the language are committed the same error with lamdas and funtions types, and in the end we have an uncompleted language feature another time.
Re: All the the time the same thing
Its too late for Java to be a functional langugage
I would have said use Scala for the functional parts and Java for the rest however Scala is good at OO as well. Once a Java programmer makes an investment to learn Scala he/she will find most everything is better done in Scala.
I would say use Scala to write your own code and leverage existing Java frameworks, libraries and tools.
Re: All the the time the same thing
Have you actually encountered a situation where you really needed reified generics?
Many times, but before I answer that, I you are looking at the problem the wrong way. It is not an issue of needing needs reified generics, but an issue of coding that must go along using generics implemented via type erasure.
When implementing libraries and plumbing code, I've had a need to do have access to this type of construct: T.class (or trying to serialized/deserialized generic-based code without having to rely on @SuppressWarning and defensive code boilerplate).
Unfortunately, in general, I can't have neither due to type erasure, and have to rely on convoluted boilerplate (.ie. Class<? extends T>).
Boilerplate, boilerplate, boilerplate. If all you are doing is using already "genericided" libraries, the problem is manageable. Try implementing complex composition of generic types (in particular reusable code based on that) then you end up having to rely on convoluted boilerplate.
So either I've had to do that (making code extremely hard to comprehend for any poor soul that happens to inherit it), or to implement a large section of that without generics surrounded with a lot of @SupressWarnings and a lot of javadocs screaming that hell will break lose should someone not pass the right types to it (thus defeating the very purpose generics were supposed to solve.)
Java language designers should have 1) swallow their own ego, 2) deprecate the existing collections API, 3) implement generics without type erasure, and 4) introduce a new collections library (as C# did) that is based on true generics with a sub-package of wrapper classes for interfacing with old collection-based code.
It is what it is, though. What can we do.
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015