The "What Does Deprecation Actually Mean" Meta-Argument

Rafael believes that deprecation does not imply removal; he takes issue with my argument that removing deprecated features is a healthy act of maintenance.

That's fine; let me expand my argument further.

The "Words Mean Things" Argument

One reason why deprecation should imply removal is that the act of deprecating a feature is a formal expression of disapproval. For example, deprecating the Switch module reflects a strong community belief that you cannot use that module reliably.

There are other reasons to discourage the use of a feature: the existence of a better approach (certainly true in the case of Switch), the difficulty of maintenance, performance penalties (in the case of $&), the possibility of confusion (sigilless aggregate variables), and more.

If you've browsed perldiag, you'll see that some features marked as "deprecated" also contain the text "will be removed in a future version."

The Ease of Maintenance Argument

Assume that the Perl 4 package separator were a deprecated feature. Assume that you want to add a new feature to Perl 5 which deals with package names. (I've done this.)

Every place in the tokenizer -- look for yourself, it's toke.c -- which deals with what may be a package name must explicitly look ahead at each character position for either a single tick or double colons. I can think of five or six places where this is the case. (There may be more. It's not always easy to count by skimming the code; a single tick is a valid character with special tokenizing semantics in at least two other contexts in the tokenizer.)

If you want to add a new mechanism to deal with package names, you must be aware of this separator. If you want to refactor the code which deals with package names, you must be aware of this separator. If you want to add a test case which deals with package names, you must be aware of this separator.

In short, the maintenance burden for the tokenizer is a little bit higher due to support for a feature largely unused (I know of two cases outside of the Perl 5 test suite: isn't from Test::More and the joke D'oh module) and almost universally unknown (if you've used Perl 4, you may remember it; if you started using Perl sometime in the past fifteen years, you may have learned it the hard way).

The "You Can't Have It Both Ways" Argument

Rafael suggests the "removing features might break existing code" argument is spurious. That conveniently overlooks a nasty little conundrum in deprecating code. If you think for a moment about exactly what I quoted in my previous post, you may see it. Ready for the spoiler?

Deprecating features means adding warnings. As Abigail points out on p5p from time to time, adding warnings may break existing code.

Enter the DarkPAN Pseudo-ontological Silver Bullet argument. Imagine that some code exists outside the purview of the CPAN. Imagine that this code uses the deprecated feature.

This could go two ways.

Either the DarkPAN codebase eschews warnings, in which case its maintainers may never find out about the deprecation until the point of removal (and when yet another pumpking asserts -- even in jest -- that people who don't test their code against Perl 5 prereleases deserve any unpleasant surprises they get, it's difficult to understand why there's little sympathy for new and unknown bugs versus so much sympathy for deprecated features announced and removed after a lengthy deprecation cycle)...

... or the DarkPAN codebase uses warnings, in which case upgrading to a new version of Perl 5 which has deprecated a feature will suddenly produce warnings where it produced no warnings before.

Here's a clever rhetorical trick.

What if such a codebase used fatal warnings? The act of deprecating a feature could break code!

Because there's little visibility into the DarkPAN, it's easy to imagine that this is the case. The fatal warnings feature exists. Some code uses it. Deprecated features exist. Some code uses them. Might there be a union of those two sets?

Don't count on the "But it's not likely!" counterargument to save you. How likely is it that DarkPAN code relies on the Perl 4 package separator? On sigilless aggregates? On using reference syntax on non-reference aggregates? On split in scalar context clobbering @_?

Until the DarkPAN is observable, the best anyone can do is guess -- and that's hardly a reliable mechanism for discipline in software development. (I suspect the right approach to handling upgrades is to admit that upgrades require caution and planning and mindfulness and to stop overcomplicating them to overcompensate.)

I realize that this is a scorched earth argument against invoking the DarkPAN pro or contra any potential change. That's deliberate.

The "Gratutitous Breakage" Argument

I'm not the only one with strong rhetoric. Quoting Rafael:

Basically the only real argument against removal of features is precisely the one that chromatic persists in ignoring: preservation of backward compatibility, to avoid gratuitous breakage of Perl programs.

The emboldened emphasis is mine. If a deprecation notice has been present for multiple years in multiple stable releases (a feature deprecated in Perl 5.6.0, for example, has been deprecated for nine years and fourteen stable releases of Perl 5), this is a use of the word "gratuitous" of which I was not previously aware. I suppose you could make the word work if you argue that marking a feature as deprecated offers no justification -- none -- for its eventual removal, but that circles back to the "Words Mean Things" argument.

Note again that the fatal warnings feature condemns even marking a feature as deprecated. In a codebase with those characteristics, the deprecation is itself arbitrary in a way that the removal is not: at least the removal has had an announcement period!

The "For Whom Are You Optimizing?" Argument

Given the choice between deprecating and removing a feature which has had a wildly popular replacement for fifteen years, which exists to support (as far as anyone can tell) two public features (one a joke and the other easily rewritten), and frequently confuses novices and keeping it for the purposes of backwards compatibility, I'm unabashedly in favor of simplicity.

Every time I write an API, I try to make it impossible to abuse. That's not always possible, but I want to encourage users to do the right thing by making it so easy to do that they won't consider doing the wrong thing.

Every time I read a bug report, I (try to) rethink my API assumptions. How can I change my code to make that class of bug impossible again?

That's not always easy in language design. It's difficult. Yet it's possible.

That requires a prioritization of features and design and design decisions based on your intended users. Given that Perl 5 won't enable strictures and warnings by default for several years (if ever), how will novices learn to avoid deprecated features? (Expecting them to peruse perldiag or another FAQ for "What Not to Do?" is silly. Have you ever worked with a novice? If they knew which documentation to read and how to read it and what it all meant, they wouldn't be novices!) How will they realize that the awful Perl 4 style tutorial from which they're copying and pasting code is buggy, insecure, inefficient, unmaintainable, and a really bad example of the power and elegance modern Perl affords?

I fear that if the argument "We can't change things that may break unmeasured DarkPAN code" trumps the desire to clean up some of the rough, pointy edges of Perl 5, that Perl 5 development has prioritized keeping old (and, let's face it -- if it relies on these deprecated features, you know it's crufty) code running over attracting new developers.

Characterize that concern as "A crazy, wild-eyed, frothing-at-the-mouth desire to destroy Perl 5, salt its earth, and make everyone into Java programmers!" if you want. I suspect some people reading this already have. Yet my previous post quoted from Perl 5's documentation regarding deprecated features. (To be fair, I also consider deprecation long overdue for the Perl 4 package separator, but it's not in perldiag, so there's no official deprecation.)

The "That Wasn't My Point Anyway" Argument

The goal of my previous post was very different anyway. I repeat it here because I believe it's more practical for discussion than a philosophical discussion based on differing visions for Perl 5:

I ponder the existence of an alternate Perl 5 binary with deprecated features removed; would DarkPAN developers run it against their test suites and report any results where modifications are onerous? Would that provide sufficient data as to the effects of removing these features?

A modest amount of refactoring could produce an alternate Perl 5 binary -- perhaps cleanperl or a better name -- which has these deprecated features compiled out. That might be a concrete way to see if Perl 5 can run more quickly or to gauge the degree to which these removed features affect real world codebases.