Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer

Re: What's the perl5's future?

by Old_Gray_Bear (Bishop)
on Oct 11, 2015 at 19:51 UTC ( #1144445=note: print w/replies, xml ) Need Help??

in reply to What's the perl5's future?

I have been writing and maintaining Perl code since 1994. The first thing that I worked on was a mail-handling system written in Perl4. I have written production code in both Perl4 and Perl5. I have been playing around with Perl6 for the last couple or three years, just to see what is happening in that space.

Last week I got a note from an old boss at the job I had in 1994. He is now the CIO and he has a contract to upgrade the old mail-handler system into something more modern. They run off the "if it ain't broken, don't fix it" theory; so the last time someone worked on it was when they "converted" it to Perl 5 (specifically 5.6.1) by changing the shebang and fixing the obvious errors.

That mail handler is a non-trivial system (you try parsing email address in Perl4....) that has been in service with out a major re-write for over 20 years. I expect the same kinds of life-spans for properly designed and built Perl5.xx systems. Particularly if the P5Porters continue the work of retro-fitting Perl6 concepts into the Legacy code base.

N.B.: I am actually, seriously, considering coming out of retirement for this. Redoing a Corporate E-Mail system and building it right, this time. (With a proper design, using CPAN modules as much as possible, a real test suite that exercises the entire system, modern hardware with enough RAM, disk and multiple multi-core processors, a real backup and recovery process, plus documentation for everything), is very**3 tempting.

I Go Back to Sleep, Now.


Replies are listed 'Best First'.
Re^2: What's the perl5's future?
by sundialsvc4 (Abbot) on Oct 12, 2015 at 14:08 UTC

    This kind of life-span for a mainline Perl application is actually very common ... and there are of course a lot of programmers in the market today who were not even born yet (or they were but toddlers) when the systems that they are now being asked to work on were first made.

    This, more generally, is the “legacy-code” issue, and this was the essential point of my (much-downvoted, of course) previous post.   It is not that the IT staff of the company in question is in any way clueless.   They know that the system now in-place is working, and that the company simply needs it to continue doing so ... which it will, unless someone decides to re-code the thing in Perl6 Java.   (You never correctly estimate either the cost or the true business risk of a re-write.)

    This is also why I repeatedly advocate that you should write your source-code for the future ... because it will have one (even if you don’t ... watch out for bread-trucks next time).   The business value of your work is not tied to the language that you wrote it in, and the task of converting a mission-critical system, to anything else whatsoever, is fraught with costs and risks.   Lots of programmers in the business today simply have no idea of this.   (They are not, dare I say, old enough yet.)

    Perl is not the only mainstream language today that is doing this sort of thing, of trying to radically reinvent itself under the same brand-name.   Python, PHP, and Ruby all did it, too.   Every one of them discovered that the “older, badder” versions did not disappear from service, because there was no business case to put existing business software assets at such risk, no matter how “–er” the new language-version might have been.   The contributed-software libraries which accompany all of these languages was the biggest part of the coffin-nail in that decision.

      There are some reasonable assertions here, which Old_Gray_Bear has given a very good example for. (Some of your assertions I disagree with though).

      I've been coding Perl starting sometime between 2000-2k2, and I know for fact that some of that code is still in prod, unchanged at past orgs I worked for. Other than my modules that strictly need a certain version because I've decided to use a new feature, I've never had any of my past code break due to upgrades in the perl binary.

      I want to point out here though that Perl6 is not an upgrade or a hack/feature-set to Perl5. It is a new language, where some of the benefits are ported to Perl5 so we can benefit. Going to P6 from P5 is akin to going from P5 to Python (or equivalent). We just thankfully get to share some of the same syntax/sigils etc

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1144445]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (2)
As of 2021-09-19 09:04 GMT
Find Nodes?
    Voting Booth?

    No recent polls found