Re^5: RFC: feature proposal re code in @INC

[Anonymous Monk]

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

[chromatic]

A simpler, cleaner language requires that the malicious programmer work harder to accomplish the same obfuscations in the same amount of time...

Oh, please!

Have you truly never seen a program with incomprehensible variable names, entangled control flow, and no particular subdivision into separate functional units? Heck, I could write terrible awful nearly obfuscated code in both Pascal and Scheme by ignoring what hard-earned experience has taught me about writing good code.

[polettix]

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).

[diotalevi]

Have you seen Perl::Critic? It does things like this. You can make cleverness plugins for B::Lint too.

[Anonymous Monk]

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

[Roy Johnson]

I wish you had a login so I could have msg'd this to you: the spelling is "weird".