closures after all?

[Reinier Zwitserloot]

We should invent a new rule: When you start equating language design to
random real-world contrived examples, you lose. I can come up with a zillion
analogies in favour of any programming language design argument. Let's
instead agree not to foist such analogies on each other.

Can you perhaps contribute something of more useful substance? I mentioned
that having to use existing techniques in rather creative ways in order to
force your API to be somewhat more usable is far inferior and far more
complicated compared to using existing + new techniques in their standard,
designed for, fashion, in order to get an API which is even more usable, and
where your API users don't have to first figure out what kind of creative
insanity you've uncovered. So far you've done nothing to counter this
particular argument aside from repeating your previous argument but this
time with frivolous analogy attached.

Unless you want to argue that there are actual alternatives to offering a
SAM type or closure in API design, I suggest we drop this notion that adding
closures is somehow going to complicate API design. It's codifying a
practice we already have. Like Runnable.run, and ActionListener.onAction.
We're not inventing rocket science here.

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

> On Mon, Nov 23, 2009 at 12:44 PM, Reinier Zwitserloot <
> reinier at zwitserloot.com> wrote:
>
>> I'll readily admit that any change that is bound to give you more options
>> in API design is likely to tickle (in a bad way) the sense of perfection of
>> any API designer, in that they'll want to revisit their existing stuff. But
>> that's an entirely different beast from complicating or simplifying the work
>> of someone building new API -from scratch-.
>
>
> The benefits of having more options are obvious. The problem with having
> more options is that the would-be designer of a new, from-scratch API now
> has to evaluate more alternatives during the design process: Do I use
> function types here? Do I use interfaces? Should I do it all with abstract
> classes? Serious evaluation of an approach probably involves sketching it
> out, presenting it to a few people and getting feedback, or at least having
> extended conversations about it. A designer who says, "Clearly using
> whizbang feature X here is far superior to any other approach, so I won't
> waste my time considering anything else," is not thinking about the users
> and might as well be saying, "Users? I understand users so well that I don't
> have to talk to them."
>
> 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).
>
> 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. :-))
>
> --tim
>