[skimbrel]

They weren't originally intended to provide namespacing, as far as I know. They were there to make the compiler's life easier.

The reason that an array subscript is "$foo[0]" is because the $ sigil means "HEY COMPILER, the expression here is going to evaluate to some scalar".

@foo is the entire list and the compiler treats it as a list type; $foo[0] is an element of the list and needs storage/behavior of a scalar. Same thing for hashes: %bar is the whole hash; $bar{quux} is an element and must be treated by the compiler as a scalar.

The programmer must remember that square braces mean array subscript and curly braces mean hash lookup.

So basically, this is a compiler optimization implemented by having the programmer provide hints to the compiler. It's overhead that probably isn't needed in the modern age, but we're effectively stuck with it. It wouldn't be so bad if they hadn't made the second (and IMO worse) decision:

You can reuse symbols across contexts. The way this works is that the compiler maintains a symbol table where each symbol has a slot available for each of the types (scalar $, array @, hash %, subroutine &). This was originally the way to emulate pass-by-reference: you'd write a subroutine that assigned its arguments into typeglobs (* foo — think of it as a wildcard for all things named foo that behaves as a magic scalar with the contents of foo's symbol table entry) and then pulled them back out as the types it wanted:

  local(*foo) = @_;
  foreach $bar (@foo) {
    do_something($bar);
  }

This amounts to telling the compiler "I want to alias the name foo in all contexts to my argument, and then go look at what's stored in the array at that name" and is a poor man's pass-by-reference.

Perl 5 has a real reference system that completely obviates the need for this, except for the case of monkey-patching a subroutine, where you still say:

  local *Package::quux = sub { ... }"

What's left is an unfortunate case where things like the GP mentioned ($bar = $foo[$foo]) are possible, and people who think they're being clever will do these things. Like the parent said, this is not a good thing to do.

[Jeema3000]

"So basically, this is a compiler optimization implemented by having the programmer provide hints to the compiler."

I'm not entirely sure that's correct. I think Larry Wall (being a linguist originally) designed it that way because he thought that using context-sensitive sigils was more like regular speech where leading words indicate the number, i.e. 'a cup' vs. 'some cups'...

[epochwolf]

> Larry Wall (being a linguist originally)

Having taken a class on linguistics, I have to say basing a computer language on it is a horrible idea.

Human languages are far more complex and verbose than is required for talking to computers. Consider that it takes years to master a spoken language. A computer language should be much easier to pick up once you already know how to use an existing language. Computer languages should attempt to reduce complexity and verbosity where possible.

Example: I picked up lua in a week. (javascript and ruby experience helped a lot) I'm not an expert by any means but I'm capable of writing usable applications. I doubt a person could pick up a new human language in a week.

[mkn]

Human languages are far more complex and verbose than is required for talking to computers.

This is mostly a quibble, but human languages are not more verbose than computer languages, generally. I can generally rely on you to allocate all the variables and present the result in a context-aware way when I ask you, "What is 3 + 5?" I'd generally have to allocate variables and tell the computer where to put the result if I were to ask it the same question.

What was, and still is, sort of magical about Perl is the degree to which it is aware of context and can use it to sort out meaning. If anything, the chief complaints against Perl, which stems from its similarity to natural languages (!), is its terseness and expressive power, these complaints being that it's indistinguishable from line noise and is a write-only language.

[Mithaldu]

Honestly, Perl is really anything but a write-only language. Consider this:

https://github.com/schwern/AAAAAAA/blob/aaaaaa/aaa/AAAAAAAAA...

It should be unparsable, but most people who have some Perl knowledge find they can actually read and understand this.

[steve-howard]

I appreciate the depth of your response; the original reasoning makes sense, and as Python 3 tells us, it is very hard to get people to use your new version if you break enough old code.

[danudey]

This seems unfair to Python 3. The Python community, including the developers of Python 3, have not been encouraging people to migrate to Python 3. In fact, it was never in their roadmap for people to migrate immediately. The common wisdom has always been 'When starting a new project from scratch, if all the libraries you need are ported, and you won't need backwards compatibility down the road, then use Python 3. Otherwise, use Python 2.x'.

It's quite difficult to get people to use your new version when you actively tell them that it's probably not a good idea right now.