hi, i was interested if perl is still relevant in this day and age. Perl has been on the decline for a very long time now. Perl 6 (now named 'raku) not being backwards compatible with perl 5 code made the already small perl community even smaller by splitting it in half. A good example is lisp with it’s thousands of different dialects.

Is it still worth using or is it bound to legacy software forever? Like cobol.

  • @[email protected]English
    12•10 months ago

    I write Perl at work. Supporting an actively developed Perl based application.

    It’s honestly not that bad as a language, the biggest downside is that the ecosystem of libraries around it are often abandoned or outdated. The language isn’t perfect and it needs a bit of discipline to avoid creating unreadable code, but honestly it’s not as bad as its reputation might have you believe.

    It has quite a few tricks and unexpected bits of flexibility that make it quite a bit more expressive than other languages - you can really craft nice compact, elegant code with it if you want to.

    These days I use other languages too (Python, Ruby, JS, etc) but none of them quite match Perl for expressiveness.

    Oh also it’s great for oneliners. That expressiveness can be abused for brevity in some really interesting ways.

    • @[email protected]English
      4•10 months ago

      unexpected bits of flexibility

      The worst one I stumbled across while reading a colleagues script was the three separate namespaces for symbols of type scalar, array, and hash.

      • @[email protected]English
        1•10 months ago

        You mean the fact that you can have a hash called %foo, an array called @foo and a scalar called $foo all at the same time? I agree that’s a weird choice and there’s potential for insanity there, but it’s pretty easy to just not do that…

        20+ years of Perl experience and while Perl has a load of idiosyncrasies that make it harder to work with than other languages, I don’t think that particular one has ever caused a significant problem.

        • @[email protected]English
          1•10 months ago

          You mean the fact that you can have a hash called %foo, an array called @foo and a scalar called $foo all at the same time?

          Yes, exactly. Those definitions aren’t clashing, so they must have separate namespaces.

          it’s pretty easy to just not do that…

          I wouldn’t do that either, but my colleage apparently did. So far I’m having a harder time reading perl than writing it.

          • @[email protected]English
            1•10 months ago

            The way it works is that there’s a symbol table entry for “foo” which has a slot for a hash, scalar, array, glob, etc.

            That leads to some super weird behaviour like, for example, if I declare a scalar, hash and array as “x”:

            $x = "sy";
%x = (foo => "mb");
@x = ("ol", "s!");

            You can access them all independently as you’re aware:

            say "x: ", $x, $x{foo}, @x; # Outputs:  x: symbols!

            But what’s really going to bake your noodle is I can assign the “x” symbol to something else like this:

            *z = *x;

            …and then the same thing works with z:

            say "z: ", $z, $z{foo}, @z; # Outputs:  z: symbols!

            Oneliner if you want to try it:

            perl -E '$x = "sy"; %x = (foo => "mb"); @x = ("ol", "s!"); say "x: ", $x, $x{foo}, @x; *z = *x; say "z: ", $z, $z{foo}, @z;'

            Congratulations! You now know more about one of Perl’s really weird internals than I’d wager most Perl programmers (I have literally never used any of the above for anything actually productive!)

      • @[email protected]English
        3•10 months ago

        Nope. But I know a bunch of people that do or have, and have interviewed several (it’s a pretty small sector!)