Well, I wouldn't put ties and closures on the same level as evals, especially if you mean string-eval.

Said this, Perl's nature is intrinsically that of a polymorphic, complex, dynamic language with a rich syntax and semantic. You have to live with that! And generally Perl aficionados do like it too! Or else you may try to choose a simpler alternative. (Pssst! Don't tell anyone, but I think that io is very cool - if only I had some spare time I'd like to learn something more about it¹)

¹ Of course the fact that it has a simple, consistent syntax, and that it has no keywords doesn't automatically make you an expert programmer...

Well, I wouldn't put ties and closures on the same level as evals, especially if you mean string-eval.

They're all potentially evil. Try working with code like this. What does it do?

$x = $h { foo($y) };
$z = &$x( $a );
eval $z if ( $b );
[download]

I don't even know; and I invented this example. :-)

Note that for large hashes and complex, 1000 line functions with obscure return values, you won't really know what that code actually does; it's very hard to figure out what's going on, until runtime (and sometimes not even then -- we've got a special abstraction layer that re-implements a turing machine in software. Don't ask! And the system's too slow! Gof figure!). Welcome to my world. :-(

Note also that if $h is a tied hash, it can change the values of $a and $b. Heck, it could even change the meaning of the code to be evaluated in $z.

Perl's nature is intrinsically that of a polymorphic, complex, dynamic language with a rich syntax and semantic.

It's been growing every more complex every year for the last ten years; and I felt had too much unnecessary complexity back in 1996. Expanding the language rather than cleaning it up and simplifying the messy parts hardly seems a winning propositon to me. It feels like we've been doing a nosedive in wrong direction... and I worried that Perl 6 is mostly cool new features, without concern for how they'll be (mis)used.

You have to live with that!

Maybe, but I don't have to like it. :-( And it takes a massive amount of lobbying effort to get management to change languages, so I'm probably stuck with Perl; a fringe language like Io will need greater support (and much better documentation) before I'll be allowed to code in it/learn it.
--
Ytrew

Try working with code like this. What does it do?

It calls foo with the argument $x to get something which when stringified will give us a codref from a hash. That coderef is then called with an argument $a and is presumably expected to return a codefragment of some sort. We then eval the code frament but only if $b is true.

What it does is pretty clear. Why it is doing what its doing is not clear. But thats to be expected of a three line fragment with useless variable names.

I don't see the point you are making. Although I can see how coderefs in @INC could be a pain to debug.

---
$world=~s/war/peace/g

(ties and closures and evals, oh my!)

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

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.