But these are things that can usually be spotted very quickly. Which leads to the second part of the OP hope: "At some point, they do get fired...".
In my understanding, what is really scaring the OP is that someone can write apparently innocent code and make a mess that's hard to spot. Probably, some kind of code analysers (or some "flagging" feature inside perl itself, with the lower "p", who knows?) could help to spot if some program uses these "gray" features, and a company could enforce that these should not be used.
Something along these lines (but I really don't know if it's doable) would allow a company decide the "level of cleverness" allowed, while letting the whole Perl community benefit from Perl's un-orthogonality (which I truly love).
Flavio
perl -ple'$_=reverse' <<<ti.xittelop@oivalf
Don't fool yourself.
| [reply] |
| [reply] |
What do you think I'm debugging half the time? The first program I looked at when I got here was 6,000 lines of ugliness with strictures turned off (everything was a global), with a 3,000 line loop; and that's before the modules got involved! Another program was 8,000 lines long,inconsistently indented, with mostly 2 column indents, and at least 8 levels of indentation in places. I had to gamble on perltidy to clean that one up enough that I could read it.:-( And don't get me started on the 100,000 line monstrosity that's so ugly and obfuscated that we have no clue how to refactor it, and no time or mandate to do that work. So yeah, I have seen that kind of ugly code, and for the most part, if it's vanilla ugliness, I can deal.
It's the extra cleverness on top of all that bad practice is what's killing me. There's only so much I can handle at once.
I can break programs into functional units. I can rename variables. I can detangle control flow with some difficulty. I can refactor chunks and figure out what they do, and even tie them back to the (mostly fogotten) business logic in some cases.
But when I have to examine each and every variable to see if it's tied to something stupid -- that's a perl feature I'd just as soon live without.
When it's hard to clean up whitespace and know it's reformatted correctly -- that's a limitation of the language I could do without. I want those kinds of tools, and I want them to be reliable!
Now I have to scan @INC each time, to see if something wierd is being done to the normal process of loading modules, something that is already error prone enough.
It's not just one thing; it's a whole bunch of straws that add up to a crushed camel handler. All the things to check for add up; I can't read variable assignments without checking for ties, I can't read function calls without checking for parameters being modified, I can't read anything without having to be suspicious of everything, and there's so much that's possible in perl! And every possible avenue is a chance for something to go horribly wrong.
Perl started out as a big, inconsistent language. It's been getting bigger all the time -- the rules for what some idiot can do to screw you up change with each major release of perl. It's hard dealing with all the wierd corner cases, trying to guess what strange side effects might be snuck in with an innocent looking line of code. I just get tired (and whiny, I guess) when someone adds yet another feature to the language that I have to learn just so I can track all the abuses of it.
You know, I'll probably never use that wierd @INC trick; but I still need to know it to stop others from abusing it. Which is what prompted this rant; the more people add to perl, the more work I have to do. Which makes me grumpy.
--
Ytrew
| [reply] |
| [reply] |
Thanks for the correction: I hate it when I spell things wrong (which I do all too often!).
--
Ytrew
| [reply] |