It is, but difficulty in requiring diligence in such a creative environment is the reason Perl has failed for larger team development.
I was once praised for the readability of my Perl code by a junior teammeate, and immediately scolded by the best Perl programmer on the team with "yeah, because he makes it look like C code".
Don't get me wrong, I like perl, I just think its unique characteristics make it a poor choice for complex, long-term software, which is where the most money is, and thus the most people/candidates.
Reminds me of getting an answer from Tom Christiansen on stackoverflow. Most of his answers follow one of the two typical patterns:
1. an extended regex to do what you want in every encoding known to man, extended to use cases you never mentioned, taking 10+ lines to replace one character with another (with occasional angry remark about random other language where "it's impossible to do that")
2. "it doesn't work, because you're not using my standard boilerplate" - followed by 20+ line boilerplate setting a lot of different things where most of them are not even remotely related to the question... because everyone should be using his boilerplate...
My point was that majority of that answer was completely offtopic. I'm not disagreeing that it catches the mistakes - but that this reminded me of the attitude described in the post above. tchrist might be a known perl person... but this comment was confusing at best - only one line actually relates to the question - "use autodie;". You must be also full of yourself to actually write something like "If you had begun with the standard boilerplate" - where "standard boilerplate" is actually "something I use" - and expect anyone else to actually use it.
Yes answers like this can be off putting but they are steered more towards the teaching you how to fish and are often be more valuable in the long term
BTW... sorry to be pedantic but it was the use warnings and not the use autodie that caught the problem.
> Most of the second line is on the programmers shoulder.
Train-and-blame is a poor and ineffective way to ensure quality and consistency. Good engineering designs quality and consistency right into the system. It's possible, for example, to write ugly, unreadable code in Python, but the language design itself strongly pushes you toward writing elegant, readable code.
the language design itself strongly pushes you toward writing elegant, readable code.
The language design itself strongly pushes you toward indenting the way Guido indents. The rest (effective decomposition, good naming, testing, intelligent default behaviors, algorithm choice, comments and documentation) is on the programmer's shoulder, as it is in every language.
