Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Stop suggesting to upgrade perl

by vsespb (Hermit)
on Aug 31, 2013 at 17:25 UTC ( #1051742=monkdiscuss: print w/ replies, xml ) Need Help??

Often on PerlMonks I see posts, asking for some help, with a requirement for perl minimum version (i.e. "perl 5.8.8+" or "perl 5.10+", or "any perl above 5.8" etc).

What surprise me is that people still trying to advice to "upgrade perl" again and again. Why??

Advice to upgrade perl comes from wrong assumption that:

There is only one instance where this code supposed to work.

That's often not true.

Cases where there is only one instance where code should work:

1) You are the only user of your own code. You hack it for yourself.

2) It's a webdevelopment and there is just single instance of web application (I am not talking about single server vs cluster, I am talking about case when you develop one site somesite.com, but not a web framework, not a software-as-service to be installed on your clients machines)

Cases when there are many instances of your code (i.e. when your code have users):

1) You are developing CPAN distribution

2) You are developing standalone application

And it's not an option to ask your users to upgrade perl.

Imaging that all the software that you use (say, under Linux) suddenly change install instruction and and ask you to install "rvm", "virtualenv", "perlbrew", upgrade Glib and GCC, and install certain versions of Python, Ruby and Perl into virtual environments.

If no one would be allowed to run system, vendor, perl, perl would be already dead.

And yes, about "unsupported" perl versions. Most verndor perl versions are unsupported (well, they supposed to be supported by vendors)

Conclusion: Please, don't suggest to upgrade perl if you see that there are clear requirements about *range* of perl versions in the post.

Comment on Stop suggesting to upgrade perl
Re: Stop suggesting to upgrade perl
by choroba (Abbot) on Aug 31, 2013 at 17:30 UTC
    The problem is that for some classes of tasks (e.g. Unicode support), the older version of Perl are insufficient. New versions usually bring new functionality that is not backpropagated to the older versions.
    لսႽ ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ
      If some task is impossible to implement for specified version range, one should mention that (and possibly explain), instead of recomending to upgrade to random (or latest) version.

      There is also difference between "upgrade perl" and "raise minumum perl version requirement", former is indication that person think there is only once instance of code, and, perhaps, recommends just a random new version.

      Unicode in Perl works mostly fine since 5.8.8.
        Unicode in Perl works mostly fine since 5.8.8.
        Except for the "Unicode bug", which was solved a bit later.
        لսႽ ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ
Re: Stop suggesting to upgrade perl
by Ratazong (Prior) on Aug 31, 2013 at 20:23 UTC

    While a reply requiring another perl version than expected won't help the author of the question, it can still be benficial:

    When posting a question to a public site like perlmonks, the answer is not only intended for the author, but also for the many lurking monks reading it. If they encounter a similar problem, they might be thankful that they get the advice that a feature in another perl-version might help them. They might not have the same version-constraints as the original author.

      When posting a question to a public site like perlmonks, the answer is not only inendet for the author, but also for the many lurking monks reading it
      Yes, I agree
      They might not have the same version-constraints as teh original author.
      Yes, but there should be some thin edge. Otherwise, when someone ask for solution for Win32, one may post Linux-only solution. Who knows, maybe it help someone.
        If you'd been here for a bit longer, and read, attentively, a few years worth of questions and answers, I think you'd find that posting a "Linux-only solution" rarely happens when OP specs Win32...

        What's more, if such an OS-only solution does appear it's usually coupled with an explanation of the limits of its inter-OS applicability... and often, with one or more hints about how to modify it for another OS.

        [Shoe-fitting time]: 1 Of course, some OP's write questions with insufficient information to provide useful replies and/or questions so broad as to constitute a request that someone (else!) do the review of the literature; the research and compilation of findings, if any and, when given replies suggesting methods for performing those actions, respond with abusive statements that respondent is maliciously withholding information or -- in the vernacular - 'doesn't have a clue.'

        1. C.f. http://en.wiktionary.org/wiki/if_the_shoe_fits
Re: Stop suggesting to upgrade perl
by chromatic (Archbishop) on Sep 01, 2013 at 04:03 UTC
    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.

      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.)

        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.

        "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
      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?
        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?

