4 ms·

The ugliest parts of Perl (in my admittedly not-exceptionally-well-informed opinion) are dereferencing variables and automatic list flattening. I honestly don'

The ugliest parts of Perl (in my admittedly not-exceptionally-well-informed opinion) are dereferencing variables and automatic list flattening. I honestly don't know what kind of crazy design process could possibly lead to the way Perl handles nested lists. $a[0]->[0]? @{$a[0]}? Why? God?

william42 18y ago
It handles lists that way because of the braindead idea of sigils which, in order to be semantically consistent, cannot have as an element of a list being a list.
- philh 18y ago
  I'd like to see you back that up. $a[0][0] does exactly what it looks like it should do: it takes the first element of the list at $a[0]. (Incidentally, this is exactly the same as the gp's $a[0]->[0].) The only problem sigils introduce is the -> in expressions like $a->[0]. ($a is a reference to a list, and you can't write $a[0] in this case because it will look at the list @a.) I'm not entirely sure why perl doesn't have good support for nested arrays and hashes, but I'm pretty sure it's not to do with sigils.
  - SwellJoe 18y ago
    It's historic. In The Beginning...Perl was a different language, a simpler language built to take the place of awk/sed/grep/shell in one mostly consistent package, and when it later obtained complex data structures, they were implemented on top of the existing semantics, which involved arrays and hashes that could only store scalars. I don't think anyone thinks list-flattening is a good idea, these days. And, of course, Perl 6 gets better handling of complex data structures...if I recall correctly, it gets an explicit "slurpy" sigil that provides the flattening behavior, but I don't actually work in Perl 6 yet, so I'm not sure of that.
- SwellJoe 18y ago
  It has nothing to do with sigils. It has to do with the legacy of arrays and hashes only storing scalars in ancient Perl. Perl 6 does not flatten by default. (And, obviously, sigils remain a core part of the language.
  - benmathes 18y ago
    Short answer: Don't write $a->[0]->[0]->[0]->[0]->[0], write $a->[0][0][0][0][0]. It does the same thing. Long answer: As for writing code, however, you don't need to write $a->[0]->[0]->[0]->[0]->[0]. After the first dereference (if any), you can omit the '->'s because arrays and hashes only store scalars so perl knows you're talking about a reference. You can use all the arrows for backwards compatibility.
  - william42 18y ago
    The legacy of arrays and hashes only storing scalars is pretty much because of sigils.
    - SwellJoe 18y ago
      Citation needed.
shimon 18y ago
I agree that this approach is deranged. It all stems from the decision to distinguish between values and references. That decision comes from the available hardware and typical programming background at the time of Perl 5's development (early 90s). At that time computers weren't abundantly fast for most programming goals, and storing all variables as references (or objects) was a pretty serious "extreme OO" position. Plus, anyone who called himself a hacker would have to be competent with pointers in C, and Perl references were substantially easier than that. So Perl layered on ways to reference and dereference values, and @{$array->[1]{"foo"}} was born.
- Agathos 18y ago
  When Perl references start making as much sense as C pointers it will be a considerable improvement.
  - SwellJoe 18y ago
    You really believe that? I simply can't believe anyone would find working with complex data structures in C easier than in Perl. It just doesn't make sense, but obviously a few people agree with you. Have you actually worked in Perl (and C)?
    - Agathos 18y ago
      C pointers make sense to me because they represent what's going on in the machine. The syntax and the rules behind it are simple enough that they click, for me. Perl references seem to carry a lot of historical baggage that leads to the expressions mentioned elsewhere in this thread. The rules behind them always seemed arbitrary and I have never felt like I had a grip on them. Now that said, I'm still more likely to blow my foot off with C than with Perl, thanks to the do-it-yourself memory management. But at least when it happens it's for the right reasons.
      - SwellJoe 18y ago
        Now that said, I'm still more likely to blow my foot off with C than with Perl, thanks to the do-it-yourself memory management. But at least when it happens it's for the right reasons. You're my hero, and I mean that. I'm glad we cleared that up, and I'll readily agree that complex data structures via references is among the most glaring warts in Perl. It's obviously more complicated and error-prone than it ought to be, and moreso than other similar languages. I've got this theory that the thing that people talk about most in any language or technology is the thing that is actually most broken about the language. People talk a lot about references in Perl, and I know they're broken by design. Similarly, I've got my suspicions about monads in Haskell, since people spend so much time trying to explain them...seems like there must be some fire under all that smoke. But I could be just imagining it, and I think I probably need to spend a lot more time with Haskell before I can accurately detect bogosities.

william42 18y ago

It handles lists that way because of the braindead idea of sigils which, in order to be semantically consistent, cannot have as an element of a list being a list.

philh 18y ago
I'd like to see you back that up. $a[0][0] does exactly what it looks like it should do: it takes the first element of the list at $a[0]. (Incidentally, this is exactly the same as the gp's $a[0]->[0].) The only problem sigils introduce is the -> in expressions like $a->[0]. ($a is a reference to a list, and you can't write $a[0] in this case because it will look at the list @a.) I'm not entirely sure why perl doesn't have good support for nested arrays and hashes, but I'm pretty sure it's not to do with sigils.
- SwellJoe 18y ago
  It's historic. In The Beginning...Perl was a different language, a simpler language built to take the place of awk/sed/grep/shell in one mostly consistent package, and when it later obtained complex data structures, they were implemented on top of the existing semantics, which involved arrays and hashes that could only store scalars. I don't think anyone thinks list-flattening is a good idea, these days. And, of course, Perl 6 gets better handling of complex data structures...if I recall correctly, it gets an explicit "slurpy" sigil that provides the flattening behavior, but I don't actually work in Perl 6 yet, so I'm not sure of that.
SwellJoe 18y ago
It has nothing to do with sigils. It has to do with the legacy of arrays and hashes only storing scalars in ancient Perl. Perl 6 does not flatten by default. (And, obviously, sigils remain a core part of the language.
- benmathes 18y ago
  Short answer: Don't write $a->[0]->[0]->[0]->[0]->[0], write $a->[0][0][0][0][0]. It does the same thing. Long answer: As for writing code, however, you don't need to write $a->[0]->[0]->[0]->[0]->[0]. After the first dereference (if any), you can omit the '->'s because arrays and hashes only store scalars so perl knows you're talking about a reference. You can use all the arrows for backwards compatibility.
- william42 18y ago
  The legacy of arrays and hashes only storing scalars is pretty much because of sigils.
  - SwellJoe 18y ago
    Citation needed.

shimon 18y ago

I agree that this approach is deranged. It all stems from the decision to distinguish between values and references. That decision comes from the available hardware and typical programming background at the time of Perl 5's development (early 90s). At that time computers weren't abundantly fast for most programming goals, and storing all variables as references (or objects) was a pretty serious "extreme OO" position. Plus, anyone who called himself a hacker would have to be competent with pointers in C, and Perl references were substantially easier than that. So Perl layered on ways to reference and dereference values, and @{$array->[1]{"foo"}} was born.

Agathos 18y ago
When Perl references start making as much sense as C pointers it will be a considerable improvement.
- SwellJoe 18y ago
  You really believe that? I simply can't believe anyone would find working with complex data structures in C easier than in Perl. It just doesn't make sense, but obviously a few people agree with you. Have you actually worked in Perl (and C)?
  - Agathos 18y ago
    C pointers make sense to me because they represent what's going on in the machine. The syntax and the rules behind it are simple enough that they click, for me. Perl references seem to carry a lot of historical baggage that leads to the expressions mentioned elsewhere in this thread. The rules behind them always seemed arbitrary and I have never felt like I had a grip on them. Now that said, I'm still more likely to blow my foot off with C than with Perl, thanks to the do-it-yourself memory management. But at least when it happens it's for the right reasons.
    - SwellJoe 18y ago
      Now that said, I'm still more likely to blow my foot off with C than with Perl, thanks to the do-it-yourself memory management. But at least when it happens it's for the right reasons. You're my hero, and I mean that. I'm glad we cleared that up, and I'll readily agree that complex data structures via references is among the most glaring warts in Perl. It's obviously more complicated and error-prone than it ought to be, and moreso than other similar languages. I've got this theory that the thing that people talk about most in any language or technology is the thing that is actually most broken about the language. People talk a lot about references in Perl, and I know they're broken by design. Similarly, I've got my suspicions about monads in Haskell, since people spend so much time trying to explain them...seems like there must be some fire under all that smoke. But I could be just imagining it, and I think I probably need to spend a lot more time with Haskell before I can accurately detect bogosities.