Re^2: Some Insights from a Traveler Between Languages

[skyknight]

Well, here's the thing. I don't have a huge problem with different languages having similar syntactic constructs with different semantic interpretations, though I do find it irksome and perhaps even unnecessary. However, I do consider it problematic that two syntactically very similar constructs in a language have two very differerent semantic interpretations while operating on the same kind of stuff (arrays/lists). This is just a land mine waiting for someone to step on it. I like that Python skirts the issue by only having [] for working with lists, as opposed to Perl which has () on top of that.

In a language like Perl, it's not clear to me that the distinction between "array" and "array ref" is a useful one. For example, the fact that you can return a reference to a local (er, my) variable inside a function is indicative to me that Perl doesn't seem to have the concept of auto variables. Presumably the things getting placed onto the function call stack are not actual variables, but reference counting pointers. I could be wrong, as I have never looked at Perl's internal code, but given its behavior I can't imagine it working differently. As such, why do we even bother with the variable/reference distinction? What does that buy us over Python's strategy of allowing you only to store references? I think Perl's way of dealing with stuff is a legacy of C-style thinking that needlessly complicates things. Do we really need to care about the distinction between variables and references? We don't even have guarantees about when garbage collection occurs, so what's the point?

Also, you're totally confusing the issue with point four. Perl could survive just fine if the scenario I described were a syntax error. All you'd have to do is wrap your RHS in parentheses, making it explicit that your intention is to assign to an array with an array reference being the first and only element. This doesn't kill any Perl constructs. It just makes things a lot safer by requiring a little more syntax.

Perl is a fantastic language for rapid prototyping. It makes things that would be tedious in other languages very easy to bang out quickly so you can stay focused on your nascent ideas and ignore the potentially messy implementation details, if just for the moment. To this end, Perl ought also to try to prevent users from making careless mistakes that cause them to bog down in debugging. Having dangerous syntactic constructs that can easily lead to mental traps undermines the goals of rapid prototyping. Every time a programmer has to deal with the vagaries of a language, he's missing the rapid prototyping boat. The whole point of choosing a language like Perl for rapid prototyping is that it should be as transparent as possible to your endeavors to rapidly craft a prototype.