Re: Stop suggesting to upgrade perl
by moritz (Cardinal) on Sep 01, 2013 at 07:47 UTC

    If your code base now runs on perl 5.8 only, eventually you will have to upgrade. At some point in the future you'll have new hardware on which the legacy OS that come with legacy perl won't boot anymore, so it's not a question whether you upgrade, but when.

    With that in mind, advice of the form "Upgrade to at least perl 5.12 because it fixes your $problem" is actually quite valuable, because it gives you reason not delay the upgrade any longer.

    Also the more incentive you have to upgrade, the easier it becomes to convince your manager that now would be a good time to spend your resources on upgrading to a newer version of perl. And a list of issues that would be much easier to fix with a newer version of perl is exactly the kind of incentive that convinces managers.

      The post was about users. I can't ask them to upgrade. Perl 5.8 supported till Y2017 in RHEL5, Perl 5.10 till Y2020. Perl 5.12 is probably not too new. But Perl 5.18 is not shipped with majority of distros currently.
        The post was about users.

        Then I don't see your point at all. The vast majority of questions asked on perlmonks is from programmers, not (just) users. The very few questions by users are barely worth discussing.

        Perl 5.8 supported till Y2017 in RHEL5, Perl 5.10 till Y2020

        What does "supported" mean in that context? I guess there will be security updates, right? I don't quite think that Redhat will answer a user's question in 2016 on how to do proper Unicode handling with perl 5.8, will they?

        If you decide to constrain yourself to what Redhat will support, then I suggest that you ask Redhat for help. They're the ones holding you back, not the volunteers here.
