closures after all?

[Kevin Bourrillion]

Hello everyone,

I have a particular interest in the current debate (over the potential
deleterious effects of closures on APIs) as the person who, a few years ago,
introduced the Function and Predicate interfaces into Google's internal
codebase.  To be sure, these have been useful, and we've found many great
uses for them.

I've also seen too many completely appalling usages of them to count.  To
give just one example, I once came across a class whose constructor required
two Functions and Predicate, on various types, storing those in fields, and
whose documentation (of course) quite glossed over the finer details of
their semantics.  So I asked the author, "why do it this way -- wouldn't it
be more natural to just define three abstract methods, with regular old
javadoc and the whole bit -- or define an interface with these three
methods, to be passed in?  Logically, it could be named Xxx, and that helps
users understand what it's really all about."

His response? "Oh, I hadn't thought of that! You're right, it's totally
better that way."

::headdesk::

I think I went home early that day.  But this wasn't an isolated incident.
 This kind of thing happens a LOT.  Most developers, by FAR, do not really
put conscious thought into the art of API design.  Their job is usually to
implement a feature, which requires them to make small changes at many
different layers of the system -- so every API boundary they touch is one
where they are both the implementor and the consumer.  It doesn't feel too
important to them how exactly they choose to talk to *themselves*.  So they
walk the path of least resistance.  If their first thought is, "I need a way
to get from a Foo to a Bar," then their second thought is, "ahh, that's a
Function<Foo, Bar> then!"

When you consider how bloated and boilerplate-laden these Function and
Predicate incantations are, then you can only conclude that this will be
happening at a much greater scale once closures are here. Give me a shiny
new hammer, and suddenly everything I see looks like a nail!

Is potential for abuse alone ever a sufficient argument for killing a
feature?  Definitely not.  And I'm not even opposed to this new closures
proposal (such as I understand it); I think it will probably make a lot of
code better.  I do, however, think it is easily within the realm of
possibility that it will make even more code worse.  Lawrence is explaining
some the reasons very well in this thread.

My two cents.


On Mon, Nov 23, 2009 at 1:30 PM, Tim Peierls <tim at peierls.net> wrote:

> On Mon, Nov 23, 2009 at 3:35 PM, Neal Gafter <neal at gafter.com> wrote:
>
> > On Mon, Nov 23, 2009 at 12:02 PM, Tim Peierls <tim at peierls.net> wrote:
> >
> >> Here's an imperfect but suggestive analogy: More options in the
> treatment
> >> of a disease might offer hope to millions, but the physician's job is
> harder
> >> because she has to evaluate more options in the context of each patient.
> She
> >> might be glad to be able to offer her patients a promising new therapy,
> but
> >> she is working longer hours (or seeing fewer patients).
> >>
> >
> > Doctors can do better by their patients by investing more time, with or
> > without new techniques.  On the other hand, she may be able to save more
> > lives with the same effort by taking advantage of the new techniques.
>  That
> > seems to be the way it works in practice.
> >
>
> Not the way the physicians I know talk about it. A new technique can be a
> great boon, but in practice it means more work for physicians. My wife, a
> physician, reacts to each new development with deep ambivalence: it's
> wonderful to have that new option, but now she has more to learn, and her
> list of things to check off for each patient just got that much longer.
>
> OTOH, she's terrible at API design. :-)
>
>
>
> > Here's another: The addition of a new instrument when scoring a musical
> >> theater piece broadens the palette of available colors. The orchestrator
> is
> >> probably pleased when the producers cough up the extra dough for the
> player,
> >> because now he can achieve certain effects more easily, but he also
> knows
> >> that he'll be working harder -- it's another part to write. (But he's
> >> getting paid more, so he's not going to object. :-))
> >>
> >
> > The ochestrator can do a better job by investing more time with or
> without
> > new instruments.  On the other hand, he may be able to better achieve his
> > goals with the same cost and effort by taking advantage of a new
> instrument
> > in place of a more traditional one.
> >
>
> Another part to write is another part to write, no matter how desirable the
> resulting sound. Much as I love being able to add drums to a plain piano
> part, because it makes it easier to get the rhythms across to the actors in
> performance, it's a *lot* of work, so much that every time I do it I think,
> "Hmm, how badly do I want drums in this song?"
>
> But getting back to the point: Neal and Reinier, you're working very hard
> to
> argue something general and hard to support -- that new language features
> don't mean more work for API designers -- when you should be arguing that a
> particular feature is *worth* the extra work. That's the important
> question.
> It's hard to engage in a meaningful discussion of costs and benefits if you
> don't acknowledge the possibility of costs.
>
> And while I don't think ParallelArray is a compelling case for function
> types over named interfaces based on my experience, I'm interested in
> hearing about other people's experiences with it, and I certainly think
> it's
> worth investigating other applications of function types that might prove
> more compelling.
>
> --tim
>
>


-- 
Kevin Bourrillion @ Google
internal:  http://go/javalibraries
external: guava-libraries.googlecode.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091123/3425f001/attachment.html