closures after all?

[Tim Peierls]

I think the one of the existing rules is not to be nasty.

Care to rephrase?

--tim

On Mon, Nov 23, 2009 at 5:51 PM, Reinier Zwitserloot <
reinier at zwitserloot.com> wrote:

> 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
>>
>
>