I fall firmly into the "Why are you doing it that way?" camp. In my experience, both as a questioner and an answerer, is that most people don't know why they're asking a given question. Case in point - all the HTML/CGI homework questions we get in May and December.

• "I need to get data from an Excel spreadsheet into a form that allows the user to choose which FOO to get the BAR info about."
• "How do I modify the variable named in another variable?"

And so on and so forth.

Programming (and life, for that matter) is about thinking. It's about knowing what question to ask. Charlie Brown once quoted someone I don't know, saying "The more I learn, the more I know how much I don't know." I take that to mean "The more I learn, the more I discover what is knowable."

Douglas Adams puts it another way. In his Hitchiker's Guide series, he describes a civilization that took 100 generations to build a machine that gave them the answer to the Ultimate Question. It then took them 1000 generations to build the machine that gave them the question for the Ultimate Answer. (The second machine was the Earth, but that's another story, better told by the white mice.)

My rationale for being in the Question-Further camp is this - I'd prefer to teach you how to fish than give you a fishstick. Most answers need context. (Which, coincedentally, is how all education works - by expanding context. You need to be able to hook in what you're learning to what you already know. That's why geometry is taught before limits is taught before calculus. You can't hook calculus onto anything without limits, and on down to geometry. It's also why Peano's Postulates aren't taught until college. Even though it's just about the whole numbers, you can't understand them without a concept of spaces.)

If you ask about modifying a variable named in another variable, I'm going to explain what the heck it is you're really asking about. I'm going to point you in the direction of basic knowledge (hashes). I'm going to point you in the direction of structured programming (which it seems most Perl coders have a serious aversion to, kinda like bathing for Magic players). I'm going to attempt to tutor you and educate you. After all of that, if you still want to know how, you'll already know. I mean, if symbolic references were all bad, then why would Perl allow them? Why would many of the modules we use every day use them? Why would people like me write code that's used in production that makes use of them?