closures after all?
reinier at zwitserloot.com
Mon Nov 23 09:44:56 PST 2009
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-.
Unless we want to replay that old bitty of 'java is like cobol' (which
annoys me to no end. I was rather glad to hear Mark Reinhold publically
slaughter that silly notion at devoxx), a certain amount of pain today is
worth it for a better tomorrow.
However, some concern for how feasible it would be for the main IDEs to come
up with fancy refactor scripts to make your job easier, that would be nice.
Generics was rather hard to refactor. I'm guessing this may be a bit easier.
On Mon, Nov 23, 2009 at 4:43 PM, Tim Peierls <tim at peierls.net> wrote:
> 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".
> 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