Re^8: perl.com has been restarted

[Laurent_R]

I don't disagree with your logic at all.

And you don't see that this is really a problem?

Look, I'm using Perl 5 daily at $work. Perl 5 is (to a large extent) paying my bills. And, besides, I really love Perl 5.

Now, I am really sad to say that, but Perl 5 hasn't been able to produce any major feature warranting a major version number upgrade over the last 20 (or actually 24) years, and you just said that you don't disagree with that point of view. Gee, almost a quarter century without a really major change. (And, BTW, the only significant improvements that could possibly justify a major upgrade (if they were included into the core) have been stolen from Perl 6.)

And the reason for Perl not being currently able to produce really new killer features is certainly not Perl 6, quite the opposite. The reason is: "DON'T BREAK BACKWARD COMPATIBILITY." Nothing else. This is bullsh*t and this is killing us. This compatibility compliance has been an advantage during many years, but it has become a major drawback and impediment, and this has happened already many years ago.

Well, at this point, the whole Perl 5 community should really reflect on that: do we really want to let this language slowly die for fear of breaking compatibility? I certainly don't want this to happen (even though, given my age and the longevity of languages in general, I'm rather likely to die before Perl 5, or, at least, to retire well before Perl 5 goes away.)

My point is this: if we want to save the Perl 5 language, we have to get out of this compatibility syndrome. Let's face that, it's killing us.

Breaking this compatibility problem is exactly what the Perl 6 project was about. Many many years ago already. Now, I can certainly understand that many people thought that the Perl 6 project was going too far in this direction and that the changes should be more limited; perhaps too many bells and whistles, also. And, obviously, implementing all these new features took far too much time. Well, I think we can live with two languages in the same family: one which is ambitious and bold, and one which is more conservative and currently more solid (and battle-tested, as someone here would say).

But open your eyes and face reality: the Perl 5 status quo is killing us. Perl 5 need a major overhaul, or it will fade away. I can only hope that it is not too late already.

Update: s/UPWARD/BACKWARD/

[chromatic]

Perl 5 hasn't been able to produce any major feature warranting a major version number upgrade over the last 20 (or actually 24) years, and you just said that you don't disagree with that point of view. Gee, almost a quarter century without a really major change.

For somewhere between 10 and 17 of those years, something has been in the way of those major features, whether putting pressure on Perl to stop being a moving target, to prepare for a port to a new platform, to maintain syntactical compatibility, or whatever.

As the kids these days say, I'm old enough to remember Larry sitting in my hotel room adding MAD to Perl to make it easier to translate Perl code to P6. Keeping that experiment around was enough of a drag on Perl maintenance that it was eventually torn out entirely. You can't say that about most features in Perl, and there are a fair few that should be removed.

[stevieb]

Personally, I don't really agree that Perl 5 requires a significant upgrade given the CPAN ecosystem.

That said, I'm not completely against it either. However, for corporates who have custom code, they can plan a perl upgrade in a cozy test environment before the upgrade to ensure everything works, and update/refactor where required before going live to production. I feel the larger problem with compatibility would be for the CPAN authors. For example, I've got 40+ distributions published, and another half of that which aren't published. If a major update to Perl broke all of them at once, particularly in non-trivial ways, that would be a significant nightmare and a very costly (time-wise) process to fix everything.

I'm sure that it would be too much bloat and slow load time if "legacy" code was left in place and used dynamically (aka the new changes could be disabled on the fly) if, say, the build systems had an option to enforce a specific maximum version of perl (eg: MAX_PERL_VER => '5.26.1'; or some flag), but I would hope that this discussion would be had if we ever see a perl binary that is completely, or even significantly different.

I've actually never thought of this to be honest; I've coded Perl since 5.6 (the codebase I was handed was actually Perl 4 code at the time) and only ever considered ensuring backwards compatibility as much as possible (90% of my distributions are 5.8 compatible, a few are 5.10), completely knowing about the mandate in perlpolicy about backwards compat. Even discussing breaching that policy raises a lot of questions that would need deep consideration by the p5p, driven by the community.

If Perl 5 does get a large changing upgrade, I'd prefer a major version bump unless serious work goes into minimizing collateral damage to the highest extent possible.

[Laurent_R]

Hi stevieb,

I certainly understand you objections. I haven't really thought about the scope of the overhaul that I would recommend (nobody really cares about my personal opinion on that anyway), but I was mainly thinking about changes that would break very old or lousy code, not code compliant with the modern Perl recommendations and commonly accepted best practices. For example: making strictures the default, forcing lexical filehandles (by default, possibly with a switch to make bareword FH possible on very old code), forcing a three argument file handle (also with a switch), include say into the core, making subroutine signatures a core feature, making some form of modern OO framework a core feature, and so on.

If carefully designed, all of these things would break only very bad or very old code, not code that has been properly maintained or that has been written in accordance with recent practices. In short, you probably wouldn't have to rewrite anything from your modules.

[Anonymous Monk]

Heh, children :)