closures after all?
reinier at zwitserloot.com
Sat Nov 21 15:46:00 PST 2009
Maybe. Knowing how to use 86 features normally is probably easier than
knowing how to use 85 features very creatively, so, I still don't really
agree with your reasoning.
On Sat, Nov 21, 2009 at 10:52 PM, Tim Peierls <tim at peierls.net> wrote:
> On Sat, Nov 21, 2009 at 11:44 AM, Reinier Zwitserloot <
> reinier at zwitserloot.com> wrote:
>> On Sat, Nov 21, 2009 at 6:24 AM, Tim Peierls <tim at peierls.net> wrote:
>> [in response to Neal's argument that writing libraries is hard already]
>>> The addition of function types would raise the threshold of expertise
>>> required to do a good job, making that small percentage even smaller.
>> I'm not sure that argument actually works in practice. One of the skills
>> needed when writing libraries is making sure that the library tries to make
>> the job that HAS to be done by the user of the library as easy as possible.
>> Sometimes this requires some _very_ creative design, such as coming up with
>> something like the builder pattern. Having the ability to use function types
>> may actually alleviate the need to come up with, say, the 80 hook interfaces
>> that ParallelArrays defines, making the job easier instead of harder.
> Adding a language feature *does* open the door to new possibilities, but
> the designer's job *is* harder because now you have to evaluate the benefits
> and costs of using existing features in creative ways vs. taking advantage
> of these new possibilities. It's not enough to observe that an approach
> based on new features is more appealing to expert users (more elegant, say,
> or more compact) than one that is not -- a feature wouldn't get far if it
> didn't appeal to experts. But the API designer has to be sensitive to the
> consequences of using new language features for all users, not just the
> experts. The pool of good designers possessing that kind of sensitivity is
> necessarily smaller than the one that doesn't have to worry about new
> language features; the latter have less to do.
> How do you know if you belong to that smaller pool? I don't know (and I
> don't claim membership), but I bet self-nomination is not a guarantee. ;-)
> And again, I think too many folks are taking it on faith that ParallelArray
> with function types would be vastly superior to ParallelArray with named
> interfaces. I'm not at all convinced -- in fact, my limited experience
> suggests otherwise. A year (two years?) ago, I had what I (naturally)
> thought was an efficient and externally attractive way to drastically reduce
> the number of named interfaces needed for ParallelArray. Doug Lea didn't
> like it, but it's possible I didn't describe it well to him. :-) Maybe I can
> dust it off and try again.
More information about the coin-dev