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
In reply to Re^5: RFC: feature proposal re code in @INC
by Anonymous Monk
in thread RFC: feature proposal re code in @INC
by blazar
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |