Final by default?

Joseph Rushton Wakeling joseph.wakeling at webdrake.net
Sun Mar 16 11:46:20 PDT 2014


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.


More information about the Digitalmars-d mailing list