5 ms·

> 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 bet

> 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.

berntb 16y ago
This backwards compatibility is a conscious decision. And it is argued about. To find a bit to read about that, Google e.g. for darkpan. (It is probably one reason why Perl 5 is so extensible.)
- acqq 16y ago
  Thanks berntb! That's a perfect tip for a new submission: http://news.ycombinator.com/item?id=1712404 http://news.ycombinator.com/item?id=1712404 The DarkPAN matters "There is currently some FUD going about in some parts of the Perl community about why we should break Perl 5 backwards compatibility. A short blog entry, schmarkpan, is a good example of the trend: loud, noisy, but clueless and devoid of any content."
avar 16y ago
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. Your impression is correct. Perl is a more mature platform than Python, and backwards compatibility is taken more seriously. The latest Perl 5.12 release can still run most of the test suite for Perl 1 released back in 1987. 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).
- jedbrown 16y ago
  There's a lot of equivalent old warts in Perl that haven't been fixed This is the crux of the issue. Serious language users (especially the ones writing the new libraries that add significant value to your platform) want the warts fixed to make the environment pleasant to work in. Meanwhile, most casual users are desperate for backward compatibility because it makes distribution easier. I actually prefer Python's choice, but pain is inevitable either way.
  - avar 16y ago
    I should have said: They haven't been fixed by default. Perl is also moving forward, it's just doing so differently than Python. Python has major releases like 2.6 and 3.0 where they explicitly break old code in the default installation. Perl however doesn't break any of the old warts by default, but developers can easily do so by importing modules like Moose and perl5i in their own code. See http://search.cpan.org/perldoc?Moose http://search.cpan.org/perldoc?Moose and http://search.cpan.org/perldoc?perl5i http://search.cpan.org/perldoc?perl5i Perl's model means that you can usually upgrade any code base from say 5.6 to 5.12 without major headaches. But if you try to do the equivalent with Python 1.6 to 3.0 you'll run into trouble. There are advantages to both models, but with Perl's you rarely see users with big legacy code bases staying behind on some legacy 10 year old release of Perl that may have bugs and security issues. Users usually just upgrade along with their OS without any major pains.
    - jacobolus 16y ago
      Which code was explicitly broken by Python 2.6?
      - SapphireSun 16y ago
        iirc nothing was, but it made available some features that would be used in 3.0 and 2.7 is essentially a back-port of stuff the 3.0 people found useful. I believe the idea is that in a major version number, everything is back compatible.
    - 16y ago

berntb 16y ago

This backwards compatibility is a conscious decision. And it is argued about. To find a bit to read about that, Google e.g. for darkpan. (It is probably one reason why Perl 5 is so extensible.)

acqq 16y ago
Thanks berntb! That's a perfect tip for a new submission: http://news.ycombinator.com/item?id=1712404 http://news.ycombinator.com/item?id=1712404 The DarkPAN matters "There is currently some FUD going about in some parts of the Perl community about why we should break Perl 5 backwards compatibility. A short blog entry, schmarkpan, is a good example of the trend: loud, noisy, but clueless and devoid of any content."

avar 16y ago

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. Your impression is correct. Perl is a more mature platform than Python, and backwards compatibility is taken more seriously. The latest Perl 5.12 release can still run most of the test suite for Perl 1 released back in 1987. 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).

jedbrown 16y ago
There's a lot of equivalent old warts in Perl that haven't been fixed This is the crux of the issue. Serious language users (especially the ones writing the new libraries that add significant value to your platform) want the warts fixed to make the environment pleasant to work in. Meanwhile, most casual users are desperate for backward compatibility because it makes distribution easier. I actually prefer Python's choice, but pain is inevitable either way.
- avar 16y ago
  I should have said: They haven't been fixed by default. Perl is also moving forward, it's just doing so differently than Python. Python has major releases like 2.6 and 3.0 where they explicitly break old code in the default installation. Perl however doesn't break any of the old warts by default, but developers can easily do so by importing modules like Moose and perl5i in their own code. See http://search.cpan.org/perldoc?Moose http://search.cpan.org/perldoc?Moose and http://search.cpan.org/perldoc?perl5i http://search.cpan.org/perldoc?perl5i Perl's model means that you can usually upgrade any code base from say 5.6 to 5.12 without major headaches. But if you try to do the equivalent with Python 1.6 to 3.0 you'll run into trouble. There are advantages to both models, but with Perl's you rarely see users with big legacy code bases staying behind on some legacy 10 year old release of Perl that may have bugs and security issues. Users usually just upgrade along with their OS without any major pains.
  - jacobolus 16y ago
    Which code was explicitly broken by Python 2.6?
    - SapphireSun 16y ago
      iirc nothing was, but it made available some features that would be used in 3.0 and 2.7 is essentially a back-port of stuff the 3.0 people found useful. I believe the idea is that in a major version number, everything is back compatible.
  - 16y ago