Expected distribution of lambda sizes (Re: Syntax poll, take 2)

[Collin Fagan]

How small exactly? I just have a feeling that I will be using method
references more often then inline lambdas.

int maxFamilyMemberAge = personList.filter(#withMyLastName)
     .map(#calculateAge)
     .max();

I can then just use public or private methods to satisfy the interface.
Methods can be javadoced and even used without lambdas being involved.

So for me the inline syntax will probably only be used when the lambda is so
trivial that it's immediately recognizable as to what it does.

Now what is a trivial lambda? I can think of 2 right now.

1. Simply calling a method on the input parameter of the lambda.

List men = personList.filter(#(Person p){ p.isMale() } );

But if we have method literals (and I think this is part of the project
still) then it's probably simpler to do this.

List men = personList.filter(Person#isMale);

2. A simple calculation.
List<Double> adjustedPrices = prices.map(#(Double price){ price +
getShipping() });

I've seen inline classes for action listeners or renders and it's messy as
soon as you go more then a couple of lines. Most of the simple ones just
call other methods. Certainly nested inline classes get harry rather
quickly.

If there was been research on how, and the number of places one could apply
lambdas in existing code, could we see some examples?

Thanks,

Collin

On Mon, Jun 13, 2011 at 12:34 PM, Brian Goetz <brian.goetz at oracle.com>wrote:

> Thanks, Reinier, for bringing this up.  This was on my list of things to
> start discussion threads on.  There are a number of aspects that you
> raise here.
>
> 1.  Most syntactic forms fit better with either "little lambdas" or "big
> lambdas".  This means either:
>  - We be willing to pick something that is mediocre for all the cases,
> rather than good for one case and bad for another;
>  - We be willing to say "Case A is more important than case B", and
> pick the one that looks better for case A;
>  - We be willing to have more than one syntax.
>
> Of course, it would be ideal to find something that is great for all of
> the cases, but I think we know that's not going to happen.
>
> Drilling into the issue of "what is the target idiom for lambda", I
> think this is highly dependent on what library features we add, and also
> time varying as newer lambda-friendly library idioms gain adoption.
>
> Personally my leaning is that we should favor the small lambdas (e.g.,
> #{ x -> x+1 }).  Because we already have an acceptable syntax for "big
> lambdas" -- inner classes -- and the syntactic improvements of lambdas
> over inner classes are mostly compactness.  This is huge for the small
> lambdas like #{ x -> x+1 }, but almost negligible for twenty-line
> Runnables.
>
> So I am not sure I agree with your assumption that lambdas will mostly
> be multi-statement.
>
> Further, the distribution of lambda sizes will almost certainly skew
> over time, as the libraries are enhanced with more methods like filter()
> which will usually take small lambdas, and this increased number of
> small lambdas pulls the average towards the one-liner.  (If we had
> embraced control abstraction a la BGGA, it might skew in the other
> direction.)
>
> 2.  A key aspect of selecting a syntax is promoting a preferred style
> (and encourage the IDE vendors to promote it as well).  This is
> absolutely true, but would be premature at this point.  First we have to
> decide what we want.
>
> 3.  Small-vs-large is not the only axis over which you want to vary your
> experimental examples.  Also small arity vs large arity (with nilary
> being an interesting special case in some forms, and unary offers the
> possibility for a special coase in some forms too), and context: method
> parameter, assignment target, etc.
>
> 4.  Line-breakability of the different idioms.  I'm not sure I buy your
> claim that only strawman works well in multi-line.  Consider this
> variant of BGGA:
>
> Foo f = { (s, t) ->
>           blah(s);
>           blah(t);
>           return wooga(s+t);
>         };
>
> This doesn't look all that different from the equivalent in Ruby:
>
> Foo f = { |s, t|
>           blah(s)
>           blah(t)
>           wooga(s+t)
>         };
>
> Now, you may or may not like Ruby's lambda syntax, but I've never heard
> anyone complain that it doesn't scale to multiple lines.  And the C#
> guys seem to do OK with multi-line lambdas in Redmond.
>
>
> > I'm concerned that this poll relies a little too much on your average
> > lambda-devver experimenting.
> >
> > The instructions include examples, but these examples are rather
> > unlikely to be representative of what Joe Java is _ever_ going to write.
> > Anyone filling in this poll based primarily on looking at them is going
> > to make an uninformed decision.
> >
> > All examples in the instructions share 2 properties:
> >
> > (A) They are a single expression.
> >
> > (B) They are written as a physical single line. (one-liner).
> >
> > While some closures will certainly be a single expression, I'd expect
> > many (probably over three quarters*) to be multi-statement, and some to
> > be single statement, which is for some proposals actually relevant.
> > Piling multiple statements all on one line is obviously not going to
> > happen in actual live code use, and the instructions do not offer any
> > suggestion as to what that would look like (in fact, in many cases the
> > syntax isn't even clear!)
> >
> > More to the point, writing these things in a single line does not seem
> > like something Joe Java will ever do. The majority of the community will
> > refuse to write something like:
> >
> > if (x == null) return null;
> >
> > instead adding braces and some newlines. Given that the community
> > evidently finds that too complicated to one-line, I fail to see how any
> > of the closure examples are palatable to Joe Java. Why do we think
> > closures will all of a sudden cure Joe from his obsession with line
> breaks?
> >
> > The only one of the 4 proposals that is obviously line-breakable is
> > strawman (newline after the brace, just like everywhere else in java).
> > For all other proposals I'd like to see a style guide which is suitable
> > for Joe Java (i.e. does not attempt to pile too much into a single
> > line), and which is virtually enforced (i.e. consistently applied
> > everywhere, with a link to a style guide distributed at the same time as
> > the official proposal) as lambda is promoted to blogs and eventually
> > java 8, so that most of the community ends up using a single style to
> > write them. Nothing is more annoying than a language where the community
> > breaks into a near even split across various completely different
> > styles. See tabs v. spaces debate. I doubt anyone would argue that's
> > good for the language.
> >
> >
> > *) Very *very* few closures used in my own code as well as open source
> > projects I looked at ever use closures with a tiny one-expression body.
> > However, if lambdas had been in java, code that currently doesn't use
> > closures might have used closures, i.e. the balance between
> > one-expression closures and (much) larger ones is different when
> > closures are easier to use. Nevertheless, it seems obvious that
> > multi-statement closures will not all of a sudden become the rare case
> > when lambda is out.
> >
> >   --Reinier Zwitserloot
> >
> >
> >
> > On Sat, Jun 11, 2011 at 9:44 PM, Brian Goetz <brian.goetz at oracle.com
> > <mailto:brian.goetz at oracle.com>> wrote:
> >
> >      > I'm curious - why the 100 responses limit? Is that how few people
> are
> >      > subscribed to lambda-dev? (I can't check myself right now, sorry)
> >
> >     Partially laziness -- the easiest way to do the survey was the free
> >     SurveyMonkey account, which is limited to 100.  There are ~300
> >     subscribers on lambda-dev, but only ~100 that have posted.  So the
> >     laziness-induced limit seemed adequate to the task.  And if 100 is
> not
> >     enough, 200 (two polls) will surely be.
> >
> >     The polluted poll has been set aside and you have a chance to express
> >     yourself in the new one.
> >
> >
>
>