Tuesday, 21 July 2009

Deprecation in the Perl core

chromatic goes on arguing that deprecated language constructs deserve to be removed just because they're deprecated.

I'll argue, at the contrary, that deprecated constructs should be removed only when they stand in the way of a performance improvement or of a bug fix. Which is precisely why, for example, pseudo-hashes, empty package names or $* got removed in Perl 5.10. In other cases the deprecation warning is more of a "bad style, don't do this" message -- until someone finds a good reason to remove the deprecated construct.

Here are a few examples, which are a panel of different cases:

  • The $[ variable used to be a waste of memory. Now re-implemented as a %^H element, its existence has now no runtime memory impact (as long as it's not used). It's very possible, however, that it has a speed impact (I'd be glad too see a benchmark). If someone demonstrates that perl can be made faster by removing it, it's worth removing. (Note that it's deprecated in bleadperl currently.)

  • The apostrophe syntax for namespaces (foo'bar instead of foo::bar) has been used quite recently for its cuteness value (like the function isn't). It's not yet deprecated. Moreover the core still has Perl 4 files that use it. (Those would be worth considering for removal, by the way -- they're not maintained.) However, it's largely considered bad style to use this syntax and it can be confusing (as in print "$name's"). Adding a deprecation warning would be nice to warn users against potential errors, but I think that removing it would cause too many problems; so, that deprecation warning is likely to stay for some value of ever.

  • The defined(@foo) and defined(%bar) syntax is actually only deprecated for lexicals -- not for globals. (You can check.) Some deep magic uses them for stashes. I'm not sure about the details, but a comment in toke.c asserts that removing them would break the Tk module. So that construct can't be removed without some heavy engineering to devise a replacement.

  • Finally, the "split to @_ in scalar context" deprecation. Removing assignment to @_ would change the behaviour of split, and that's what caused the discussion on P5P: if we remove it and replace it by something more sensible, code developed on 5.12 might cause problems when run on an older perl. Opinions differ here. I would personally favor removing it unconditionally, which is likely to be chromatic's point of view too (for once). More conservative opinions were issued.

Now, let's have a look at the two arguments against deprecation and removal that are misrepresented by chromatic:

The arguments for retaining these features are likewise simple: modifying code may cause bugs and removing features may break existing code.

First, "modifying code may cause bugs". This meme surfaced on P5P about a very complex and hairy Perl module with almost no test (ExtUtils::ParseXS). However the code changes we're talking about here are C changes. Written properly, C is a more straightforward language than Perl, and the test coverage of the core is excellent. So I don't buy that argument at all and I don't think anyone knowledgeable used it seriously about core changes. Also, if we're speaking only about adding a warning, it's usually a very simple change. Removal itself might be more complex, but still a lot simpler than adding features. And features get added.

Secondly, "removing features may break existing code". Right, but are we talking about deprecation of removal ? chromatic seems to suppose that deprecation must necessarily be followed by removal. He says: The problem, I believe, is that there's little impetus to migrate away from deprecated features; features can remain deprecated for 15 years. But this is not a problem -- this is a sensible policy decision. Unlike mere deprecation, removal of constructs will break code, so we must balance it with convenience, and proceed only when it brings more benefits than inconveniences for Perl users.

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. But instead of repeating myself on that point, let me finish this post by a quote:

Perl has broken backward compatibility in the past where I judged very few people would be affected.
-- Larry Wall in P5P.


Robert said...

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.

I have only heard that term used when it is meaning that the feature will be removed at some future date. Deprecation warnings have been in for YEARS...time to do some weeding.

Aristotle said...

I agree for the most part, but there is one argument I have to point out. “How does software get bloated? One feature at a time.” It may not make much sense to remove any one particular deprecated feature – but it may well make sense to remove a whole pile of them.

I haven’t ever really touched the guts so I can’t make a call on how much complexity the totality of deprecated features adds to perl. Therefore I don’t know if that argument is applicable here. But there certainly is a valid argument to be made in favour of removing deprecated features “just because”.

Tom DeGisi said...

Yes, deprecated features should be removed just because they are deprecated. That's what deprecated means. If we don't remove them we should stop calling them deprecated. Call them ill-advised. Add them to Perl::Critic. But do not refer to them as deprecated.

Tom DeGisi

Rafael said...

Tom, no, they should not. I'm not expressing an opinion here. I'm explaining a fact: why are there very old deprecated features in perl.

Tom DeGisi said...


These features are certainly labeled deprecated. That is a fact.

You have expressed your (very well informed) opinion about why they should not be removed. However, if they are labeled deprecated then they should be removed, because that is what the label deprecated means. Therefore you are arguing that these features should not be deprecated. That's fine. If you are correct that they should not be removed, then they also should not be deprecated. My point is that our words should have meaning or there is no discipline in our programming.

I think that if you believe these features should not be removed you should submit a patch so that they are no longer deprecated. If your patch is accepted, they won't be removed. If your patch is not accepted, they should be removed.

Tom DeGisi

James Mastros (theorbtwo) said...
This comment has been removed by the author.
James Mastros (theorbtwo) said...

Two more or less seperate responses. The first one is a narrow response:

I. Removing the $[ varable would speed up perl, and probably fairly signficantly. See benchmarks at http://www.nntp.perl.org/group/perl.perl5.porters/2009/04/msg145542.html, the thread leading up to it's deprecation.

II. The old, general term deprecation doesn't imply that we will remove it. It just implies that we make fun of it. The implication that we remove it late is, as Robert (possibly unintentionally) pointed out in the first comment, is a rather recent and narrow evolution of the meaning of the word. Sure, we could start marking things as depricated without implying their planned removal... but to do so would cheapen it. "Sure, they marked it deprecated, but they aren't going to remove it! Look at that other thing, they marked it and haven't removed it for *years*!", then, a release later "HOW DARE YOU GET RID OF THAT! I STILL US IT!"
If we want people to stop using things so we can add features, or even just remove complexity, then we should only say things are deprecated when we plan on actually removing them.
Most of the time, when we deprecate things, we do so already having some idea what we want to replace it with (and yes, sometimes, that's just a cleaner language then when we left it, though such proposals tend to not be very well-recieved).