Front page | perl.perl5.porters |
Postings from November 2010
Nicholas Clark <nick@ccl4.org> writes: > On Thu, Nov 25, 2010 at 04:38:09PM +0100, Steffen Schwigon wrote: >> Nicholas Clark <nick@ccl4.org> writes: >> > Why did you upgrade your systems to 5.12? >> >> Generally to use new features in my own software. >> >> In this case I only need 5.10. But I always upgrade to latest stable >> as soon as possible (eg., when setting up a new machine) because then >> the upgrade carnage is smaller than after skipping more versions and >> the know-how and support on the net is more fresh. In my experience. > > So you're using the same perl binary for your own software (that you control, > understand, and are in a position to audit), and a large amount of software > which you aren't in a practical position to audit? > > 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. 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. And that cost has to be weighted against the costs for e: supporting the non-backwards-compat. 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. This happens all the time. I regularly hear this from python world and I could watch it for Perl 5.10 on catalyzers like mod_perl and big applications like Bricolage. Similar on 5.12 for SpamAssassin. All in all, it's the *backwards* compat that enables the *forward* direction. Which is why new features are invented at all (for cost a). 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? 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”. Kind regards, Steffen -- Steffen Schwigon <ss5@renormalist.net> Dresden Perl Mongers <http://dresden-pm.org/>Thread Previous | Thread Next