Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 9, 2009 11:25 UTC (Mon) by epa (subscriber, #39769)
In reply to: Perl far from dead, more popular than you think (Royal Pingdom) by chromatic
Parent article: Perl far from dead, more popular than you think (Royal Pingdom)

The trouble is that parentheses also *look like* list creation symbols in Perl. For example,
my @a = (1, 2, 3);
This is wrong:
my @a = 1, 2, 3;

So () makes a list? No, not really, since this doesn't work as you'd expect:
my @nested = ((1, 2), (3, 4));
In fact the list constructor is []. But then, this is also incorrect:
my @nested = [[1, 2], [3, 4]];

The right answer is to use a mixture of both:
my @nested = ([1, 2], [3, 4]);

Once you get used to Perl's peculiarities this starts to make sense - but you can't pretend it is straightforward for the beginner. Perl has a whole tutorial (perldsc) on how to accomplish the feat of nested data structures, which in Python or Ruby are so obvious they need no explanation.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 9, 2009 21:16 UTC (Mon) by chromatic (guest, #26207) [Link] (3 responses)

The trouble is that parentheses also *look like* list creation symbols in Perl.

That's not a problem unique to Perl. I posted elsewhere in this thread some very short Ruby and Python examples which I believe violate the principle of least surprise because the meaning of parentheses switches between creating lists (or tuples or whatever you want to call them) and grouping expressions.

Once you get used to Perl's peculiarities this starts to make sense....

Again, this is not a matter of Perl's peculiarities. I believe the Perl approach makes more sense; different punctuation characters do different things.

... you can't pretend it is straightforward for the beginner.

Sure, but we're talking about operator precedence, grouping, and false cognates here. Show me a beginner who doesn't know anything about lists or arrays in any programming language and the first two will still be difficult concepts to understand.

... nested data structures ... in Python or Ruby are so obvious they need no explanation.

Perhaps that is true for experienced programmers who've used a similar language with similar semantics before. I don't believe nested data structures are obvious to programming novices in any language. (Again, I won't defend Perl 5's dereferencing syntax -- but you won't convince me that a neophyte programmer can guess that nested data structures exist with the specific Python or Ruby syntax from reason alone.)

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 10, 2009 0:30 UTC (Tue) by alankila (guest, #47141) [Link] (2 responses)

I just think it's plainly unfortunate that @ and % still exist, given that all that you could have got with them is now doable with references and the corresponding constructors of those structures. So imagine that newbie documentation only said:

@foo = (1,2,3); # depreciated
$foo = [1,2,3]; # endorsed.

Unfortunately the syntax for references then gets a few annoying {} and -> which the @ and % versions can avoid, so stuff that should be simple looks ugly as heck.

I agree with the base criticism of the grandparent: everyone learning Perl5 will have to climb that particular roadblock of untangling the rather subtle meaning of "@a = (1,2,3)" and then the completely different "$a = [1,2,3]".

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 10, 2009 2:16 UTC (Tue) by chromatic (guest, #26207) [Link] (1 responses)

PHP tried single-sigil variables; it works about as well there as does making all arrays associative (not indexed). The semantics are messy when you do anything non-trivial and you actually *lose* type information when reading code.

I think you also break list context and complicate the optree, when you can't determine at compilation time if a list is constant or if it's merely part of an array constructor.

Perl far from dead, more popular than you think (Royal Pingdom)

Posted Nov 10, 2009 6:34 UTC (Tue) by alankila (guest, #47141) [Link]

Well, Perl references go $foo->[] and $foo->{} for the two kinds we have in mind here. They are clearly distinct and no information is lost by not having @ and % visible in this expression.

That being said, it's a bit frustrating if you would need some third kind of collection, there's no syntax available for that. But that's a completely different argument, and my opinion is that there's no real need to use every symbol on the keyboard, anyway: a single generic syntax seems cleaner to me than allocating every type of brace for something. Java only has fixed-size arrays available on syntactic level and no hashes at all: method calls work as the generic extension mechanism. PHP apparently decided to just implement arrays as hashes and forget about having "real", numerically indexed arrays.

As to the second point, I'm not even proposing removal of anything, I was just suggesting that the @foo and %foo style variables could/should be avoided as unnecessary in new code.

On a tangential note, here's another of these famous Perl hacks which indicates that Perl currently plays fast-and-loose about which lists are constants and which are not:

$ perl -wle 'sub bug { print map $_++, 1..3; } bug(); bug()'
123
234

For some reason this never bites anyone, allegedly.