Daniel Ruoso

The Perl vs DarkPAN issue is evolving a lot these days, I'd like to explore a viable option so we get out of this mess.

Let me just review which are the options that are clearly not acceptable by one side or the other:

• Have the defaults for Perl 5 changed, in a backward-incompatible way, favoring Modern Perl
• Enforce backward-compatibility in order to preserve the huge amount of software running in Perl around the world.

It seems pretty clear that going to each extreme will not build any consensus, so, I was thinking about the way "perl -E" works on 5.10, and I was wondering if we could do one of:

• Have the defaults changed, but with a switch that would enable "backward-compatible mode"
• Have the defaults kept, but with a switch that would enable "modern-perl mode"

Basically, what I'm proposing is that we assume that there are two Perls in perl, and by a switch you can select the one you're going to work with. Even if the "modern-perl mode" is assumed to be default, simply adding a switch to the invocation of the interpreter in the old systems wouldn't be much hard.

NPEREZ has written that we shouldn't care about the DarkPAN, Both AdamK and SF had argued about it, but I'd like to take it to another perspective.

One of the key strengths of both Perl and perl, has been the way old code is still supported in the language. That is a decisive aspect as when to choose a language to invest a lot of time, and by that, money. I'll take an example that is not part of the DarkPAN and that has been, just last week, released as free software.

About a year ago, I started working in a software, and of course, I chose to write it in Perl. More than that, I have also made some interesting choices, that including the use of SOAP over XMPP to design the choreographies of the application, as well as the use of Catalyst to implement that. That led me to write some new CPAN modules. Basically I was using XML::Compile, XML::Compile::Schema and XML::Compile::SOAP as the foundation to the entire application.

As the software evolved, a new major release of the XML::Compile framework was released, and it mostly changed the API and a lot of default behaviors. This change costed me about 3 months in investigation and patches, both to my code, to XML::Compile's code and to some other modules just to have the code working again.

Imagine what happens if the defaults for the core changes? That would represent an incredibly higher number of issues to be dealt with, and we don't actually have a choice of "sticking with the old perl", because the developers usually are not the sysadmins, and having to convince a sysadmin that you need to install an old, unsupported version of a CPAN module is already bad, imagine having to convince a sysadmin to install an old, unsupported version of perl? and by that it would mean to keep an entire module tree specific for that version?

That would certainly be a reason for a manager to decide to switch over from Perl to something else, and a very good one. In fact, one of the key strengths of Perl is precisely the long backward compatibilty. And that is not only important only to the DarkPAN, but for every single piece of legacy code in the free software ecossystem as well.