Front page | perl.perl5.porters |
Postings from November 2010
On Fri, Nov 26, 2010 at 12:06:39PM +0100, Steffen Schwigon wrote: > Nicholas Clark <nick@ccl4.org> writes: > > Because effectively you're requesting that you > > > > a: can have new features > > b: never have old misfeatures removed > > c: at no cost > > > > which means that you've externalised the actual costs of providing all 3. > > > > Which isn't a request that can be satisfied. You're not going to get all 3. > > I agree that I cannot expect getting anything for free. And I don't > really do. But to continue that cost thinking I even think that I > argue to keep costs for all parties low, because > > d: ???removing old misfeatures??? > > is also a cost. Sure, but a cost to whom? > And I think a) does not neccessarily has a dependency to b) or d). > It's that dependency that costs. And the deprecation creates the > dependency and its costs. It does given 'c'. > And that cost has to be weighted against the costs for > > e: supporting the non-backwards-compat. Again, a cost to whom? > As soon as a language does not support older versions big projects > will have to decide about costs of upgrading or sticking with the old > version. For big projects the cost is also high to fix deprecations, > so they stick to old language first. On big projects with big momentum > this means every minute the costs grow to solve the gap to new > version. The big project is doomed to old version until that version > goes out of support. The source code to perl is available. There is no reason why the projects (or firms) can't support the older version they need. Patch build fixes only. 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") > In Perl I think the responsibility is even bigger because it already > *is* so back compat friendly. So many code out there. Just count URLs > with cgi in it. I would compare the impact of deprecations in Perl to > making C compilers deprecate a C89 detail. Do I exaggerate? Probably yes. It's comparable to deprecating a C89 library feature, which can't be detected at compile time, and forbidding the use of static linking, to prevent one from compiling a binary against the standard you desire. The difference with a dynamic language is that it's recompiled at each and every runtime, so the *entire* installed language implementation, build system and runtime, has to stay compatible. *Assuming* that the program isn't pinned to a particular version. > In Perl on the back-compat topic we mostly talk about syntax and XS > API. XS is a slightly less intrusive because I think XS modules are > more central on CPAN than pure Perl code is in its incarnations in > millions of CGI scripts. > > On syntax IMHO it will have less costs to have more dirty but > back-compat syntax than deprecating syntax. (Only exception: > protection by ???use feature???.) > > > But I'm just dumping my user opinion. > I don't really ???know it better???. Agree. Less total costs to end users. But that is achieved by pushing more cost inward, without anything to compensate for the increased burden. Nicholas ClarkThread Previous | Thread Next