watch out for"? What does that mean? The whole coderef-in-@INC thing is a tool fit for a few specific purposes. If you don't need it, just don't use it?
(ties and closures and evals, oh my!)
I don't. I usually try to write code that's clear, simple, obvious, and provably correct.
I do, however, have to maintain code written by other people. The more wierd corners the language has, the more places for them to hide bugs on me! Sure, you shouldn't hide code in @INC without a good reason, but that's no reason to assume people won't. Remember, many coders adopt worst practices for job security. Unfortunately, the messes they leave behind last years after they're gone.
The bottom line is, for every new feature you add to the language, that's just one more thing I have to check for when I'm debugging to see why someone else's program just broke. Before, I had to make sure @INC had the right module; now I have to verify that some weasly twit hasn't snuck some code in there for no good reason; and made my bugfix fail because of it!
I mentioned ties, closures, and evals not because they're bad when used wisely, but because they're miserable to deal with when badly applied. Which they are. Repeatedly and frequently badly applied. :-(
--
Ytrew | [reply] |
The more wierd corners the language has, the more places for them to hide bugs on me!
I believe you meant to say "The more complex the code my predecessor wrote, the more places he or she may have hid bugs." Otherwise, it seems as if you've subverted your argument about language features badly applied. I can easily imagine a very simple language where it's still possible to write unmaintainable code.
| [reply] |
What I worry about is that someone else may do something bizarre in their CPAN module (like putting something bizarre in @INC) which will break my code elsewhere (like code to check modules in @INC for changes under mod_perl). If all the magical things in perl could be safely ignored by people who choose not to use them, this would be less of an issue. For a real world example, see the recent problems on the Catalyst mailing list with YAML, which uses Spiffy and apparently modifies the way 'use base' works in other modules.
| [reply] |
It's possible to write unmaintainable code in any language; but it shouldn't be easy. What's more, choice of language can sometimes simplify cleanup.
Assembly language is horrible to maintain, because it's easy to make code self-modifying. I debugged self-modifying System 370 assembly language on my second co-op term; it took a day to guess what the code was trying to do, and almost a month to prove that it was doing what it should. Most of the program was dead code; but in one case, the program modified itself to reach otherwise unreachable code.
I spent those extra 29 days searching for a another way the program might reach the rest of the "unreachable" code; but it didn't actually exist. The code was just dead code; leftover and unused. 29 days wasted because of sloppy code maintence, and a performance hack!
Perl is better than Assembly; but there's still great room for improvement. Productivity tools like perltidy don't work as well as they might, because perl is just so complex, exception riddled, and inconsistant. That's a shame, because it didn't need to be like that. It's bad when you can't be sure the tool you're running to format whitespace didn't mis-parse your program and introduce new bugs. I don't know anything else about Python, but I know you can't fail to indent code and have it run in production. Language design does matter!
A simpler, cleaner language requires that the malicious programmer work harder to accomplish the same obfuscations in the same amount of time, and that's a win for me. At some point, they do get fired...
--
Ytrew
| [reply] |