Front page | perl.perl5.porters |
Postings from November 2010
Re: [PATCH] deprecate ?PATTERN?
Thread Previous
|
Thread Next
From:
demerphq
Date:
November 28, 2010 01:37
Subject:
Re: [PATCH] deprecate ?PATTERN?
Message ID:
AANLkTinDsjSLJBJJEW2-3GsL-OAKX64n+gJmRJiJF+cG@mail.gmail.com
On 27 November 2010 22:55, Steffen Schwigon <ss5@renormalist.net> wrote:
> Nicholas Clark <nick@ccl4.org> writes:
>> My comments here are really about who is paying.
>>
>> I'd argue that the external projects are expecting a lot for free.
>> Sure, it lowers *their* total cost if the volunteers maintaining the
>> core language never deprecate *anything*, but they are externalising
>> costs, because they don't contribute to helping bare the cost of
>> this.
>>
>> (There is next to zero flow of volunteers from CPAN projects into
>> perl core maintenance. Because Perl 5 basically "just works")
>
> CPAN maintainers _are_ investing effort in keeping their libs along
> Perl's development, else the cpantesters matrixes would always get
> continuously more red.
>
> For participating in perl, the compiler, the barrier is huge(*). And
> nobody in p5p in turn does want to physically get paid, how the “Gabor
> Thread” showed.
>
> I feel the weariness coming out of this statement for p5p's effort,
> but the people on the software stack on top of the compiler are also
> hard-working and on their limits. Both are part of the same ecosystem
> which only as a whole makes Perl.
I think you missed the point.
The point is that the perl5porters community doesnt get a lot
volunteers coming from the CPAN community.
This was stated in the context that some, if not many, acitve
participants on this list feel that often we are faced with the
prospect of deprecating and removing a problematic feature in perl,
and providing an easier to maintain, teach, and likely easier to prove
correct behavior.as a replacement, or we can change more or less
nothing except fix bugs, with the result that nothing gets changed,
but likely nothing gets better either.
Since maintaining a lot of cruftier language features is complex, time
consuming and raises the barrier to entry in terms of attracting new
talent to the porter community the perception is that there is a
small, generally invisible, but very vocal when angered subcommunity
who will oppose virtually any change to perl that might force them to
review and possibly change their code prior to upgrade. Essentially
they expect to be able to use the fruit of our labours, out of the
box, but without expending any effort of their own, and actually
probably damage the process and the community which might produce new
releases - it is *VERY* VERY frustrating to have ones hard work
rejected by a chorus of screaming parasites who never contribute and
whose most intelligent comment on the list is along the lines of "then
youll break some code i wrote for perl5.6 ten years ago".
Now, on one hand, I think its fair to say that most if not all of the
porters would prefer to break as little existing code as possible when
we change things. We agonize over it. We sweat it. We debate it. We
search various code repositories to try to quantify the possible
fallout. We do our best to provide workarounds, mitigations and
replacements.
But the fact remains that despite this there will still be a nasty
vocal minority freaking out about anything we do that will impact
their ability to use *for free* the work that *we did* if that means
*they* have to expend some effort.
Now, at a certain point you have to ask yourself, how can this be
fair? Why should a group of programmers who refuse to review and
update their code, yet *demand* to be able to use the newest perl with
their ancient code, be able to have such a drammatic, and negative
veto over any form of progress or movement in our community? Why
should those who contribute the least, and who benefit the most, be
given the greatest voice in what we do?
Why should people that do not want to review their code, or take any
risk of their own, be entitled to *demand* that the work *we* do suits
them *precisely* without *any* effort on their behalf?
I think the general consensus on this list by active and semi-active
porters is that we should NOT CARE what these people think. If they do
not want to break their code by upgrading then THEY SHOULD NOT
UPGRADE. If that means they have to figure out how to build an old
Perl using a new tool chain, then THAT IS THEIR PROBLEM. We have other
problems to worry about on this list, and since these people do not
contribute to solving OUR problems, (and arguable make our problems
more difficult) then why should we care about THEIR problems with
upgrading?
This is what Nicholas meant by externalising costs. Organizations that
expect to be able to upgrade perl, without backwards compatibility
issues at all, are essentially expecting the Perl community to support
their organizations in a financial way without any return on our
investment. Its like they come to the list and say "hey i expect all
of you *volunteers* to pay our company N hours of dev a week, because
we decided to use your software - great job guys, please send the
check".
Now, if they actually did it like that then there would be no debate
about the inappropriateness of their demands. It is only because it is
couched in terms like "deprecation" and "backwards-compatibility" that
there is any debate at all.
One thing I know, is that responsible companies that are making money
out of perl are a) paying the cost to upgrade because they know its
worth it, and b) contributing financially to the ongoing development
of perl.
I think the community will contibue to be particularly sensitive to
back-compat issues, it is in in our blood and heritage. Yet at the
same time, the only truely stable language is a dead one. And we arent
in the programming-language mortuary business here on this list.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next