develooper Front page | perl.perl5.porters | Postings from March 2007

Over conservative approach towards backwards compatibility is just wrong

Thread Previous | Thread Next
From:
demerphq
Date:
March 1, 2007 04:22
Subject:
Over conservative approach towards backwards compatibility is just wrong
Message ID:
9b18b3110703010421n5754ba89i9680edebd70c915a@mail.gmail.com
In the recent thread on use feature Mark Jason Dominus made a comment
that I think is worth analysing in more detail, and frankly deserves a
bit of a rant. Its not really aimed at him as the view he espouses is
not uncommon in the p5p development world. The analysis is first, and
the rant follows, seperated by a divider line.

On 3/1/07, Mark Jason Dominus <mjd@plover.com> wrote:
>
> > It would be nice if 'use feature;' (without an argument list) includes all
> > features, just as 'use warnings;' turns on all warnings. But this might
> > have already been proposed and dismissed.
>
> It's a bad idea, because any program with that declaration will break
> the next time an incompatible feature is added.
>
> Consider "use 'strict'".  People are allowed to put just "use
> 'strict'" in their programs, without saying which strictures they
> actually want, and the outcome is that we can't add any new
> strictures, because doing so would break every program in the world
> that starts with "use 'strict'".

I think this argument is flawed. Use strict is supposed to catch
constructs that are most likely errors. If we introduce a new
stricture presumably we will only do so because we have identified
something that is likely to be used incorrectly and therefore result
in buggy code. Once we introduce it the only code that will break is
the code that does the thing that is likely to be incorrect. And since
it is likely to be incorrect the odds are that the new stricture will
bring potentially buggy code to the attention of the author.

I can't see how this is a bad thing, nor how it would result in
breaking every program that uses strict, and in fact id go so far as
to say that the programmer has already explicitly asked us to do this
type of checking by using strict in the first place.

Consider a variant of this issue, if strictures had a bug in it such
that something that it catches, lets say symbolic references, wasn't
being caught in a particular situation. If we applied the argument
outlined above we wouldnt be able to fix this problem because it could
break code.

---begin-rant---

Looking at it in a general sense, if you want to 100% backwards
compatibility, then DONT UPGRADE. By changing major versions
*something* will change, and it could affect your code. But its not
going to magically happen underneath them. We can't handcuff sensible
behaviour for evermore simply because those that came before us didnt
have the foresight to predict everything under the sun.

Perl takes a *very* conservative approach towards stuff like that,
which is good, but taking it so far that nothing can be changed or
improved or extended or fixed is ridiculous.

I think its generally understood that people dont upgrade their perls
anywhere near as often as we on p5p might wish. So its even less of an
issue. Bad code is most likely going to stay running on the perl it
was written for.

use feature is a bit of a tricky case as it includes something that we
KNOW will break a lot of code in the interest of /forward/
compatibility (with the soon to be release Perl 6), and some things
that will break various email signature oneliners and obfus. The rest
probably wont break much. And if it does well, the people upgrading
should catch it in /their/ regression suites before they put the new
version into production.

I think the real issue here is that we have almost obsessive desire to
avoid backwards compatibility issues. A desire that i dont think is
healthy, and one that is probably not justified. Its one thing to
break old behaviour by accident, its another to do it with conscious
decision and document it and warn about it to upgraders.  This is not
to say that we should break things willy nilly, we shouldnt, taking a
conservative approach is good, but we shouldnt assume that avoiding
breakage in a small number of modules is the primary concern. That way
lays stagnation.

An email sig from Jarkko says it all I think:

        # There is this special biologist word we use for 'stable'.
        # It is 'dead'. -- Jack Cohen

Cheers,
Yves


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About