Hacker News new | past | comments | ask | show | jobs | submit login

Are there languages which don't require some special syntax for accessing nested data structures?

Isn't that true for... most languages? Python, Ruby, Java, PHP, Smalltalk. And any language created in modern times. Perl in this respect is like a transitional animal in the evolution of languages -- what seemed somewhat modern given its peers (like shell or Tcl) now seems horribly outdated, the programming language world moved on having considered nested data structures a solved problem. It's like goto or dynamically scoped variables in other eras.




How to make an array of arrays in Perl 5:

    @aoa = ( [ 1, 2, 3 ], [ 4, 5, 6 ] );
How to make a list of lists in Python:

    lol = [ [ 1, 2, 3 ], [ 4, 5, 6 ] ]
How to access the second element of the second array in Perl 5:

    $aoa[1][1];
How to access the second element of the second list in Python:

    lol[1][1]
The difference seems to be nomenclature and Perl's use of sigils. Where's the "horribly outdated" design?


You've selected one option where Perl looks sane, while leaving out cases like "[ [1, 2, 3], [4, 5, 6] ]" or "( (1, 2, 3), (4, 5, 6) )". And of course there's other cases like lists containing hashes, and hashes containing lists. All of these are handled consistently in languages like Python and Ruby, and the programmer never needs to consider the interaction of the container and the objects it contains -- numbers and lists and strings and hashes are all objects and all act exactly the same with respect to containers.


I'm not going to defend Perl 5's dereferencing syntax for container operations. Perl 6 changed that for a very good reason.

I could give you examples of Ruby's and Python's inconsistency in their use of parentheses, as sometimes they group expressions to influence parsing precedence and sometimes they denote first-class data structures, but as you persist in asserting that parentheses create lists in Perl and that lists are first-class data structures, I suspect this discussion will continue to go nowhere.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: