Syntax poll, take 2
Tom Brus
tombrus at gmail.com
Mon Jun 13 11:43:55 PDT 2011
+1
On Mon, Jun 13, 2011 at 20:20, Neal Gafter <neal at gafter.com> wrote:
> On Mon, Jun 13, 2011 at 9:30 AM, Reinier Zwitserloot <
> reinier at zwitserloot.com> wrote:
>
> > 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).
> >
>
> My experience with C# - and particularly with the aggregate-data operations
> that are a prime motivator for project lambda - is that the majority of
> lambdas are indeed single-expression ones. That's why I prefer a syntax
> similar to C#'s (which, incidentally, did not appear among the choices):
>
> () -> expression
> () -> { statements }
> id -> expression
> id -> { statements }
> ( paramList ) -> expression
> ( paramList ) -> { statements }
>
> I believe that if project Lambda does a good job, the experience of Java
> (e.g. the distribution of sizes of lambda expressions) will be similar to
> that of C#. For that to come about it must be easy and natural to write
> code using bulk data operations.
>
> The really-simple lambda expressions (e.g. bulk data operations) are the
> ones where project Lambda has an opportunity to make the most difference
> compared to anonymous inner classes. If the body is already 10-20 lines, a
> lambda isn't much better than an anonymous inner class. But for really
> small ones, it is the friction of the anonymous inner class syntax that
> really makes that style of programming tedious. The more concise the
> lambda
> syntax, the easier those cases become.
>
> Cheers,
> Neal
>
>
More information about the lambda-dev
mailing list