Hacker News Reader

Comment by postepowanieadm | Hacker News Reader

I'm too scared to check how good llms are in writing perl.

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.

Are you talking about perl 5 or perl 6?

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.

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.

> 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.

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

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...

> 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.

Because perl5 Types::Standard went the broken python way of type hints.

cperl types worked, and actually made it faster.

Codex for some reason sometimes runs Perl instead of Python to work with local files

Reply on news.ycombinator.com