Very good, actually. But you have to nudge them slightly. Tell them you prefer the modern version of the language, with gradual typing† and function signatures, and you'll get very good results. Perl interpreter comes standard on modern OSes and due to permissive licensing and impeccable backwards compatibility you can always assume you deal with very modern versions of Perl.

I write Perl scripts that are 10-100 lines of code, and at this size Perl is a Strictly Better Bash: better syntax, some type checking, better text support, and still effortless calls to external processes: essentially you put a command with arguments in backticks, and you get it's output. Ruby can do it too, but not all systems have it. Python is another obvious choice but calling external commands in it is annoying. I also use Perl for some one-liners as a better `sed` for text replacements.

† Perl nowadays have TypeScript-style type checking for function parameters. So, while the syntax is wild sometimes, the language is much better than it used to be.

▲ hrmtst93837 2 days ago | parent | next [-]

Assuming every OS ships new Perl is a good way to lose a bet, since RHEL and CentOS are happy to hand you a system package from years ago.

All the gradual typing and signatures in the world do not matter when the interpreter on the target box is old enough to miss half of it, and then you are dragging in CPAN modules or juggling shebangs just to get the same script to run everywhere. Bash at least advertises its limits. Perl can look like a nicer shell tool right up until deployment turns into a version scavenger hunt.

	▲	downsplat 2 days ago \| parent [-]
		What kind of context has you deploying into old systems that don't ship a recent perl? If that is a legacy requirement for whatever reason, then at least I'd use docker or podman to get a recent runtime. Or would you also write Python 2 or Php 7?

▲ downsplat 2 days ago | parent | prev | next [-]

What are you using for parameter type checking? I switched to native function signatures, native try/catch and might look into the new class system soon, but I don't recall native type checking...

▲ bmn__ 16 hours ago | parent | prev | next [-]

> Perl nowadays have TypeScript-style type checking for function parameters.

I can't believe that.

TS code, compile time error "TS2345: Argument of type 'null' is not assignable to parameter of type 'number'."

    function foo(x: number): void {};
    foo(null);

Perl code:

    use Kavorka qw(fun);
    use Types::Standard qw(Num);
    fun foo(Num $x) {}
    foo(undef);

This code passes CHECK (perl -c), but should not if you are correct.

I invite you to prove the claim. Rewrite this with any module you like.

	▲	rurban 3 hours ago \| parent [-]
		Because perl5 Types::Standard went the broken python way of type hints. cperl types worked, and actually made it faster.

▲ throwaway27448 2 days ago | parent | prev [-]

Are you talking about perl 5 or perl 6?

▲

jasonjayr 2 days ago | parent | next [-]

A few years ago; perl 6 renamed itself to 'raku', so the perl 5 folks can continue to improve/maintain the original 'perl'.

▲

topspin 2 days ago | parent | prev [-]

5 has this. There are modules that get you to function signatures and type constraints. It's all opt-in and, as was said, you have to nudge LLMs to use it, but they can and the results are indeed better.

▲

tasty_freeze a day ago | parent [-]

What kind of performance impact does it have? Obviously it depends on the specific program, but let's say the worst case scenario, something like a recursive implementation of the factorial function.

	▲	topspin 16 hours ago \| parent [-]
		> What kind of performance impact does it have? Minor. Faster unpacking of @_, but it's not a huge win until you have a lot of arguments. The conventional Perl 5 interpreter has no JIT to leverage the benefits of stronger types, inline functions, unroll loops, etc. A factorial function has few arguments, so the unpack gain will be small to nothing.