|laziness, impatience, and hubris|
JanneVee, with all due respect, I disagree. I have had to deal with extremely obfuscated COBOL. One company (that shall remain nameless) that supplied us with software had deliberately written the system so that copybooks contained copybooks that contained still further copybooks. Imagine trying to find a variable that was cryptically named WS-FLT-DATA (for example) that was buried several copybooks deep and then trying to figure out what it did. Hoo boy! One of their programmers privately admitted to us that this was done to guarantee that they had the support contract (though I will confess that their company gave great support).
And then there was the program where the programmer cleverly named all of his variable after types of alcohol and had statements like
I would have given anything to get my hands around that programmer's neck.
The point is not whether or not a language can be obfuscated (I think C is obfuscated simply by its existence), but the development time. COBOL is, generally, easy to maintain, but the development time is horrendous.
Let's take a vote: how many Monks who have experience with both COBOL and Perl feel that there is anything they can develop faster in COBOL?
Another point: Yes, Perl code can be obfuscated and has a steep learning curve (compared to COBOL). But consider the example that I pointed out in COBOL vs. Perl: 80 lines (after optimization, no less!) of COBOL code compared to 10 lines of Perl. Unless someone is deliberately obfuscating the Perl, 10 lines is one heck of a lot easier to debug and maintain than 80.
I went on longer, but it cut me off. The prosecution rests. :)