Defender methods and compatibility
Neal Gafter
neal at gafter.com
Tue Nov 30 13:09:57 PST 2010
On Tue, Nov 30, 2010 at 11:35 AM, Brian Goetz <brian.goetz at oracle.com>wrote:
> This is a trivial detail that's not worth holding back progress for
>>>
>>
>> Was somebody proposing to hold back progress?
>>
>
> The sad reality is that a fair portion of the postings to lambda-dev, no
> matter how well-intentioned, have a negative effect on progress.
If by "progress" you mean completion and delivery of language changes (no
matter how ill-advised in their design) I can easily believe that. While I
do believe that Oracle would have less schedule risk in the absence of the
discussions on this list, I also believe that these discussions have the
potential to improve the language design (in the sense of reducing risks to
future users of the language that arise out of poor choices in language
design) in a way that more than offsets (from the perspective of the users
of the language) the schedule risk. These risks - risks to the future users
of the language - might well be valued differently by members of this list
than by Oracle.
Of course these risks do need to be balanced against each other, as spending
infinite resources on design ensures that users never see any language
change. Oracle does not have a well established history of collaborative
engineering in this kind of forum, where such risks can be balanced by the
participants, but we can hope that this forum provides an opportunity for
change.
The question is whether the potential incremental benefit that comes from
> the discussion is worth the incremental cost in time and schedule risk.
> Unfortunately nearly none of the contributors in this forum have all the
> facts (e.g., schedule, budget, and other non-public constraints) with which
> to make that tradeoff.
That is why this mailing list is so valuable: it enables the participants to
share, discuss, and balance risks of all kinds, including risks to future
users of the language that Oracle might not fully appreciate (or care about
as much as its users).
More information about the lambda-dev
mailing list