Earlier quoted context omitted.
In the Git project we target Perl 5.6 for critical code (like git add --interactive) and Perl 5.8 for some other code (like git-svn). Those are 10 and 8 years out of date, respectively. Or the equivalent of targeting Python 1.6 and 2.0. It can be mildly annoying sometimes to have to use 5.6 features when I usually develop on 5.12 or newer, but Perl's policy of backwards compatibility makes this a lot easier than it w…
> equivalent of targeting Python 1.6 and 2.0. I'm less in touch with Perl language development in the past decade, but my impression is that the difference between Perl-5.6 and Perl-5.12 is much less than between these versions of Python and recent releases. This is expected when a language evolves rapidly, but it's rather frustrating to wait 10 years before you can depend on the "new" features being available.
My impression is that the difference between Perl-5.6
and Perl-5.12 is much less than between these versions
of Python and recent releases.
That and its wide availability and portability make it a much better target than Python for something like glue in a build system for a project that's mostly in C anyway.
But even though it's backwards compatible with old code it's still somewhat of a pain to write code that works on old releases that don't have the modules / core features you want.
Backwards compatibility also comes at a price. Many of the changes that broke old Python code broke it because old warts were being fixed in Python. There's a lot of equivalent old warts in Perl that haven't been fixed, and there's no plan for doing so (other than Perl 6).