1. 12

  2. 12

    As we can see the pool of people willing to work on Perl projects is shrinking fast.

    This may be true, but it’s a bit of a stretch to say that “we can see” anything based on what appears to be a made up graph.

    1. 5

      Yeah, I’m not so sure that the number of people able and willing to work with Perl is that close to 0. I know a number of people under 35 who have worked with it (including myself, although I’m pretty close to turning 35 😅)

      1. 5

        Sounds like author is living in their own bubble ;) I work for two different Perl companies and hardly anyone is over the age of 35.

        1. 5

          I agree. Perl consultants and distributors have told me that if anything, the Perl mindshare is growing. People are rediscovering it, and using it for new projects because it is ubiquitous, mature, and way more capable today than it was 20 years ago.

          Sure, other languages might grow faster, but what’s getting smaller is a slice of the ever-increasing pie of developers, so it’s still increasing in absolute numbers.

          1. 3

            In the company I work in, there is significant number of perl scripts that are powering the infrastructure which is used every day, plus some people are using perl to write new scripts (for one-time jobs, after few months those scripts will be tossed out).

        2. 2

          That graph was made up, but this one isn’t:


          And I just looked on indeed, and saw 1932 Perl jobs (“perl developer”), 2679 ruby jobs (“ruby developer”), and 15867 python jobs (“python developer”).

        3. 10

          I believe that graph is wrong. I believe the number of people capable and willing to work on Perl hasn’t decreased all that much. I think the percentage of developers interested in doing Perl for mediocre wages is decreasing.

          As my old CTO used to say, nothing really dies in tech, we just add more.

          TIMTOWTDI for life!

          1. 5

            The same argument can be made of every language which comes into and then goes out of fashion. And every platform.

            Light maintenance of code is easier than a rewrite, so you can keep going for a while. If you don’t know perl, the rewrite to another language isn’t going to get any harder over time, so why do it now?

            1. 4

              It’s too late for Perl projects to move to anything else, as people that use Perl and $theLatestCoolLanguage are hard to find. It’s a lost cause. But for projects that use Ruby, PHP or Python it’s still possible to rewrite them in JavaScript, Go or Rust.

              1. 1

                Wouldn’t the choice of Rust preclude a lot of older architectures where Rust isn’t supported?

                1. 2

                  If you’re porting from perl? Not especially; the list of things LLVM won’t target but perl will must be very short (I can’t think of any).

                  Mostly the same if you’re porting from ruby, though I suspect there’s a few architectures targeted by embedded ruby that wouldn’t be covered.

                  1. 1

                    Thanks, for some reason I thought that Rust was predominantly x86, but the supported platform list belies that.

                  2. 1

                    Most certainly. But nowadays we care only about the latest languages and the latest architectures.

              2. 4

                As an amateur Perl hacker, the future of Perl-as-COBOL sounds awesome: Perl lives forever, and my skills are in high financial demand? Sign me up!

                Seriously though, this piece reeks of concern trolling. It assumes a mature open-source project that uses Perl as part of it (like OpenBSD) will be avoided by new contributors to whom the very sound of “Perl” is a giant turn-off. It is as if the entire project is tainted with the awful stench!

                Does any open-source project really want contributors who are that shallow and ignorant?

                I do agree with the need of future-proofing, but it’s a case of resource allocation. It’s concievable that if an urgent need to fix the Perl code appears, professional help can be paid for by the project, or such help be solicited as pro-bono work for the project. Which is another reason not to be rabidly anti-Perl.

                1. 1

                  All code has a lifetime, everything rots eventually. If you fail to consider that, then you shouldn’t be surprised events like your COBOL infrastructure falls apart and actual people suffer dire financial consequences.

                  I believe that it’s fundamentally irresponsible to let critical infrastructure decay - if the availability of developers for a language drops and stays below a certain point, keeping the current code as-is is wrong (unless you can prove said code is bug free). Enough rewrites should cause the documentation of business rules to be preserved outside of the actual implementation. Conversely, fewer to nil rewrites will end up with hidden/subtle business logic embedded in the implementation and nowhere else.

                  Does this mean that most code has to be rewritten periodically? Yes. And that’s not as bad of a problem than maintaining an indecipherable stack and praying nothing goes wrong. The former is expensive if not budgeted for ahead of time, the latter can be business ending (and possibly life ending).

                  1. 1

                    This title grabbed my attention because in Navy Intel parlance, “Perlings” are Persian linguists. This article is not about that.