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

[Pavel Minaev]

I don't think it's meaningful to compare lambdas to conditionals. In your
example, "if" is a statement, but lambda is an expression. And I don't see
people wrapping things like "(a + b) * b" on several lines.

Statement lambdas would typically be thus wrapped, yes (coincidentally, it's
also why I'd prefer to have a separate form for expression lambdas which
does not include the {} so as to be visually distinct from statement
blocks).

On Mon, Jun 13, 2011 at 1:02 PM, Reinier Zwitserloot <
reinier at zwitserloot.com> wrote:

> Assuming for a moment that lambdas tend towards the small, and that for
> larger ones one should either accept less suitable syntax or stick with
> Anonymous Inner Class literals / method references (not sure that's an
> acceptable argument to make, but lets assume for now):
>
> That still leaves the issue that Joe Java doesn't like piling nested nodes
> into a single line, i.e. the prevalence of code like this:
>
> if (x == null) {
>    return false;
> }
>
> vs:
>
> if (x == null) return false;
>
> Do we expect Joe Java to do the opposite for closures? Maybe. I prefer the
> latter, one-liner style. But this is one of those cases where we 'language
> aficionados' should perhaps defer to the community.
>
> Secondly, control abstractions tend, as has been said, towards long
> closures, and I don't think we should ignore that use case here.
>
>  --Reinier Zwitserloot
>
>
>
> On Mon, Jun 13, 2011 at 9:08 PM, Collin Fagan <collin.fagan at gmail.com
> >wrote:
>
> > 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.
> >> >
> >> >
> >>
> >>
> >
>
>