[Israel.pm] Informal poll: Why are you (or your company) still using an older version of Perl?

Shlomi Fish shlomif at iglu.org.il
Sun Nov 1 01:34:52 PST 2009


On Saturday 31 Oct 2009 13:58:29 guy keren wrote:
> Gabor Szabo wrote:
> > On Fri, Oct 30, 2009 at 4:49 PM, guy keren <choo at actcom.co.il> wrote:
> >> i have a different question: why do you care?
> >
> > That's a good question too but your comment regarding
> > selling courses was quite nasty.
> > But hey, it was true.
> 
> if it was nasty - this is not my fault - you started sounding too
> "microsoftish" in the way you wrote your question - and i wanted to make
> sure that the motives are clear.

I don't think Gabor sounded "Microsoftish". Microsoft is not the only one who 
pushes upgrades, and many companies and open-source projects provide free or 
cheap upgrades and still want you to upgrade so they can end-of-life the 
support of old versions.

I release many new versions of CPAN modules and other FOSS projects I 
maintain, and I only support the latest stable release. Normally, I maintain 
backwards compatibility, and I otherwise expect people to upgrade to the 
latest versions and don't support older versions. And being open-source, the 
upgrades are free. 

> 
> > I want to help keeping Perl viable in the future so I can sell more
> > courses.
> >
> > Or am I not supposed to to that as an open source developer?
> 
> one thing to keep it viable - and another thing is to do it by trying to
> "Force" people to upgrade. if you start doing this - you become as bad
> as microsoft's marketing - ever pushing people into using something they
> don't realy need.

Gabor cannot and will not "force" anyone to upgrade. There's a difference 
between encouraging people to upgrade or giving reasons that they would and 
forcing them to. Microsoft's marketing also cannot force anyone to upgrade, 
though they may have more resources to encourage people to do it, and can also 
end-of-life their proprietary products.

I agree with Gabor that clinging to old versions of perl is bad on many 
respects: it scares away many good developers (who will prefer not to work for 
you), it delays the inevitable, it does not allow using many CPAN 
distributions that require later versions of Perl (and distributions that are 
dependent on them), it requires developers extra work in supporting them. 
Often, just upgrading to a newer version of Perl and doing all the maintenance 
work will be much cheaper in the long run.

I should note that in some cases it is worse than Perl. For example PHP 4 was 
not backwards compatible with PHP 3, and PHP 5 is not backwards compatible 
with PHP 4, and PHP 6 won't be backwards compatible with PHP 5. There is some 
talk about dropping support for PHP 4, which still can be found in many 
places, and I've witnessed PHP dropping compatibility with working code in a 
third digit release (x.y.[[z]]), and leaving the SimpleTest users in the cold.

> 
> > If companies stay at old versions of perl for a long time they will start
> > complaining that they have an old version of perl that lack all kinds of
> > things.
> 
> i don't know about you - but companies i worked in hardly ever
> complained about that.
> 
> companies i worked in had no time and manpower to re-port all the old
> code to work with newer versions of perl if things start breaking up.
> there were always more important things, and unlike what you imply - the
> price for staying with an older perl wasn't necessarily such a big price.
> 

The perl releases are *mostly* backwards compatible. The emphasis is on 
"mostly" because we cannot 100% guarantee that things won't break, if your 
code was too funky or relied on bugs, etc. There are over 100,000 automated 
test assertions in the perl 5 code (and many more in CPAN modules), and it is 
regularly smoke tested on various platforms. This tests assure a high level of 
backwards compatibility and bug-freeness. CRuby and CPython don't have nearly 
as many tests and as a result might break much more often in subtle ways.

Old perl 5 major releases (5.004, 5.005, 5.6.x, 5.8.x, etc.) are known to have 
some security problems that have been fixed in newer releases of Perl, and not 
fixed in earlier versions due to lack of motivation on part of the perl5-
porters, or volunteers (though, naturally, a volunteer would be free to 
maintain them, assuming they were motivated enough).

