develooper Front page | perl.perl5.porters | Postings from June 2013

Re: What does "deprecated" mean? (was: [perl #118511] Use of bare <<to mean <<"" is deprecated - make a hard error)

Thread Previous | Thread Next
Nicholas Clark
June 27, 2013 09:56
Re: What does "deprecated" mean? (was: [perl #118511] Use of bare <<to mean <<"" is deprecated - make a hard error)
Message ID:
On Thu, Jun 27, 2013 at 06:54:57PM +1000, Peter Rabbitson wrote:
> On Thu, Jun 27, 2013 at 09:34:01AM +0100, Nicholas Clark wrote:

> > I see your point, but I think that you are contradicting yourself here.
> > Given that you already described the warnings as meaning "do not complain
> > when it is gone", then others should not be complaining if the deprecated
> > feature is pulled promptly.
> I dropped some context that was present in my original mail [1]. In it I 
> said:
> > IFF a feature was deprecated because if was broken OR because it needed
> > to free up syntax for something infinitely more consistent and/or useful -
> > then removal after an announced deprecation is fair game.
> To summarize/clarify my position: An end-user has no right to complain 
> that a deprecated feature got in the way of something and was removed. 
> An end user could very well complain that a feature was gone without a 
> technical reason (see below).


> > Also, given that there is no reliable timeframe on deprecation eliminations,
> > it's not actually possible for anyone to perform a cost-benefit analysis
> > of whether to deal with it now or "at the time of removal", because without
> > a timeframe for the latter, it's impossible to calculate the correct
> > discount for future work.
> You know very well that this is not how the real world of PHBs work. The 
> usual cost-benefit analysis is framed roughly as "Alrighty, out of this 
> pile of technical debt, what do we have to do NOW and what can we do NOT 
> NOW"

Agree with how reality inevitably pans out. But I wouldn't call that a cost
benefit analysis. That's more triaging, or at least two thirds of triaging -
"what will die unless we intervene immediately" vs "what will still be
living if not treated right now".

I don't think that the timescale matters, other than "right now" versus
"sufficiently far in the future that it's not in this budget"

> 1) seems to be the case for the feature in question - namely <<''. It 
> has already been deprecated as such. And its users (in this case FC) 
> conceeded that if a saner use comes along he will let it go. With all 
> that - what is the benefit of breaking his actual existing code now, 
> instead of when the use case for <<'' becomes clear?

> This would be a reasonable timeline, except I still fail to see the urge 
> to break something without a clear technical need.

Yes, it is bugging me that removing things *feels* more like dogma than
pragmatism. But this case, it's arguably also a language design issue, and a
maintenance issue. Bother of which is harder to quantify. ie

a) it's *marginally* harder to teach people a language with yet another
   special-case feature. (Or expect them to maintain code with it)
b) it's *marginally* harder to maintain the code codebase because the code
   to deal with the feature exists

The case of (IIRC) do subroutine syntax springs to mind. IIRC chromatic
calculated that 2% (or was it 4%) of the Perl grammar exists just to deal
with it. From a language-user point of view it's not getting in the way -
if you don't use it, it doesn't hurt you. But it's potentially one of the
"thousand cuts".

So no individual change is worth it. On its own. But the sum of quite a
few of them start to take things in the right direction. So I don't think
it's purely dogma to be removing things before they are *actively* in the
way. So there's a cost to any approach.

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About