Re: reflecting opinions more than best practice
perl -- not so much since he went on to try to create perl6. Since then it's been a bunch of curmudgeons that want to make it more obtuse and harder to learn. In addition to a recent backtrack on relaxing explicit prefix-sigils (@%) for references (that always include their type), they even added postfix sigils -- little tails you can play "pin the tail on the var" to indicate type.
perl's problem has been that most of those in charge know nothing about computer languages or computer science and have no formal training. A few do and that shows, but machine room operators don't make for good language designers.
This lack of background, but having expertise in perl shows just as it shows for C++ -- the designers
design for experts -- not new users, with ideas & projects to help and attract new users shot down as too simplistic or too DWIM'y (Do What I Mean) - one of the original design goals of perl that it's continued to drift away from. Anything that *they* wouldn't use or that deobfuscates the language is considered wrong. In addition to holes in the language that generate errors rather than provide a logical feature, they are adding more errors by taking away existing usable and useful features -- what a bonus! They don't want the language to go forward without them, so they are designing in its obsolescence. A shame really, especially since in many applications it ran 5-15 times faster than an equivalent python program -- more so if it involved parallelism.
But when it came to new designs, they believed in nuking problems rather than applying touch-up fixes. It took about 20 years to get back to a working unicode that works the same as it did 20 years back -- if they'd just fixed binary files (vs console text files). Instead they killed the whole feature and now perl's unicode has a permanently established bug where you can read in files in a local, 8-bit encoding, and they'll be written out in a multi-byte utf-8 encoding. The believed it was better to preserve this bug for posterity for ancient (20yr+) program compatibility. On one hand they'd keep the bad, but on another hand, they have no problem destroying compatibility by adding new behaviors that would be 'non-optional'. In regard to bugs: they regard them as virtues: "Historically, we've held ourselves to a far higher standard than backward-compatibility -- bugward-compatibility. Any accident of implementation or unintentional side-effect of running some bit of code has been considered to be a feature of the language to be defended with the same zeal as any other feature or functionality -- thus bugs have been cemented into the language with the effect of crippling growth.
Biting the hand that feeds IT