> hey - i write code in C - and this language (as a language) remained
> almost the same for years - most people don't even dare to use the newer
> C standard from 1999 - most use the standard from 1989. still - the
> libraries get added, changed, updated, more powerful, etc. - without
> breaking their language compatibility. the only thing that changed the
> way people program in C was the addition of multi-threading support
> (because this ha to be done in a somewhat intrusive manner) - and even
> this was overcame eventually without changing the base system. yes -
> there was also the change in function decleration syntax.

It's not uncommon for C programs to break between newer compilers, porting to 
new architectures, different UNIX systems, upgrades of libraries , etc. The C 
porting effort is likely much higher than that of a typical Perl program. 

> 
> > They complain the code is unmaintainable and that they cannot upgrade
> > as the gap is to big. In many companies the "solution" is to rewrite the
> > applications in some other language.
> 
> why is code unmaintainable? code's maintainability got nothing to do
> with the syntax of the language - and it got all to do with how it was
> written in the first place.
> 
> i don't realy buy that those syntax changes increase programmer
> productivity by that much. you want to break the syntax? fine, break it.
>   and then expect the consequence you mentioned - that people getting
> burned by this will decide to move to other languages.
> 

Sometimes they are critical. For example:

<<<
open my $file, "<", $filename...
>>>

Vs. :

<<<
open my $file, "<$filename" # Dangerous!
>>>

Or "use warnings;" which was introduced in a recent version of Perl and is a 
great time saver. Often, with the Unicode support that was introduced in 
perl-5.8.x, emulating it would be extremely difficult.

Furthermore, people tend to get used to these extra syntaxes, and then they 
have to say to themselves "Wait! I cannot use it. Better do it this way." when 
working on older Perls.

> i am seeing a similar issue with python - they decided to break the
> compatibility between versions of python - we'll have to wait and see
> how this affects the python following.

perl-5.10.0 is backwards compatible with all previous version of Perl 5 and 
with Perl 4 down to Perl 1. Perl 6 will be entirely different but it is not 
meant to replace Perl 5, but rather to co-exist with it.

> 
> > It also creates a pressure on the CPAN developers and on the perl porters
> > to keep perl fully backward compatible all the way to 5.0 and beyond.
> > See, up to a few months ago Michael Schwern was working too hard to keep
> > Makemaker work on the 5.0x line just to satisfy those who don't want to
> > upgrade perl. On the perl 5 porters list - the maintainer and
> > developers of perl -
> > there is a constant tension between the people who want to remove syntax
> > that was deprecated 10-15 years ago(!) and between those who fear that it
> > might create bad reaction among the perl users.
> 
> why are you so astounded about features from 10-15 years ago? i will
> remind you that the basic unix system calls API hardly broke since the
> 1970s - almost 40 years ago. when people feel a need for a more
> powerfull API - they add, rather then replace. they usually add APIs -
> not syntax.
> 
> > There is a price for companies that are not upgrading perl. Maybe the
> > problem is
> > that currently a large chunk of that prices is paid by the open source
> > developers
> > and those who would like to have more modern perl.
> 
> it all depends on the purpose of those developing the language. if their
> purpose is to write the best language they can - they should by all
> means stop supporting the old features. if their purpose is to increase
> the adoption of perl - they should consider backwards compatibility.
>

Like I said, Perl is mostly backwards compatible. But some features were added 
since then that people have become to rely on. Are you in the mood of 
deploying all the latest and greatest software on a modern Fedora release on 
an old Red Hat 5.x release? I'm not sure if it will actually compile. The 
modern Fedora release's tool-chain is mostly backwards compatible to the Red 
Hat 5.x's one, but I'm not sure if the Red Hat 5.x would be forward compatible 
with it.

And doing the porting now rather than later will make it easier on anybody.

Regards,

	Shlomi Fish

> --guy
> _______________________________________________
> Perl mailing list
> Perl at perl.org.il
> http://mail.perl.org.il/mailman/listinfo/perl
> 

-- 
-----------------------------------------------------------------
Shlomi Fish       http://www.shlomifish.org/
The Case for File Swapping - http://shlom.in/file-swap

Chuck Norris read the entire English Wikipedia in 24 hours. Twice.


More information about the Perl mailing list