closures after all?

[Tim Peierls]

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