There's a kind of elegant flexibility to that, but it also makes it really hard to program reliably in the large, to build useful tooling, or even to glance at a function and know what you should pass it.

Beyond that, classic Perl was full of things that make it quick to write small programs (as CGI scripts were at the time) without a lot of boilerplate, but which don't scale up.

(Perl 6 is very different, and has an almost comically flexible/powerful function signature system (https://docs.perl6.org/type/Signature). Whether or not you like Perl 6's stuff, it's nothing at all like Perl 5's.)

Sorry, you are misinformed. That hasn't been true for a long time, see http://p3rl.org/Kavorka::Manual::Signatures

Other languages would kill for this kind of beyond-complete maximum overkill feature set.

> This page gives a good overview of the situation: https://perl101.org/subroutines.html

No, it doesn't. That page is not wrong, but incomplete and teaches the wrong stuff, wouldn't recommend. Instead see http://perl-tutorial.org/ for recommended tutorials.

YOU are the one misinforming, it would seem. Granted, I don't work with perl (5, never tried 6) for about 15 years, but most criticism of it seems to align with my experiences back then.

[0] http://mvp.kablamo.org/basics/functions/

Edit: The second [1] also recomends the @_ method, and the third [2] the shift method. Did you even read your own links?

[1] https://perlmaven.com/subroutines-and-functions-in-perl [2] https://learnxinyminutes.com/docs/perl/ (search for subroutines)

> WARNING: Subroutine signatures are experimental. The feature may be modified or removed in future versions of Perl.

https://metacpan.org/pod/perlsub

Which is to say: a lot of the reason they're still experimental is because Perl's commitment to backward compatibility. Other languages might have said "oh well," but Perl 5 said "oh, an unintended consequence that might break real uses in the wild; we should wait another year."

On Perl6 those are officially supported, so I imagine they work.

That is also true for the overly simple object model of Perl 5, it is more like an OOP construction kit, which enables things like Moose which has for almost 15 years provided Perl 5 with a very flexible object model.

It would be very interesting to know if anybody knows of similar systems for other languages?

Large OO codebases can be downright nasty to navigate and while I have never had the opportunity to use something like Moose for large scale projects I imagine that's where it would shine.

These days, people that aren't novices tend program much more clearly in my experience, and there's style guidelines and code linters to take up the slack. It's not like other languages never have to deal with people writing odd or unintelligible code either, there's a reason why style standards are a big thing in many places. Here's an example of a module I use that I just looked up. It's fairly terse in parts (but it's a module, so I hold it to a different standard than my own code), but I would expect anyone familiar with perl would have zero trouble determining what's going on in here, and a lot of code bases will be a little more verbose or use more white space to error on the side of caution and help people process what they are seeing easier.[1]

1: https://metacpan.org/release/Path-Tiny/source/lib/Path/Tiny....

Consider the difference between a minified JS script or one produced with emscripten and the code pre-minification. One is unintelligible guaranteed, the other … maybe haha.

Unfortunately, what tended to happen is people would write one liners, and slowly expand the one liners into more complex one liners, and then integrate them into larger scripts without refactoring. Regex can triple that problem (thankfully Perl 6 allows you to write some of the most intelligible — seriously! — regex out there).

That's like the folks who say "the problem with C (buffer overflow, UB, etc.) isn't C, it's the people who write C". Which leads to at some point contemplative folks deciding either "this is happening so often, maybe it is the language" or "the majority of people writing this language are incompetent". While I've heard plenty of people in the C community espouse the latter view, having written C since K&R days, I think most people acknowledge it's a problematic language. But I don't have empirical evidence of a ratio.

I wrote a ton of Perl <=5 back in the day. I'm pretty sure I know why I thought it was a good idea at the time. I know where I fall on the above. I know why I, and virtually everyone I know professionally, don't solve problems in Perl any more. But hey...maybe I'm just incompetent.

‘User error’ is rarely a sufficient explanation for why something negative happens, particular when those users are professionals using a professional product. At some point one needs look at whether there is something in the product that causes those errors to happen or that doesn’t do enough to prevent them.

There's nothing inherent about Perl that causes people to use $z instead of $somethingDescriptive. And regexes have for quite some time allowed for insignificant whitespace to comment things in detail.

If you comment your regexes and use decent variable names, you solve 98% of the readability problems of Perl, and both of those could be enforced with a linter. But as I said, a lot of the problems come from one liners being slowly expanded. Using single letter var names for anything is fine in a one liner, but not good for long term program legibility or maintance in any language.

However all that flexibility means that it's not possible to run static analysis with full confidence. Yes, tools exist - but it's been proven impossible for them to catch all cases, and this uncertainty carries real risks for critical business processes.

When you have a code base encompassing a set of core modules, with hundreds of auxiliary programs using them across the business, then any attempt to update perl or its modules grinds to a halt. It's impossible to even enumerate which programs will be impacted by the change with confidence, let alone the effects of such a change.

For details see "Perl Cannot Be Parsed: A Formal Proof" (https://www.perlmonks.org/?node_id=663393). You can mitigate the impact with coding style guides and code reviews but once the damage is done it's very difficult to untangle an existing code base that loads modules at run-time and makes full use of Perl's flexible nature in other ways.