closures after all?

[Tim Peierls]

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