develooper Front page | perl.perl5.porters | Postings from May 2010

Compatibility is a virtue

Thread Next
Jesse Vincent
May 5, 2010 08:14
Compatibility is a virtue
Message ID:
Our community has a long-held belief that backward-compatibility is a
virtue, even when the functionality in question is a design flaw.

We would all love to unmake some mistakes we've made over the past
decades.  Living with every design error we've ever made can lead
to painful stagnation.  Unwinding our mistakes is very, very
difficult.  Doing so without actively harming our users is 
nearly impossible.

Lately, ignoring or actively opposing compatibility with earlier versions
of Perl has come into vogue.  Sometimes, a change is proposed which
wants to usurp syntax which previously had another meaning.  Sometimes,
a change wants to improve previously-crazy semantics.

Down this road lies madness.

Requiring end-user programmers to change just a few language constructs,
even language constructs which no well-educated developer would ever
intentionally use is tantamount to saying "you should not upgrade to
a new release of Perl unless you have 100% test coverage and can do a
full manual audit of your codebase."  If we were to have tools capable of
reliably upgrading Perl source code from one version of Perl to another,
this concern could be significantly mitigated.

Like all perl5-porters, I would like to see Perl continue to grow and
flourish in the coming years and decades, but not at the expense of our
user community.

Existing syntax and semantics should only be marked for destruction in
very limited circumstances.  If a given language feature's continued
inclusion in the language will cause significant harm to the language
or prevent us from making needed changes to the runtime, then it may
be considered for deprecation.

Any language change which breaks backward-compatibility should be able to
be enabled or disabled lexically.  Unless code at a given scope declares
that it wants the new behavior, that new behavior should be disabled.
Which backward-incompatible changes are controlled implicitly by a
'use v5.x.y' is a decision which should be made by the pumpking in
consultation with the community.

When a backward-incompatible change can't be toggled lexically, the decision
to change the language must be considered very, very carefully.  If it's 
possible to move the old syntax or semantics out of the core language 
and into XS-land, that XS module should be enabled by default unless 
the user declares that they want a newer revision of Perl.

Historically, we've held ourselves to a far higher standard than
backward-compatibility -- bugward-compatibility.  Any accident of 
implementation or unintentional side-effect of running some bit of code 
has been considered to be a feature of the language to be defended with
the same zeal as any other feature or functionality.  No matter how 
frustrating these unintentional features may be to us as we continue
to improve Perl, these unintentional features often deserve our 
protection.  It is very important that existing software written in 
Perl continue to work correctly.  If end-user developers have adopted a 
bug as a feature, we need to treat it as such.

New syntax and semantics which don't break existing language constructs
and syntax have a much lower bar.  They merely need to prove themselves
to be useful, elegant, well designed and well tested.

Hello, I am the backward-compatibility police and I am watching you.

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About