closures after all?

[Tim Peierls]

On Sat, Nov 21, 2009 at 6:46 PM, Reinier Zwitserloot <
reinier at zwitserloot.com> wrote:

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


That's because for a very smart person like you the complexity is linear in
the number of features. You probably didn't endure months of frustration
converting your code to use generics -- all along thinking, "I know this is
good for me. Look at all that lovely additional type-checking. Now why won't
this compile?" You probably didn't race to replace all your uses of
synchronized with Lock/Condition even when it was completely unnecessary.

Well, I did those things -- the latter especially embarrassing given my
presence on the JSR 166 EG -- and much more! If you say, "Well, Tim, in that
case you probably shouldn't be coding in Java," I'll say, "Maybe not, but
there are many, many Java developers like me in that respect."

For people like me any new feature, no matter how compelling and desirable
in theory, affects the usability of the language in dramatically non-linear
ways. An API designer has to take such people into account.

I'm not saying a complex new feature is never worth it, only that it
definitely does make API design harder because of the need to balance the
virtues of using the feature in the API against its effect on the "masses".

--tim


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