On 13/03/14 16:57, Andrei Alexandrescu wrote:
At a level it's clear it's not a matter of right or wrong but instead a judgment
call, right? Successful languages go with either default.
Sorry for the delay in responding here.
Yes, it is a judgement call, and what's more, I think that probably just about
all of us here recognize that you and Walter need to make such judgement calls
sometimes, to mediate between the different requirements of different users. In
this case, what really bothers me is less that I disagree with the judgement
call (that happens), more that it was a decision reached without any kind of
community engagement before finalizing it.
This isn't meant as some kind of misguided call for democracy or voting or
"respecting the community's wishes" -- the point is simply that every decision
made without prior discussion and debate carries a social cost in terms of
people's ability to make reliable plans for future development.
This is particularly true when the decision (like this) is to reverse what most
people seem to have understood was an accepted and agreed-on development goal.
The breakage was given as an example. We would have decided the same without
that happening.
Understood. I hope it's clear why this was not apparent from the original
announcement.
More than sure a well-executed deprecation process helps although it's not
perfect. We're not encumbered by exhausting confidentiality requirements etc.
Thanks for clarifying that. I'm sorry if my question about this seemed
excessively paranoid, but it really wasn't clear from the original announcement
how much of the motivation for the decision arose out of client pressure. I
felt it was better to ask rather than to be uncertain.
Regarding deprecation processes: I do take your point that no matter how well
planned, and no matter how obvious the deprecation path may seem, any managed
change has the potential to cause unexpected breakage _simply because things are
being changed_.
On the other hand, one thing that's apparent is that while substantial parts of
the language are now stable and settled, there _are_ still going to have to be
breaking changes in future -- both to fix outright bugs, and in areas where
judgement calls over the value of the change go the other way. So, I think
there needs to be some better communication of the principles by which that
threshold is determined. (Obviously people will still argue over whether that
threshold has been reached or not, but if the general framework for deciding yes
or no is well understood then it should defuse 90% of the arguments.)
There's some underlying assumption here that if we "really" understood the
arguments we'd be convinced. Speaking for myself, I can say I understand the
arguments very well. I don't know how to acknowledge them better than I've
already done.
Actually, rather the opposite -- I know you understand the arguments very well,
and therefore I have much higher expectations in terms of how detailed an
explanation I think you should be prepared to offer to justify your decisions ;-)
In this case part of the problem is that we got the decision first and then the
more detailed responses have come in the ensuing discussion. In that context I
think it's pretty important to respond to questions about this or that bit of
evidence by seeing them as attempts to understand your train of thought, rather
than seeing them as assumptions that you don't understand something.
That said, I think it's worth noting that in this discussion we have had
multiple examples of genuinely different understandings -- not just different
priorities -- about how certain language features may be used or how it's
desirable to use them. So it's natural that people question whether all the
relevant evidence was really considered.
Thanks for being candid about this. I have difficulty, however, picturing how to
do a decision point better. At some point a decision will be made. It's a
judgment call, that in some reasonable people's opinion, is wrong, and in some
other reasonable people's opinion, is right. For such, we're well past
arguments' time - no amount of arguing would convince. I don't see how to give
better warning about essentially a Boolean decision point that precludes
pursuing the converse design path.
I think that it's a mistake to see discussion as only being about pitching
arguments or changing people's minds -- discussion is also necessary and useful
to set the stage for a decision, to build understanding about why a decision is
necessary and what are the factors that are informing it.
One of the problems with this particular issue is that probably as far as most
people are concerned, a discussion was had, people pitched arguments one way and
the other, some positions became entrenched, other people changed their minds,
and finally, a decision was made -- by you and Walter -- in favour of final by
default. And even though some people disagreed with that, everyone could see
the process by which that decision was reached, and everyone felt that their
opinions had been taken into account. And that was that -- a decision.
So, now, you and Walter have changed your minds -- which is fine in and of
itself. The question is, is it right for you to simply overturn the old
decision, or is it more appropriate for you to take the time to build a new
consensus around the facts that have changed since the last one?
My own take on that is that the maintainer's trump card is an essential but
precious resource, and that generally speaking its use should be reserved for
those situations where there is an absolutely intractable dispute between
different points of view that cannot be resolved other than by the maintainer's
decision. And I don't think that this is such a situation.
Anyway, for what it's worth, here's how I think I would have gone about this
(bearing in mind that hindsight is 20/20:-). I would not have jumped straight
to the final-by-default decision, but would have laid out the problem that needs
solving -- that we need to raise the bar much higher in terms of avoiding
unexpected breaking change -- and then I'd have raised the related issue:
"However, we also need to take a long hard look at the _planned_ breaking
changes we have in mind, and give serious consideration to which of them are
really necessary, and which are merely desirable." And I'd have asked for
opinions, thoughts and so forth on this.
And _that_ would have been the context in which it'd have been the right moment
to raise the issue of final-by-default, and probably to justify its exclusion on
the grounds that while it is very desirable, it is not actually fixing an
unworkable situation -- merely a problematic one.
I think that while in that context there would certainly still have been many
concerned responses questioning the decision, but there wouldn't have been the
feeling that it was a decision being imposed out of the blue for unclear reasons.
