It's a simple tool with no dependencies besides perl (which will be around forever) and no cybersecurity footprint. Even if it were to be abandoned for a decade it would still work fine and serve a purpose. There also exists no better alternative for symlink-farm style management.
Perl is like the language of a sophisticated lost civilisation, its arcane incantations frightening to the current generation. But the achievements of that civilisation are unmistakable.
I used to do quite a bit of Perl, and occasionally have need to run scripts which are 10, 15 years old -- I can't remember a case where one of those didn't work. A two-month old Python script, that's 50/50
At least Perl encourages a culture of documentation.
Getting flashbacks to my job developing Python where I had to learn data structures by literally pausing them in the debugger after starting a big sync job.
No docs, and no pointers as to what is in the dictionary or why... but I'd better close those damn tickets or it's awkward Zoom call time!
Perl scripts are surprisingly resilient. I have seen Python modules only a handful years old turning to garbage, and unmaintained Perl modules still working fine after > 20 years.
Resilient, but also infamous for being hard to modify. Our security team has a massive set of automation written in Perl, and it's slowly being replaced, not because it fails, but because the original author left; and when we need to modify it, it's generally easier to rewrite in another language than figure out what it's doing.
Also, you need to manually install all the dependencies on your system before you can use it (whereas "go build" will just go get everything for you); and there are no test cases (whereas "go test" makes it natural to write unit tests as you're developing it, and keep those after whatever feature you're working on is complete). Rust is the same of course. All that adds up to, "More useful to rewrite than to modify".
Perl is not forcing any particular style. If you don't care about maintainability you can quickly hack code which will solve the problem but will be hard to understand/update. If you do you can use tools like Perl::Critic to enforce a certain style. And lack of documentation and comments (which makes maintenance harder) IMHO not language specific problem at all.
> and there are no test cases
Modules on CPAN had tests back when open-source libraries in other languages didn't have any. It's not hard to write tests for Perl code but if you don't have time to write them or it is not a priority it's unfair to blame the language.
Is there a way to hand cpan a perl executable, and have it automatically download all the appropriate dependencies?
So far for me it's worked like "Run command -> get failure -> search on CPAN, install -> repeat 4-5x".
For golang it works like "go install <url> -> run command".
EDIT: And to compile something on my macbook and put it on a shared Linux box for other people on the team to use, it's "GOOS=linux go build -o $BNAME_linux && scp $BNAME_linux user@host:bin/$BNAME", done and dusted.
Look, perl was an amazing thing for its day. As you say, they pioneered new language ecosystem features. But that was all in the 90's and early 2000's; since then other systems have built on that and pioneered even better ecosystem features, so that moving back to perl is a big step backwards.
1. A fashionable language (e. g. Rust) make it easier to attract new developers, some may contribute just to learn the language. Perl is as unfashionable as it gets for a language still in active use. But if the project don't need a lot of changes / new features it should not matter.
- written in perl
- 1 maintainer
- not much activity on GH or mailing lists
- pivot from initial purpose as “symlink farm” to dot file management
It’s had a nice run but seems much better alternatives exist now (as mentioned in comments)