|
in reply to Stop suggesting to upgrade perl
What surprise me is that people still trying to advice to "upgrade perl" again and again. Why??
Because it's not worth my volunteered time to remember all of the bugs fixed in the 17 versions of Perl released since Perl 5.8.8, seven and a half years ago, just as it's not worth p5p's volunteered time to support the 17 versions of Perl released since then. I'll give you my best advice, filtered by all of my experience, but if I've run into problems in previous versions of Perl that I think you're likely to run into, and if they've been solved by subsequent releases, that's actionable information you really ought to know. Ignore it if you like. |
Re^2: Stop suggesting to upgrade perl
by boftx (Deacon) on Sep 01, 2013 at 05:25 UTC
|
With the understanding that this is only my personal opinion, I will attempt to make a reasonable contribution here.
One of my pet peeves is that CPAN authors will sometimes use a feature from a relatively recent version of Perl that is not backwards compatible just because the feature is "cool". One of the worst offenders of this would be the use of the defined/or operator. Yes, saying "//=" is concise and more accurate in many instances, but does it really provide any real advantage over using "||=" in the majority of use cases?
Worse still, IMO, is using Moose (and MooseX) when it is trivial to use traditional OO Perl to do the same thing.
I will be the first to agree that there are many times when using "modern" Perl idioms makes life easier, but that being said, I have found that those occasions are usually in a private environment as opposed to a public environment such as CPAN. I have often argued with myself over this when considering what version of Perl to require for my code that is intended for public consumption.
I respectfully submit that there is a vast difference between requiring a Perl upgrade because of a bug fix and the desire to use a new feature that can already be achieved by an older version, albeit in a more verbose fashion. In fact, I will go so far as to say that some of the more recent "improvements" to Perl encourage "cargo cult" programming in that new programmers adopt the new "standards" without any understanding of why these new features were introduced/requested in the first place. (I am thinking of an instance I had to deal with just yesterday that involved someone defining a new attribute with a builder without thinking about the consequences of not specifying "lazy" as well.)
| [reply] |
|
|
Yes, saying "//=" is concise and more accurate in many instances, but does it really provide any real advantage over using "||=" in the majority of use cases?
Given that it's more accurate, yes. Accuracy is a fine feature in many programs—perhaps even most. I like getting the right answers and I like having fewer bugs than more bugs.
Besides, it's a feature of a Perl release that's nearly six years old. If you want it on a Perl that's even further out of date, you can easily get patches for Perl 5.8 and perhaps even 5.6... but if that's just too much work for you, it's trivial to replace instances of it with a combination of defined and multiple appearances of the relevant variable.
Worse still, IMO, is using Moose (and MooseX) when it is trivial to use traditional OO Perl to do the same thing.
I just can't see it as a terrible thing that people who volunteer to give away their code for other people to use freely choose to do things that make their volunteer work enjoyable. You might as well suggest that we stop using Perl and start using the combination of shell, awk, sed, C, and other Unix tools because that's compatible with SysV in its purest form circa 1986. (Imagine how awful it would be if POSIX features were available to people who didn't know how to use them in C, let alone implement them.)
... but this is all a silly argument for you to make, because you've already poisoned the well by claiming that all features in Perl newer than your personal cutoff point are merely "cool" and not useful.
| [reply] |
|
|
| [reply]
[d/l] |
|
|
|
|
|
|
"Worse still, IMO, is using Moose (and MooseX) when it is trivial to use traditional OO Perl to do the same thing."
One reason to use something like Moose for answers is that you're often trying to illustrate high-level design; how to split a large problem down into discrete areas of concern. Moose's declarative syntax makes that high-level design clearer; there are fewer distractions in the code like manually-written constructors and accessors.
In other words, if you're asking about how to use bless, I'll show you; but if you're asking how to structure a large application, I don't want to post code that looks like I'm trying to teach you how to use bless.
use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name
| [reply]
[d/l]
[select] |
Re^2: Stop suggesting to upgrade perl
by vsespb (Chaplain) on Sep 01, 2013 at 14:56 UTC
|
Because it's not worth my volunteered time to remember all of the bugs fixed in the 17 versions of Perl released since Perl 5.8.8
1. There are no evidences that there are less bug in new version, see Re^2: Stop suggesting to upgrade perl
2. You don't have to remember all bugs
3. You don't have to answer questions
4. You don't have to answer questions which ask for support for older version of perl.
5. If certain perl version is business requirement, why answer with suggestion to drop this requirement?
| [reply] |
|
|
There are no evidences that there are less bug in new version...
If you don't trust the closed tickets in RT or the bugs listed as fixed in the perldeltas or the test cases accompanying bug fixes, why are you using Perl at all?
If certain perl version is business requirement, why answer with suggestion to drop this requirement?
If you already know the answer you want to get, why are you asking for help?
| [reply] |
|
|
If you don't trust the closed tickets in RT or the bugs listed as fixed in the perldeltas or the test cases accompanying bug fixes, why are you using Perl at all?
I meant there are always new bugs.
| [reply] |
|
|
