Front page | perl.perl5.porters |
Postings from November 2010
Re: [PATCH] deprecate ?PATTERN?
Thread Previous
|
Thread Next
From:
Nicholas Clark
Date:
November 28, 2010 12:16
Subject:
Re: [PATCH] deprecate ?PATTERN?
Message ID:
20101128201554.GU24189@plum.flirble.org
On Sat, Nov 27, 2010 at 10:55:51PM +0100, Steffen Schwigon 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
It's not. There's a lot of smaller things that anyone competant to write a
CPAN module can do. Heck, even "making a development release of Perl" is on
*that* list. However, most people don't want to, because it's not as fun as
writing new code.
> nobody in p5p in turn does want to physically get paid, how the ???Gabor
> Thread??? showed.
That isn't actually true given that there are (at least) 2 full time employees
of ActiveState on this list, Dave is working about half-time on the core, and
Zefram has put in a grant proposal to do similar to Dave.
I think that it's also not relevant, as I specifically said that you seem to
be asking for
a: can have new features
b: never have old misfeatures removed
c: at no cost
ie a AND b AND c.
You're not asking for "a and b, but paid for".
You're asking that volunteers provide new features, but never remove *anything*.
Which I don't think is actually practical on a volunteer basis.
In theory, it could be done on a commercial basis, but I don't see ActiveState
rushing to offer commercial support contracts for 5.6 (or earlier) "at any
price", which makes me think that there's little commercial demand for it
either. (At least, not at commercially realistic prices)
I don't actually think it achieves much even working on the assumption that
"never remove anything" means that upgrades will be completely safe. It may
well *reduce* the pain, but it can never eliminate it. For example, 5.10
added caching for @ISA. In a perfect world, this would not have affected any
existing code (except that it might be faster). In practice, there were bugs.
So *adding features* is a risk, even in the short term.
Moreover, not removing anything is a bigger risk in the long term. It's
already hard enough to grasp the interactions of the internals. Wanting to
forbit the removal of any current behaviour, however obscure it is, and
however much pain it causes internally, would mean that the maintenance
burden would, over the longer term, increase much more rapidly.
So perl 5.last.0 would come rather sooner that way.
As a specific example, you're requesting "no deprecations ever". Which means
that you are opposed to the deprecation of
my $pi := 4;
being parsed as a legal way to write C<my $pi : = 4;>, ie an empty attribute
list. The current behaviour isn't used by any actual code on CPAN. Anywhere.
So taking that as a large representative sample of (crazy) Perl code, it's
unlikely to be used anywhere else. Yet forbidding deprecating the current
parsing means that we can't in future use := as a binding operator.
Preventing the removal of even the tiniest misfeature prevents big
improvements for all.
Now, your position would be more consistent if you were arguing for just
"b AND c", but you're not. You also want "a", new features. You don't just
want 2 hard things, you want 3.
> 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 agree.
But I think that it's still unreasonable and unrealistic to ask for "no
deprecations ever" whilst also expecting everything else.
Nicholas Clark
Thread Previous
|
Thread Next