--- Tels <[EMAIL PROTECTED]> wrote: > There is a time when you have to abandon old stuff and just use the modern > thing. I would be curious what the reason for v5.6 are - and if not most of > them are of the "we are to lazy to upgrade", "we don't want to", "it always > worked" etc :)
Well, since you asked: There are several reasons why the upgrade from 5.6 to 5.8 hasn't happened yet. First, the team that I am working on has a quarter million lines of Perl code, and that's not counting the template layer. Given that there are many different teams, you can get an idea of the scale of software that we routinely work with. Ignoring the other teams for the moment, here are some of the problems that I personally ran into when trying to upgrade our software to 58. Please note that I am not attempting to justify *anything* that I am about to write. I am merely describing the state of the software as I found it when I started working here. 1. Many CPAN modules do not quite fit our requirements, so we have to subclass them or fork the code. There are very few CPAN modules that we have not done this to in one way or the other. When we upgraded to 58, many of those broke outright because they had been so radically altered. (In large part, this was often done because we used early versions of modules written years ago. We needed features that people hadn't even thought of back then.) 2. Hash ordering is now guaranteed to be random (unless you specify different compile time options to Perl, something I chose not to do). Many of our tests assume that hash order is deterministic -- which it appeared to be prior to 58 (remember, "not guaranteed to return in a particular order" is not the same as "non-deterministic"). I had to rewrite much of our test suite (which takes around two hours to run!) to find and fix all of these. 3. Extensive use of pseudo-hashes. 4. Internally, some source filters are used which automatically built prototypes for subs. They work well, but caused many strange problems. 5. Localizing tied arrays and hashes is broken in 5.8. We tie and localize %ENV. 6. Because of sloppy programming, many tests emitted warnings and a few failed intermittently. Given that I had to *guarantee* that none of those problems were caused by 58 and the test suite takes forever to run, I had to do this repeatedly to catch all intermittant failures and trap all warnings. This was a huge amount of programming time. 7. Of course, 58 is not binary compatible with 56, meaning many modules must be recompiled. This introduced plenty of other problems (don't even get me started about the module that now relies on Apache internals and thus cannot be used or required except in a mod_perl environment!!!) That list is not comprehensive, but it gives you an idea of what I faced. Here's the kicker: I've seen a lot of production Perl code and while you might cringe at some of the things I described, this is, hands down, the best production Perl I've had the joy to work with. Any shop that has a code base anywhere close to the size of ours could very well have a hell of a lot more work to do than I did. Further, given that larger code bases usually have more customer requests, upgrading to 58 might seem like a low-priority when a customer is dangling a hundred thousand dollars in front of you. Frankly, I was surprised I had support for the project. If I was not a new programmer who they were struggling to figure out what to do with, I probably would *not* have gotten approval. As it stands, I did the upgrade months ago and we're still waiting to install it. Cheers, Ovid ===== Silence is Evil http://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
