Front page | perl.perl5.porters |
Postings from July 2016
Re: Indented here docs?
July 17, 2016 19:57
Re: Indented here docs?
Message ID: CANgJU+UTNvHFvKU2=62LH9EP6nSLQTZH8Pk+3inj+gBJvVrSBg@mail.gmail.com
On 17 Jul 2016 14:14, "Sawyer X" <email@example.com> wrote:
> I wrote a much longer email at first, but I've resolved to make a
> (hopefully) clearer and more succinct response.
> On 07/17/2016 02:28 PM, Aristotle Pagaltzis wrote:
> > * Sawyer X <firstname.lastname@example.org> [2016-07-16 19:00]:
> >> Bare << was deprecated for 20 years now. It has now been a principal
> >> part of a discussion on a new feature and stood in the way. The fact
> >> that we ended up picking different syntax which does not mix with bare
> >> << does not mean it was not in the way.
> > Yes, “was” – past tense.
> > So, we drove down some old back road hardly anybody goes through, that
> > we do not plan to be on again. And we encountered a ditch cutting across
> > the road. The ditch sometimes carries water, very rarely. So we stopped
> > and considered the options: fill it up to drive over it, or just drive
> > off the road a little to go around it… or do both: fill it up first,
> > then go off the road a little to drive around it.
> > Well yes, the ditch was in the way before we filled it up, and having
> > filled it up does not change that. But saying we will fill it up even
> > though we drove around it still seems unreasonable to me. It did carry
> > water occasionally. If we expected more language design traffic in this
> > area, sure, but what is the benefit in this case?
> I started listing why this comparison is wrong (cost of operation vs.
> patch, low cost of ditch filling when building bigger projects, etc.)
> but I'll simply comment to this with: I reject this comparison.
> This situation is not so complicated that we cannot express with it in
> few words. (I also consider this is my response to the rest of this
> * We have syntax which is deprecated for a very long time.
This is the core problem at hand.
Our historic approach to deprecation has been inconsistent with the not
unpredictable outcome that deprecation has become meaningless.
The answer to the question 'what is the benefit of removing it' is quite
simply that deprecation starts being meaningful again.
Every time we break down when someone starts moaning about us removing a
deprecated feature we undermine the point of having a deprecation cycle at
all and reinforce the belief that we don't mean it and won't follow through
While I am quite sure those arguing about this particular feature don't
explicitly mean to they are, as far as I can tell, implicitly arguing that
we shouldn't have a deprecation process at all.
I believe it is far better that people believe that when a feature is
deprecated that there is no room for further debate and that the feature
will be removed as and when tuits are found to do so.
Consider a different thought experiment from Aristotles, if a person
routinely drives over the speed limit down a road and only receives
warnings from the police when caught would anyone be sympathetic when they
complained about getting a ticket? I think not.
For me this is the same as continuing to use a deprecated feature for years
after it was deprecated. It is simply irresponsible and we should not be
sympathetic to claims that removing it would break something.
> * It interfered in a proposal for a new feature we would like to have.
> * Our policy *clearly* states that we might remove deprecated features.
> * That's... pretty much it.
> You think it should not be removed while some do.
Some people care that the rules are enforced so as to avoid undermining the
very idea of having rules.
> My personal position on this, which should be discussed in a separate
> thread on whether to remove it or not, is to remove it. We can do this
> with a deprecation cycle as well.
No. We should remove it and use it as an object lesson that ignoring
deprecation warnings is unwise.