|
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?
| [reply]
[d/l] |
|
|
| [reply] |
|
|
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.
| [reply] |
|
|
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).
| [reply] |
|
|
| [reply] |
|
|
Re^6: Make $^V and "my" implicit
by Tux (Canon) 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
| [reply] |
|
|
"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
| [reply] |
|
|
| [reply] |
|
|
|
|
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
| [reply] |
