The "What Does Deprecation Actually Mean" Meta-Argument

| 6 Comments

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.

6 Comments

dep·re·cate (dpr-kt)
tr.v. de·pre·cat·ed, de·pre·cat·ing, de·pre·cates
1. To express disapproval of; deplore.
2. To belittle; depreciate.
3. Computer Science To mark (a component of a software standard) as obsolete to warn against its use in the future so that it may be phased out.'

#3 sure looks like when you label something as "deprecated" it gets "removed" at some point.

In fact, I have only heard the term used when that deprecated feature is going to be weeded out at some future date. There have been warnings for YEARS. Time for the to go.

In the programming world that we live in, "deprecated" means "marked for future removal". Take, say, split in scalar context. If you intend to remove split-to-@_ at some point, you write "Use of split in scalar context is deprecated". If you don't intend to remove it, you write "Use of split in scalar context is a really bad idea that's been retained for legacy purposes." But for 12 years or more (probably 15, but I'm too lazy to verify; 12 is enough), the docs have said "deprecated".

Perhaps depreciation does need a more formalized structure? Something like:
1st major release: simple warning
2nd major release: warning that even gets thrown when warnings is off
3rd major release: fatal warning that can be overridden by explicitly switching it off
4th major release: removal of feature
That would give anyone time to get used to the idea and would prevent anyone from going "i didn't notice".

Also, re DarkPAN: I just realized that any DarkPAN arguments are really completely irrelevant to new releases. Looking back over the past few years I've worked on quite a few projects that would qualify as DarkPAN, and all of them are still stuck at Perl 5.8. This is however not even a conscious decision to stay there, but simply because the Linux distros used for these systems don't even offer Perl 5.10. I'd think that that's really true for most of DarkPAN.

Firstly, I'm for the change following the logic presented in "The "You Can't Have It Both Ways" Argument". I'm going to expand on that with examples:

Perl 5.10 is not Perl 5.8. Perl 5.10 goes so far out that you can not safely assume compatibly with Perl 5.8 without staging your code. It has issues with disambiguiation with the new defined-or operator which is on by default '//', it has Unicode fixes iirc, and it totally removed pseudo-hashes. There are yet more "internal" changes that you have no control of inside of your perl application. In no way shape or form is Perl 5.10 to be a safe-flying autopilot upgrade from 5.8. I'm still reporting bugs with the way Debian packages cpanplus, because using that utility which is now core, can actually render your system unstable.

In addition, more than half of any Perl application by line count is probably perl code you *didn't* write and so you can't speak for its state at all. You can't copy it over from a 5.8 install, and by default 5.10 won't include code that was installed with 5.8's CPAN (/usr/local/lib/perl/5.10.0/ vs /usr/local/lib/perl/5.8.0/). This all makes sense though, after all who knows what uses pseudo-hashes, or single ticks are in the package name?

If Perl 5.10 is more than just a security release, giving potential for major breakage, than what the hell is "use features 5.10"? It is an insult to intelligence. Perl 5.8 is *not* Perl 5.6. Perl 5.6 was not Perl 5.004. And, again Perl 5.10 is not Perl 5.8. So when I install 5.10, I want 5.10. I don't want to have to bloat my code instructing perl to use the features of the version of perl *I* installed.

What is the solution to this depreciation/versioning nightmare. Well as I see it, take perl back to the old release methodology. Perl 5.10 should use its optimized internal C3, and all of the features it has to offer by default! If you want Perl 5.8 install it alongside of Perl 5.10. With that said, I totally agree Perl 5.10 should have yanked out your single-tick package name delimiter, and other deprecated nonsense. Perl 5.10 should represent the latest and the greatest of perl we have to offer.

I agree... with... EvanCarroll! AAAAH!

If someone has turned on fatal warnings, they're being responsible, and actually *want* deprecations to produce a fatal error instead of a warning. They've signed up for it. It is therefore not comparable to the situation where a feature is removed thus code suddenly stops working for a person who has never turned warnings on.

That having been said, as EvanCarroll pointed out, a minor version upgrade suggests issues. I'm more concerned that the error message regarding the missing feature is helpful. Simply saying something like "Syntax error near ';' at legacy.pl line 15832, line 934532321" will not make any friends.

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

affiliated with ModernPerl.net

Categories

Pages

About this Entry

This page contains a single entry by chromatic published on July 21, 2009 1:04 PM.

Deprecated Pointy Bits was the previous entry in this blog.

CPAN, Convergence, and Core is the next entry in this blog.

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


Sponsored by Blender Recipe Reviews and the Trendshare how to invest guide

Powered by the Perl programming language

what is programming?