in reply to Re^3: Make $^V and "my" implicit
in thread Make $^V and "my" implicit

If, on the other hand, it won't work simply because the author decided to require some fancy, superficial feature like say....

"What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?" — Larry Wall

One person's superficial triviality is a feature that's been in Perl for more than six years now. How long before it's acceptable for volunteers who give away their code freely to use those features? Ten years? Fifteen? If I fix a bug in Perl today and it gets released in 5.20, will I be able to rely on that bug being fixed by 2024? 2029?

You don't have to upgrade Perl, but you don't have to use any modules I've written either. Even better—you don't have to use them as written. You are more than free to modify them to run on your preferred version. I'll even give you a comprehensive test suite so you can prove that they work to your satisfaction. You can even redistribute the modified version.

Is that not enough?

Replies are listed 'Best First'.
Re^5: Make $^V and "my" implicit
by FloydATC (Deacon) on Feb 05, 2014 at 07:44 UTC

    I have to admit I don't know exactly who wrote each and every module I use, and I'm very happy that this isn't (yet) a big enough problem to cause great concern and personal discomfort.

    I'm just saying that if a critical component like DBI or LWP broke on RHEL/CentOS 5 tomorrow because someone wanted to use new and shiny features to golf the code down a bit, I think you'd see a sharp decline in the popularity of Perl.

    Bug fixes are ofcourse a completely different subject. Anyone who writes production code that relies on a bug to function properly should have their keyboard privileges permanently revoked.

    -- FloydATC

    Time flies when you don't know what you're doing

      someone wanted to use new and shiny features to golf the code down a bit

      The people who pay me need working Unicode. I don't have to release parts of that code so that you can use, modify, and redistribute it without paying me, but I do.

      (Come to think of it, no one who's contributed to Perl itself in the past six years has charged you a penny to use it.)

      Do you intend for your comments to sound condescending and insulting?

      A faster regular expression engine is only good for golf? Working Unicode is only good for golf? A regular expression engine without recursion crashes is only good for golf? Memory optimizations are only good for golf? Self-recursive functions without memory leaks are only good for golf? Native casefolding is only good for golf? Fixed memory leaks are only good for golf? DoS-safe hashes are only good for golf? A working keyword extension mechanism is only good for golf?

      Do you really mean to give the impression the only reason someone would use anything newer than 5.8 is because he or she thinks adding "\n" to the end of every print is onerous?

        Do you intend for your comments to sound condescending and insulting?

        No, that was never my intention. English is not my native language so if I came across that way then I apologize.

        -- FloydATC

        Time flies when you don't know what you're doing

        Perhaps you would benefit from stepping back from this for a bit?

        Do you intend for your comments to sound condescending and insulting?

        Do you mean for your comments to sound thin-skinned, whiny, and off-topic?

        Do you really mean to give the impression the only reason someone would use anything newer than 5.8 is because he or she thinks adding "\n" to the end of every print is onerous

        If you weren't being so thin-skinned, then you might have been able to read how clearly it was stated that none of what you say above is what was meant.

        That there exist quite valid even compelling reasons for a particular module to not support some particular older version of Perl does not contradict that there are module versions that explicitly don't work on versions of Perl for which the only reasons are trivial and/or stupid.

        Complaining about the latter is not the same as complaining about the former. If you have not produced instances of the latter, then you certainly shouldn't take such complaints as insults (and even if you have, you still don't need to).

        - tye        

      There now is a "consensus" of what the minimum version of perl is to be supported for the major modules on CPAN (amongst which is DBI). The consensus today is 5.8.1, with an option to move to 5.8.4 when the need arises.

      The fact that a new version of any of those important modules starts using a new(er) feature that will require a newer version of perl does NOT mean that the previous version of the module suddenly stops working.

      The module authors are very well aware of OS's that stick to old(er) versions of perl, but sometimes it is hard to stick to cruft to make a module build on those old platforms or OS's. A reason might be that a compiler is buggy. That buggy compiler also does not get updated/upgraded on that old system, so why would you update a perl module that behaves well?.

      Once you update the OS, you also probably get a newer version of perl and your problem is gone. If you don't use system perl, nothing is stopping you installing a newer version of perl alongside the system perl.

      As most modules have public repositories nowadays, nothing is stopping you to backport bugfixes that affect you to the now unsupported ancient environment.

      I for sure do NOT foresee a sharp decline when module authors start declaring 5.8.4 as a minimum.


      Enjoy, Have FUN! H.Merijn

        "There now is a "consensus" of what the minimum version of perl is to be supported for the major modules on CPAN (amongst which is DBI). The consensus today is 5.8.1, with an option to move to 5.8.4 when the need arises."

        Not really. There is a consensus that the toolchain will support 5.8.1 with the option to move to 5.8.4. The toolchain is the set of modules that are needed to be able to find, download, and install other modules from CPAN - for example, ExtUtils::MakeMaker, Module::Build, Test::Harness, etc.

        This is not all "the major modules on CPAN". DBI is not considered to be a toolchain module - however, it does currently support Perl 5.8.1.

        There are certainly major modules that do not support 5.8.1. Moose is an obvious one; it requires 5.8.3. Catalyst also requires 5.8.3.

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

        You obviously have to draw the line somewhere and you mention perfectly valid reasons for abandoning an old platform. I don't expect newer modules to compile on my last surviving CentOS 4 box. (Running Oracle 9 for three old databases that won't run on anything else, good luck with installing that on a newer platform...)

        In my opinion, this is a completely different from a developer simply wanting to use new and fancy features that don't exist on the majority of the servers where the language is in widespread use.

        None of this is new ofcourse. Imagine where Windows could have been if MS hadn't bothered with backwards compatibility. It would probably have been 1/3 of the size, an order of magnitude faster, and installed on perhaps as many as 200 computers world-wide.

        -- FloydATC

        Time flies when you don't know what you're doing