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

The point I'm making is that you don't know until run-time what functions are ultimately called, or what code will be executed. That's what you need to know to find out if the code is doing what is wanted, and it's completely unclear from those examples what lines of code will be executed.

You know the how: the scaffolding that will set up the coderefs and the eval.

You don't know the what: the important details about what coderef will be executed, which string will be evaled, nor what that code will really *do*. And that can be hard to find out. Tied variables mean that any statement involving variables could do absolutely anything unless I go back to the variable definition (often thousands of lines away), and find out if it's tied, and what it's tied to. Coderefs mean I don't get to know the name of the function being called. Evals mean that the code to be run can be hidden in a string built up entirely at run time.

Maybe I'm just old fashioned, but I'd rather just see simple function calls with a few simple if statements. If I at least had that, I'd at least have the call tree as a framework for debugging: as it is, any function of in one of many, many modules might be called; none of the functions might be called (all dead code, with live code invented at runtime), and it will take a lot of investigation to find out the truth. At least with a call stack, I can just walk down the stack to find out what does what to what, and start making my guesses as to why.

And, you're right; you also don't know why the code does what it does, nor if it is correct behaviour. That's an additional concern, and a serious one; but not knowing what the code does in the first place makes trying to analyze for correctness hard.

*shrug* I don't know if I've made my point clearer, but at least I tried.

--
Ytrew