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

[Brian Goetz]

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.
>
>