And yet ... there is also another rather-unique but critically important issue with regards to computer programming languages:   legacy.

There are tens of thousands of systems out there, comprising millions of lines of source-code, which are written in Perl this-or-that and which are in service right now.   They’re doing their job, moving the freight, paying the bills.   Although we quite-naturally might look upon the old and yearn for the new, it is quite often the case that the business need is being served quite well by the existing system and so that the number-one concern is to keep it running smoothly ... earning revenue.   It ain’t broke, etc.

Hence, it might be argued that Perl’s “business plan” is that it continue, for many decades to come, to continue providing the mission-critical service with which it is now tasked and which it is now doing ... while also evolving in appropriate new ways, but recognizing that the old ways will never be superseded by the new.

“Never be superseded?”   “But what about Perl n+1?”   No, it will never replace the Perl-5 legacy, and when a successor actually comes out of the academic labs, if it ever actually does so (which I personally doubt by now), it will be regarded as an entirely new language in the field and it will have to earn its keep all over again.   As will each-and-every other language in the field at that time.   A programming language tool is always a means to an end, never an end unto itself.

Frankly, I think that it is much more likely that the language will one day be eclipsed.   That’s usually what happens:   the language remains as good as it ever was, but the demand shifts as new and more-efficient ways are found to do the same thing.   I shut down my Perl-based million-line customer relationship management system only when I outsourced that business function to Salesforce.com and then went through a staff-reduction.   (buh-bye!)   And so on.   It was, and is, a fantastic canal-boat but now we ship by railroad.