A peek past lambda

Brian Goetz 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 mailing list