Front page | perl.perl5.porters |
Postings from June 2013
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? :) CheersThread Previous | Thread Next