> What's the point of programming in a language that has 100 ways to do something, and then banning all but 99 of them?
Two points in this. You might not want to ban all 99 in all cases. For example, you may want to do things one way in one aspect of a project and a different way in a different aspect.
This sounds dangerous (and power is dangerous), but done right it allows teams to focus on doing things right with the right interfaces between them.
For example, it's one thing to contribute to Moo, Moose, and PGObject in one way, but have a different coding convention internally for the programs which use these libraries. This is where those other 99 ways really come to be powerful.
> Why would you use a language if you don't agree that the designers did a good job?
I like the design of Perl 5. However, it took a lot to get to the point where I saw the beauty in it, and saw how to use the power properly.
In a larger project however, that's not so much of a problem. Once you get the core code started, people can grow within it. Different levels of the project may handle things differently, and that's fine. People can branch out over time.
> I've never seen a project that could enforce its coding standards in every case.
And sometimes the responsible decision is to let the coding standards violation occur and plan to fix it later. There are times I have done that and regretted it, only to later realize it was a net positive anyway.
> Maybe we should let the machines do the machines' job, and the humans do the humans' job.
Absolutely. Now to tell which is which.
> Perl has all the problems of an old language.
Evidently every 5 years or so we need to all jump on the bandwagon to a new language?
> No commonly-agreed on coding style (you'll get flamed to a crisp in some parts for even talking about Modern Perl), no single object framework (Moose, Class::Accessor, Object::Tiny, Role::Tiny, and plain old "inside out object."
There are lots of object structures but you probably shouldn't list Role::Tiny there. The basic point there is you have Moose, of which Mouse was an attempt to make it smaller for performance sensitive applications (now largely superceded by Moo). Role::Tiny is an attempt at a minimalist piece of Moose aimed at specific applications. Moo/Moose/Role::Tiny are best thought of as aspects of a single object system rather than separate ones. In fact Moo and Role::Tiny were authored by the same individual.
The Perl world has largely gone to Moose and friends. Pretty much everyone that uses anything else does so for legacy reasons or external constraints IME.
> References are confusing and unnecessary (neither Python nor Ruby needed to make an artifical distinction between references and non-references).
And yet I have been bitten by the lack of such a distinction in Python.
> All the various different ways that things can fail at runtime are a huge burden, especially when you combine them with the different modes that perl itself can be run in, like "use strict" versus not.
Meh, my test cases in any language use up more code than my production code anyway. There is no substitute for clear code contracts.