The Right Approach to Deprecation

Is it possible to think too highly of Moose? Most of what I want in a deprecation policy is in Moose's deprecation policy. Loosely rephrased (so believe the official published Moose policy, not my interpretation of its words):

  • It's better to do things right than to do things the way everyone's always done them previously.
  • Undocumented behaviors are unsupported behaviors. They can and will break.

Consider technologies which lack defined upgrade, version, and obsolescence paths: Microsoft Windows, SMTP, PHP, the JVM.

Consider technologies which have defined upgrade, version, and obsolescence paths: Perl 6, Moose, the Linux kernel.

Which would you rather use? Java the language has the patina of type safe collections, but Java bytecode (apparently) can't change to support real type safety. PHP has never met a half-baked feature-adding patch it doesn't like, even if that patch gets in the way of something better a few years in the future. (I half expect PHP 6 to restart development by adding drive letters as namespace anchors, say C:\This\is\my\PHP\Namespace.) Various Windows kernels have included workarounds for bugs in specific DOS programs and 16-bit Windows programs.

I suppose if you see programming as an occasional exercise where you blurt out a few pages of code and spend the rest of your life hoping never to touch that machine again, there's value in nothing ever changing (though here's the source code to old versions; go crazy).

Meanwhile, if the price I pay for using Moose or Perl 6 or whatever is that I need an explicit declaration of the version I intend to use and I need to pay attention to upgrades but in return my code gets a little faster, a little cleaner, and a little more correct, that seems like a bargain. After all, I use these tools because they make me more productive. Why would I limit myself with the baggage of having to support accidental, undocumented features used by code I can't even prove exists?

(The Parrot world once had a brief debate over whether our deprecation policy covered the names and orders of struct members in Parrot's C data structures. Imagine wanting to clarify the name of a variable and having to wait three months even if accessing that code from outside of libparrot represented an egregious violation of encapsulation so much that you'd have to copy and paste literal source code between files. The flip side of the "Sane deprecation is good" argument is "Design and document an effective API". Then again, you have to be able to recognize insane APIs, which is not an easy task when you have Stockholm Syndrome from suffering under the reign of actively hostile interfaces.)

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

sponsored by the How to Make a Smoothie guide



About this Entry

This page contains a single entry by chromatic published on September 29, 2010 10:03 AM.

On Optimization was the previous entry in this blog.

Modern Perl: The Book: The (draft) PDF is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Powered by the Perl programming language

what is programming?