Project Lambda: Java Language Specification draft 0.1.5

[Reinier Zwitserloot]

That's not the principle of least surprise. The PLS means: If a significant
chunk of those people using it think a certain library call or construct
does X, and believe this is sufficiently logic to not immediately dive for
the documentation, but this call or construct actually does Y, that's a
violation of PLS. That's _clearly_ not happening here. The only possible
expectation here is that "foo.()" is simply invalid syntax, but this
argument feels like weak tea to me: You can make that argument against just
about every new language feature.

The dot is easy to miss: No, it isn't. If you take the union of the groups:

 [ programs in a non-monospace font OR uses a style convention to add spaces
right before the open paren in a method invocation ]

you've covered everyone that could possibly miss it. I don't have research,
but I very much doubt it's a big group.

the dot is "obscure and esoteric": That's a pleonasm. It also needs backup -
what's obscure about it? The dot is a widely known character that stands for
"dereference". Parentheses following dots stand for method invocation. Seems
about right. Sure, if you show this syntax to an average joe Java programmer
on the street today it's likely he wont know what it means, which does not
reflect well on this syntax proposal, _but_, that by itself cannot be a
mandatory feature of a language change, for obvious reasons.

"faulty looking syntax": That argument can be used against any language
feature, and is hence meaningless.


I don't think shortening ".invoke" to just "." is particularly important,
but as Mark said, the way lambda-dev is heading, closures are being 'sold',
so to speak, as function calls and not merely as inline SAM implementations
similar to Anonymous Inner Class literals. Invoking a method with no name,
while perhaps surprising to some, is the whole point - if we add closures at
all with function types then this idea needs to become part of Joe Java's
toolbox, there's no getting around it.

--Reinier Zwitserloot



On Tue, Feb 16, 2010 at 9:45 AM, Paul Benedict <pbenedict at apache.org> wrote:

> My only advice is to keep simplicity and the obvious in mind. I think
> the "object.()" syntax violates the principle of least surprise -- I
> was surprised to suddenly see method calls without a method name. The
> decision does make sense within context, but it is obscure and
> esoteric; I think it's too much of a break with the past. If you
> really believe that the "object.()" syntax is the best, I'll trust
> your decision (i.e., having a doctorate, working on C#, etc.) but I
> wanted to raise my objection still.
>
> On Tue, Feb 16, 2010 at 12:57 AM, Neal Gafter <neal at gafter.com> wrote:
> > On Mon, Feb 15, 2010 at 10:40 PM, Paul Benedict <pbenedict at apache.org>
> wrote:
> >> Thanks for the links. To offer my perspective, those who support the
> >> syntax don't appear to have a typical background -- usually those who
> >> are admitted language designers or are serious hobbyists about
> >> languages. If that sounds funny for a "lamda dev" mailing list,
> >> there's definitely a spread subscribed here based on responses.
> >> Nothing wrong with that. I just think those who opposed better
> >> represented the casual Java population. Not being a language designer
> >> myself, I empathize with their position.
> >
> > Yes, I definitely see that point.  Experienced language developers are
> > often better able to judge how difficult a job it will be for
> > developers to internalize a language change based on experience with
> > other languages, while programmers often fear things that appear to be
> > different, even though that difference may improve their lot once they
> > begin using the feature.
> >
> > In any case, this isn't a democracy.  We get to peek over the
> > shoulders of folks at Sun every now and then to see their progress.
> >
>
>