Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Re^5: Make $^V and "my" implicit

by FloydATC (Hermit)
on Feb 05, 2014 at 07:44 UTC ( #1073523=note: print w/ replies, xml ) Need Help??


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

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


Comment on Re^5: Make $^V and "my" implicit
Re^6: Make $^V and "my" implicit
by Tux (Monsignor) on Feb 05, 2014 at 10:55 UTC

    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

      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

      "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

        All (big) modules depend on (part of) the toolchain, so the consensus implies what I said.


        Enjoy, Have FUN! H.Merijn
Re^6: Make $^V and "my" implicit
by chromatic (Archbishop) on Feb 05, 2014 at 20:25 UTC
    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?

      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 are module versions that explicitly don't work on versions of Perl for which the only reasons are trivial and/or stupid.

        I'm sure patches (or even bug reports) would be more welcome than general complaining, though I'm not sure who gets to decide where a reason is "trivial and/or stupid".

      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

        Your English is far, far better than my Norwegian or Finnish, so no apology necessary. I agree that backwards compatibility is a good feature of Perl, even though I do believe that organizations which choose to use Perl beyond its public supported date have taken on the responsibility to maintain the code on which they depend. That's all.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1073523]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (3)
As of 2014-09-21 09:51 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (168 votes), past polls