A peek past lambda
brian.goetz at oracle.com
Sat Aug 20 07:14:09 PDT 2011
They have not yet been published, but they will.
On 8/20/2011 9:57 AM, Serge Boulay wrote:
> All this is very interesting and I certainly like the direction you are
> going in.
> I am trying to find some of the EG discussions (for my own interest) but
> they don't seem to be here. Where would I find those ?
> On Thu, Aug 18, 2011 at 2:10 PM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
> Along the lines that we've been discussing today, here's a peek at where
> we're heading. We explored the road of "maybe lambdas should just be
> inner class instances, that would be really simple", but eventually came
> to the position of "functions are a better direction for the future of
> the language".
> This exploration played out in stages: first internally before the EG
> was formed, and then again when the EG discussed the issues. The
> following is my position on the issue. Hopefully this fills in some of
> the gaps between what the spec currently says and what we say about it.
> The issues that have been raised about whether lambdas are objects or
> not largely come down to philosophical questions like "what are lambdas
> really", "why will Java benefit from lambdas", and ultimately "how best
> to evolve the Java language and platform."
> Oracle's position is that Java must evolve -- carefully, of course -- in
> order to remain competitive. This is, of course, a difficult
> balancing act.
> It is my belief that the best direction for evolving Java is to
> encourage a more functional style of programming. The role of Lambda is
> primarily to support the development and consumption of more
> functional-like libraries; I've offered examples such as
> filter-map-reduce to illustrate this direction.
> 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.
> As a single example, let's take function types. 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. That
> may, or may not be possible. But in a world of reified structural
> types, function types start to make a lot more sense.
> The lambdas-are-objects view of the world conflicts with this possible
> future. The lambdas-are-functions view of the world does not, and
> preserving this flexibility is one of the points in favor of not
> burdening lambdas with even the appearance of object-ness.
> You might think that the current design is tightly tied to an object box
> for lambdas -- SAM types -- making them effectively objects anyway. But
> this has been carefully hidden from the surface area so as to allow us
> to consider 'naked' lambdas in the future, or consider other conversion
> contexts for lambdas, or integrate lambdas more tightly into control
> constructs. We're not doing that now, and we don't even have a concrete
> plan for doing so, but the ability to possibly do that in the future is
> a critical part of the design.
> I am optimistic about Java's future, but to move forward we sometimes
> have to let go of some comfortable ideas. Lambdas-are-functions opens
> doors. Lambdas-are-objects closes them. We prefer to see those doors
> left open.
More information about the lambda-dev