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