Re: What's wrong with Perl. The writer also is apparently struggling with some key concepts, as in, "I tried using references, but never made it work.". His discussion of lists within lists furthers that point: in his final solution for lists within lists (@b=([(0.8,0.9,1)],2,3,4);,[(...)] is redundant. [...] would suffice. The writer's problems with regards to lists of lists appears to come from mixing up the Perl and Lisp meaning of (...)
One Perlish idea that works is context sensitivity. It is tricky to learn properly, but, once learned, it allows for quick and expressive programming. I think it works because context-sensitivity fits nicely into the way our brains process natural language.
One Perlish idea that doesn't work (just my opinion) is the approach to variable scoping. Variables don't come naturally. They are something most of us have to learn to work with. The analytical training of an 8th or 9th grade algebra class is less about quadratic equations (which most people forget) and more about learning how to deal mentally with missing information and symbols that represent a bounded but as yet unknown range of values. Natural language is just not much help here. The closest analog we have is the pronoun.
When we can't rely on natural langauge, we rely on past technical training. For 20+ years I was able to get by on a single mental model of scoping. This model said the names and addresses of variables in an inner block (or lower on the stack) hide the names of variables in outer blocks. If I made a closure it used whatever version of the variable happened to be in play in the scope where the closure was generated. Somewhere in the back of my mind I knew that there were several strategies languages used to create this effect, but I could ignore it and treat it as an implementation detail for the curious.
Not so in Perl. As was made amply clear in this thread, you simply cannot understand the behavior of variables inside closures without understanding that Perl has two different mechanisms for scoping variables. In Perl the implementation details matter. I have yet to be convinced that having to know such implementation details should matter. So far (for me) this feature of Perl has been primarily the source of curious bugs. I might be convinced if someone could show me that such complexity allows me to make a higher level task easier to implement, but that hasn't happened yet.
<code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>