14th October Lambdas Hackday
paul.sandoz at oracle.com
Mon Oct 22 07:45:01 PDT 2012
On Oct 21, 2012, at 3:56 PM, Richard Warburton <richard.warburton at gmail.com> wrote:
> Lambdas Hackday
> Last Sunday (14th October) the London Java Community ran another
> hackday on the lambdas binary builds. Brian Goetz was there, so i
> imagine that the majority of the feedback has already been discussed
> somewhat. I still think its useful to post a brief summary of what
> people found confusing to the public lists so people outside the EG
> can see what’s going on.
> 1. What is the idiomatic way of expressing a generator function? So
> far no one has answered this one for me, and I can't think of a good
> answer myself!
> 2. The design of flatMap confused a lot of people. They didn’t seem
> to understand the callback was a block. It was much easier to explain
> the intended purpose via an example than anything else. It might
> simply be the case that ‘Block’ is a bad name for result callback
> handler, though I appreciate that people wish to avoid interface
> 3. People didn’t understand why Stream.fold() takes both a Combiner
> and a BinaryOp, rather than just a combiner.
Right, its not obvious, since the BinaryOp only kicks in on parallel streams, to combine results (like the reduce part of map/reduce). Developers may be tempted to pass in null (see recent email thread on "fold throws NPE when using parallel() variant on the collection").
> 4. Any code that relies on getClass() is hard to transform from an
> anonymous inner class into a lambda. This is because getClass() on a
> lambda returns the class that it was defined within, rather than the
> class of the anonymous inner class. It makes sense from the
> perspective of lambdas being like blocks - but it will break things
> down the line so there should probably be at least a “Beware!” type
> 5. The base argument of Stream.reduce() needs to be the identity value
> of the combiner function if you're to get the correct answer when
> running in parallel. This wasn't at all obvious to developers, and
> seems like a real gotcha for people when parallel collections are
> meant to be a simple method of obtaining parallelism.
Good observation. I can see why that would be a surprise. For the current implementation in the parallel case each leaf node in the computation tree will be initiated with the seed value, rather than just the left most leaf node. IMHO that is a bug.
> I’ll omit the bug reports (since Maurizio has already fixed them) but
> link to a full feedback pastebin that people used below:
> Thanks to Brian for coming over and The JAX London Conference for
> space to run the hackday in.
More information about the lambda-dev