Surprisingly that never happened, and we already have over 100 plugins. :)

Btw. Devel::Nextalyzer is a great tool to visualize multiple inheritance (and in turn prevent collisions).

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

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

But then that would not be Perl. It would be a subset of Perl almost certainly guaranteed not to make use of its expressive power.

A technical writer doesn't set out to make use of all the "expressive power" of the English language; (s)he seeks clarity and aims to be understood by his/her target audience. So, too, a programmer should aim for clarity, and only write what will be understood. In both cases, using simple language wherever possible is going to make life easier for the person trying to understand later on.

Now your claims fundamentally amount to the belief that there's an implication between feature-richness and tendency to write "bad" code. Of course such a cause-effect relationship does exist, but although it is difficult to quantify this kind of things, my judgment, and the common perception here, are that it is of a much much smaller entity than you seem to think.

I can only speak for my own experiences; but they've been almost uniformly bad. It's not just that feature-richness provides a tendancy to write bad code; it's the general fact that giving someone more than they need becomes awkward. Look at the tendancy for long cords to become tangled; it's the same principle with coding -- more is not better. In both cases, the snarls and tangles don't have to happen: but they do happen on a regular basis.

Actually, in my experience, bad code I had to deal with was not bad because of the (ab)use of "advanced" features. It was bad because of "basic" shortcomings, e.g. no use of strict and warnings, unchecked opens and so on.

Those are very annoying problems to solve; but not hard ones. Depending on the needs of the program, you might, for example, replace all uses of open() with a version with exception handling of some sort (dies, warns, throws an exception object).

The problems I'm facing deal more with the fact that the code itself tells me almost nothing about what the code does; it's all run time decisions that are hidden by as many layers of abstraction as possible. Checks for things that can't happen are layered in with things that can and must be checked; and the run time state has become a total maze of objects, global flags, internal stacks, and code hidden in code references and closures.

In particular "bad" code -in my acceptation- indeed often features string evals, always in situations in which it is not needed by any means. And I can understand your concerns with tied, variables, although variables do not tie themselves on their own. But I still can't understand what scares you in closures. Care to give an example?

Well, closures are coderefs, and that means guessing *which* code a variable currently refers to. Add to that the burden of figuring out the scoping of the closure, and you've got much more cognitive burden than tracing a simple function call. Unless there's no reasonable way around it, I much prefer the simple and obvious solution.

And of course, all of my complaints are interrelated. It's not just closures in and of themselves; it not just the ties, it's not even just the evals (though they really suck!). It's the fact that I'm dealing with codrefs (and occasionally closures) that are generated at run-time by evals with class names being returned by objects that are determined by hash lookups to tied variables that are eventually tied to something or other using hash lookups and evals; a very simplified version of the main loop runs something like this:

while ( @list ) {
      $x = shift(@list);
      ($a,$b) = @$x;

      if ( ref($a) eq "CODE" ) {
          &$a($b); # modifies @list
      } else {
           $a->$b; # $a may be a class or an object;
                   # modifies @list 
      }
} # end of evil code that tells me nothing

As you can tell, the main section of the code does nothing other than provide some run-time scaffolding to obscure what's going on. The closures and coderefs, the object syntax, the ties, the evals: they all combine to make something hard to understand practically impossible to understand. Any one of them by themselves would be bad enough (especially eval), but together they make it all just horrible.

I'm gaining very little personal benefit from most of Perl's advanced or interesting features, because I need to write Perl that's accessible to a beginner perspective wherever practical to do so. So far, it's been practical to do so, with exactly one exception in two years.[1] On the other hand, every time there's a new feature added to perl, there's one more feature I have to remember to watch out for, just in case some idiot has (ab)used it.

--
Ytrew

[1] I once wrote a pair of redefine() and restore() functions that override and restore the definition of a function at run time. I use it to simplify testing, by doing separate unit testing of parent functions from their child functions. (ie. If the children return a given value, does the parent function correctly?).

I carefully separated the potentially confusing code out into it's own module, documented the functions and their intended purpose, and documented the codebase as well.