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
Peter Rabbitson
June 27, 2013 10:22
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 10:56:13AM +0100, Nicholas Clark wrote:
> On Thu, Jun 27, 2013 at 06:54:57PM +1000, Peter Rabbitson wrote:
> > 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"

This is precisely what I was trying to convey.

> > 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.

I thought this has already been addressed... While teaching it is 
perfectly acceptable to gloss over anything deprecated. It is even 
acceptable to gloss over *discouraged* practices (e.g. 2 arg open, 
indirect invocation, etc)

> (Or expect them to maintain code with it)

I don't think this applies... a quirk of a project is a quirk of a 
project. I could take your statement and apply it to any codebase that 
uses Devel::Declare, or Perl5i or somesuch - it is reasonable to expect 
an employee to get familiar with the local dialect of perl used... Or am 
I missing something?

> 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".

Being 2 (or 4%) of the grammar, and being a special case of invocation 
(thus likely having an effect on entersub or somesuch) - in any case - 
there is *tangible* technical benefit of removing this. I do not believe 
it would be reasonable to complain if this were removed during a 
*related* encounter with this part of the parser/lexer/whathaveyou.

> 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.

I actually agree with this in principle. It is the context of such 
changes that bothers me.

I am specifically decrying "cleanup for the sake of cleanup" - when 
someone takes time specifically to remove deprecated features for reason 
no other than to "stick to the schedule". Yes, an argument can be made 
that removing extra code now, will make it easier for the next 
maintainer to work on this area. On the other hand one can make the 
argument that cleanup with no plan prevents the currently-assigned-janitor
from seeing the big picture, thus preempting a much larger-scope cleanup 
that would result if a particular new feature was held in mind.

In other words - all I wanted to do is raise an objection against the 
perceived benefit of "cleanup for the sake of cleanup". I think both 
sides have at this point exhausted and argumented their positions well 
enough, thus it is "pmpking time".

What do you think? :)


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