Have you ever read the documentation for Perl 5's wantarray?
(It's perldoc
-f wantarray.) I don't remember the first time I read it, but as far
back as I can remember, it's said something like:
This function should have been named wantlist() instead.
The second edition of Programming Perl, published in 1996, says something similar.
At least fifteen years later, novices still get tripped up on the difference between arrays and lists. That's fifteen years of confusion and fifteen years of further entrenching the damage of having a core keyword with the wrong name, making the problem worse and the pain of fixing things worse.
(What would have been the problem of making an alias named
wantlist and deprecating but not necessarily removing
wantarray?)
Does not understanding the difference between arrays and lists really cause problems in practicable usage?
perlfaq4 gives a couple of examples but none that I've ever seen in real life. OK, maybe something like '$first = split(//, $string)'. I can see that being a common problem.
I've seen all of the examples in perlfaq4 in real life. That's why they are in perlfaq4.
I see "Why don't nested lists work?" all the time.
I might be slow this morning but I wonder why would a novice even need to know about the "wantarray" function? I am showing it in my advanced class but I am not sure I should encourage the use of it.
Anyway, if it is going to be replaced then wouldn't it be better to use one of the modules that provide you with greater detail of the context? IIRC you even mentioned them in Modern Perl.
Let me restate the sentiment a different way:
Let's say you believe and wish that your software project will become popular-- that someday you will have more than twice as many users as you have now.
You spot a bad design decision that would break backwards compatibility to change it. If you fix it, you may annoy and inconvenience nearly all of your current users. However, if you look forward to growth and new users, you will be inconveniencing and annoying the *majority* of your users may not fixing it. Further, you may be retarding growth by keeping warts in your software, since users who discover your software after the fix won't care that you broke backwards compatibility with a version you never used.
Soon you may find you are competing you with new projects that "started from scratch", but really they learned from your mistakes and left out the warts.
If users are willing to switch to completely new languages, don't you think they would be willing to switch to a new version of your software without the warts?
A fine restatement!