Re: Stop suggesting to upgrade perl
by Tux (Monsignor) on Sep 01, 2013 at 10:21 UTC

    I agree that you should not upgrade perl just for the upgrade, and - also - not because some wise monk tells you to without a reasonable reason. I do agree with the volunteer-time that chromatic mentions, but not with that being a reason to upgrade. He has been around long enough to know some problems do not have any issues in perl versions (other than maybe the updated documentation coming with it).

    Nor are there any valid reasons to force anyone to move along to the *latest* version of perl. There may be very good reasons to upgrade, even with the problem at hand, but that does not imply a forced move from 5.6.1 to 5.18.1 where 5.12.3 might be more convenient.

    Note however that perl releases are not made just for the release numbers. However the people in charge (the CEO's, not the perl5 developers) like to see the language alive and being actually developed, those updates have a reason: for most the updates are not because of the new features, but because of bug fixes. A lot of complaints that we as monks see pass by here do get fixed.

    The example given by boftx is imho the worst example to have to opinion not to upgrade. I love defined-or to the extend that I have the feature available for *every* version of perl5.8.x. I can't live without it in my daily work. All production scripts use it. Though by now our production machines and all customers use 5.14.2 as a minimum perl. Also not that this seldom is one of the reasons mentioned in answers here where the OP is asked to upgrade perl, as this was a new feature in 5.10, not a bugfix.

    A next thing I want to mention is related to what chromatic mentions in volunteer time use: the minimum version of perl for the toolchain support has been raised to perl-5.8.1 with an option to be raised to 5.8.4 is 5.8.1 proves to be too restrictive. This was done in the Lancaster Consensus. The reason is that it just takes too much time of the authors of the toolchain to be 5.6 compliant. Having a minimum version as guarantee can make code a lot more simple to write and to maintain. The toolchain however is used for EVERY module on CPAN. This causes the call to upgrade your perl to the minimal version of perl supported by the toolchain, as though your reported bug might not be a perl-bug or a CORE-bug, the bug might have been fixed in a newer release of the CPAN module, but you cannot install it, as the toolchain used to build and install the module does not work on your old version of perl.


    Enjoy, Have FUN! H.Merijn

      That the toolchain is switching to 5.8.1+ does not mean that people on 5.6 will no longer be able to install anything from CPAN. ExtUtils::MakeMaker has been bundled with every release of Perl 5, and the version that comes pre-installed with 5.6.x (EUMM 5.45 for Perl 5.6.(0|1) and EUMM 6.17 for 5.6.2) won't suddenly stop working.

      If a Makefile.PL doesn't use any whizzy new EUMM features, it can thus happily continue to run on Perl 5.6. Even if it does; EUMM 6.72 can be downloaded and installed on Perl 5.6.x with no problems (perhaps EUMM 6.74 too, but no successful reports on CPAN testers yet).

      So even though the toolchain is dropping Perl 5.6 support, people will be able to continue installing CPAN modules on Perl 5.6, provided module authors make the effort to support versions of Perl that old. The toolchain EOL is not the death-knell for Perl 5.6.

      Personally there are very few of my CPAN releases I make the effort to support Perl 5.6 on. Type-Tiny and PerlX-Maybe are amongst them.

      use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name

        You are absolutely right. I also try to support 5.6.x for some of my modules. (I dropped 5.005_04 not too long ago for Text::CSV_XS). What you will see however, is that some modules will require new TESTING features, like Test::More's done_testing and subtests. These might require new(er) build tools and the snowball starts rolling.

        I never stated that 5.6 would not be able to install new CPAN stuff, but that one should be aware that it will/might not work out of the box for many CPAN updates in the (near) future.


        Enjoy, Have FUN! H.Merijn

      I suppose I should have put more emphasis the importance of the intended operating environment.

      I am not opposed at all to running a reasonably recent version of Perl when possible. But it must be borne in mind that there can be considerable time and expense involved for a company to do this. I would be hard pressed to defend the practice of upgrading every time an even-numbered version of Perl came out.

      Tools such as perlbrew make it simple for individuals, but even then, there can be problems if the process takes too long to run and the hosting server (if one is being used) decides to terminate the process. I had this happen to me when installing 5.16 and wound up doing it with --notest and then going back and running the tests manually just for sanity's sake. Part of the cause of this problem can be attributed to the ever-growing number of core modules, it seems.

      I agree with the OP that just automatically saying to upgrade is not always the most practical solution. Unless the problem involved is the result of a bug that can only be properly rectified by an upgrade, I think it is better to suggest a solution that works on the version the requester has, if possible.

      All this being said, I prefer having a recent, reliable version of Perl on a production platform when it makes sense to upgrade. I, too, like the //= operator a lot and use it regularly at work. But that by itself could not justify the expense of an enterprise wide upgrade when I was restricted to 5.8.8, and certainly doesn't justify (in my mind) requiring the use of 5.10 as a minimum version in a CPAN module.

        ... certainly doesn't justify (in my mind) requiring the use of 5.10 as a minimum version in a CPAN module.
        But it must be borne in mind that there can be considerable time and expense involved for a company to (run a reasonably recent version of Perl)...

        You want CPAN authors who give away their code for free, largely in their volunteer time, to test their code against at least a dozen and sometimes as many as seventeen or eighteen stable releases because it's too expensive for a business to upgrade to a supported version of Perl? You object to me using features I personally added to Perl itself several years ago in my CPAN code because it's too expensive for your business to install a new version of Perl more often than once every five years?

        I can understand why you might want that, but why would I do that?

Re: Stop suggesting to upgrade perl
by RichardK (Priest) on Sep 01, 2013 at 14:36 UTC

    But upgrading is usually the right answer, running known buggy software is just dumb.

    If you have special requirements then you must make that clear in the question, not complain about the answers that you get.

      But upgrading is usually the right answer, running known buggy software is just dumb.
      What makes you belive that new versions of software contain less bugs than older? It's never true unless software developers first priority is reducing technical dept. And known bugs are just better than unknown (however, I suspect there were several perl versions where bug rate is too hight. I think between 5.8.1 and 5.8.8)
      that clear in the question
      Of course, I was talking only about cases when I mentioned version in the question. The possible problem that it was not highlighted with big red font and put into title.
Re: Stop suggesting to upgrade perl
by flexvault (Parson) on Sep 01, 2013 at 17:08 UTC

    Hello vsespb,

    I agree with most comments on both sides of your argument, but that is because different requirements demand different solutions. What you have to accept is that we are dealing with different personalities, different degrees of experience, etc, etc. Making a rule doesn't stop people from breaking it!

    So enjoy PM and learn from the comments/knowledge of many monks and ignore the comments that don't fit your rule(s).

    Enjoy the good stuff at PM.

    Regards...Ed

    "Well done is better than well said." - Benjamin Franklin

      Thanks!
Re: Stop suggesting to upgrade perl
by Anonymous Monk on Sep 01, 2013 at 18:53 UTC
    There are many conflicting points-of-view in this post ... I am quite lost ... let us just say that, whenever someone recommends that Perl should be upgraded, they should as much as possible say "to which (minimum) version" and "exactly why." It is or should be obvious that you can't remodel a house (a Perl app) when the problem is in the foundation (Perl). Also that any foundation work is a big-deal that has to be seriously justified esp. when it is impossible, e.g. in a shared host. A business argument will have to be made which will require ammunition. Provide that. Details details.
Re: Stop suggesting to upgrade perl
by Jenda (Abbot) on Sep 02, 2013 at 17:01 UTC

    Imagine that all the software you use suddenly change install instruction and ask you to install .Net Framework version X.Y. Oh wait! They do.

    Jenda
    Enoch was right!
    Enjoy the last years of Rome.

      1) Windows install process is different. It's easier for users to update .Net under Win than update python/ruby/perl under linux.
      2) .Net is monopoly. Most of popular sofware for windows is written in .Net. You ask to update .net when your competitors do. This is not true for perl/ruby/python apps
      3) And I think this whole thread has no relevance to Windows world. There is no perl shipped with windows.

        That is the boxed software way, and its relevant for perl even on linux -- if you want to sysadmin your machine to install prerequisites, you can use app-installer that comes with all the prerequisites -- diskspace is cheap

        It's easier for users to update .Net under Win than update python/ruby/perl under linux.

        Installing new versions of perl/ruby/python under *nix (I use MacOS & BSD rather than linux, but it's minimally different) is generally pretty simple, and I tend to have a number of installs of each on my dev machine (and sometimes on the production server). I use perlbrew for Perl and rvm for Ruby. I don't use much python.

Re: Stop suggesting to upgrade perl
by Argel (Prior) on Sep 04, 2013 at 02:21 UTC
    I brought this up in What is a really old version of Perl?. As you have no doubt noticed by now, the majority of people posting in this thread have little to no understanding of how enterprise environments operate. There's a huge disconnect in the Perl community between developers and system administrators. Ironic, given Perl's roots. Sad too, of course. I doubt they even realize how hostile they come across or that the advice given may at times even be a career limiting move if followed. If there was a community wide effort to raise awareness, evangelize to vendors, etc. then maybe that would make a difference but I doubt the interest is there.

    One thing you could try is putting your limitations in your signature (e.g. policy dictates that you have to use the Perl that ships with your distro and that it is against policy to download modules and manually install them (or just copy the .pm's in)m etc. and then reference that in your post. Then, you can at least berate someone for not reading the limitations in your environment.

    Elda Taluta; Sarks Sark; Ark Arks
    My deviantART gallery

      As you have no doubt noticed by now, the majority of people posting in this thread have little to no understanding of how enterprise environments operate.

      One might equally as well say that these so-called enterprise environments have little to no understanding of negative externalities and the consequences of pushing their support burdens onto the volunteer commons.

        And how is that relevant to this thread? The majority of posts show a gross lack of knowledge when it comes to how enterprises work, etc. -- aka a huge disconnect. And enterprises are not going to change, so if there is any interest in helping those of us that do work in those environments, it needs be directed/focused elsewhere. Encouraging Red Hat, Novel, etc. to ship with a second, newer version is one approach that may work. If there was a semi-official Perl distro that contained lots of additional modules that all of the vendors could make use of that would be even better.

        But the reality is that sysadmins in the enterprise are second class citizens of the Perl community. And with responses from people like you that could help nudge things in the right direction but instead discourage it, there's no reason to expect that to change anytime soon. I know your time is limited, but next time could you consider using that time to help raise awareness of the situation instead? If more people talk about it, then maybe eventually the Perl Community will get to the point where it can ask "Why are these vendors shipping much old versions, causing many of our brethren to suffer needlessly, and causing some developers to support older versions of Perl longer? Is there something we can do to help change things?"

        Elda Taluta; Sarks Sark; Ark Arks
        My deviantART gallery

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: monkdiscuss [id://1051742]
Approved by hdb
Front-paged by Anneq
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (8)
As of 2014-07-31 07:01 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (245 votes), past polls