Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • If you want a demonstration, get a computer with a fresh untouched install of a 5-year old Perl...

    I'm not sure how to make it easy for people who don't upgrade their software to upgrade their software, when the defining characteristic of the group of people who don't upgrade their software is that they don't upgrade their software.

    There's a point at which helping people do stupid things goes beyond negligence and on toward malice. Supporting ancient versions of Perl gets dangerously close to that line--else why in the world are we continuing to develop Perl?

    • You make it easy for people that don't upgrade their software to upgrade their software by making the software help/force them to upgrade their software.

      The only challenge is in doing it in a way that isn't stupid.

      In essence, if the past is stupid and broken and will hurt them, and they don't realise it, then we drag them into the future unless they actively tell us not to.
      • Is your plan then to produce a minimal amount of software that can upgrade an ancient Perl installation into something modern, at which point the entire upgraded toolchain is available?

        I'm all for that.

        Crippling all of the nice modern tools that take advantage of all of the nice bugfixes and new features developed this millennium in Perl for the sake of people who refuse to upgrade, however, bothers me a little bit.

        • My plan is to firstly make the toolchain aware of the fact it is fatally out of date, and to give it the ability to upgrade itself.

          If, in the process of doing so, an ancient Perl discovers that part of the toolchain is not longer supported on that version of Perl, it should intentionally stop and tell the user CPAN no longer is supported on Perl version $blah, rather than just crashing.
          • Provided that only a minimal amount of code has to be backwards-compatible with, say, 5.004_x, that sounds reasonable.

            • That should be the case.

              From my monitoring of heavily used modules, CPAN as a whole has had a fairly clear dependency on 5.005 for a long time.

              And there's been a trend over the previous year to 5.6.1 as a minimum.

              Plus of course the 5.8.5 unicode sanity point.

              We'll see how it goes, but I don't expect the requirements to be too onerous, and the amount of code should be fairly minimal.
    • A 5 year old perl install is 5.8.0 (well 4 years 8 months). Is that really old enough to be called ancient?
      • Yep, go try it.

        Typically what will happen is that some module (say, Catalyst) will have a dependency that uses Module::Build in the Build.PL. But dependencies don't get installed until AFTER Build.PL.

        Circular unresolvable dependency. Explode.

        Unless you first upgrade Bundle::CPAN, the standard CPAN client doesn't work.

        And anyone that isn't a Perl programmer is going to have no idea that they have to upgrade CPAN to unbreak it before they run it.
      • Sorry, I didn't realise you were replying to chromatic, not me.
      • There have been eight stable releases of Perl since 5.8.0. That number will soon be nine. It's ancient.