Perl 5 backward compatibility is not only for DarkPAN

| 5 Comments | No TrackBacks

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.

No TrackBacks

TrackBack URL: http://daniel.ruoso.com/cgi-bin/mt/mt-tb.cgi/152

5 Comments

I don't like the idea of having to specify the version to use new features. New features should be enabled by default. Otherwise we just end up with more boilerplate code at the top of every perl file.

Instead I think we should provide optional pragmas that can turn off defaults. So if you upgrade to a newer version of Perl that has strict enabled by default and it breaks your stuff you can then choose to disable strict and not have to go through the hassle of fixing all your code. Having to annotate a few files to stay in the past is a small price to pay for the free updates, and your legacy code doesn't burden the rest of the Perl world who wants the language to move forward.

Longevity? Sysadmins upgrading on whims without discussing implications
with other departments?

Two problems with your problems: If you want true longevity, use a dead
language that will never change (FORTRAN, some ALGOL flavor, etc). No
modern language is exempt from change. C#? Let's see, over ten years,
there have been a handful of version increases, including a change to
the core runtime. You don't see businesses scrambling to get away from
it do you?

Second, if you have sysadmins upgrading your production systems without
discussing the implications with the users of said systems, that is an
organizational problem that has nothing to do with Perl.

To sum up: We should never change Perl the language or perl the
interpreter because your organization doesn't have the discipline
control sysadmins, and because of that, managers will change to
something else (even though nothing else delivers perpetual twilight
short of dead languages)?

Honestly, your fear of change is unwarranted. No one is wanting
malicious changes that break everything. And those that do want those
kinds of changes are off working on Perl 6 anyhow.

1) Write your own modules to simplify work with XML, SOAP and XMPP to avoid such problems, share it and maintain. How much time will it take? How often will you break compatibility?

2) More changes, often releases give you advantage of new features and if you have perfectly correct code that doesn't work then you can expect release with fix sooner than later.

The question is would your problem with the upgrade be an argument to froze XML::Compile in some version?

Michael: I agree with you in principle that it would be better to turn new features on by default and provide a pragma to turn them off, but that's not a usable, practical solution without a means of putting that pragma into the older perls which give people the desire to turn them off it in the first place. e.g., 5.10 has "no feature" to turn things off, but trying to run code containing "no feature" under 5.8 just gets you a "feature.pm not found in @INC" and a non-running program. (Granted, this can be fixed with a dummy feature.pm, but having to install something extra solely to *not* get new features seems wrong to me.)

Leave a comment

About this Entry

This page contains a single entry by Daniel Ruoso published on July 1, 2009 1:09 PM.

Perl 6 - The quest for the holy grail was the previous entry in this blog.

How do we get out of this mess? is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.