Hacker News Reader

Comment by DrSprout | Hacker News Reader

The article still makes an excellent point, which is that the difference between most of the 'newer technologies' and Perl is basically marketing, not any actual superiority of language design. You can write line noise in Perl, but you can also write Python in Perl. It may not be quite as pretty as Python, but as far as use in a production environment it will be equally useful.

View on HN

Why not just write Python in Python instead ;)?

I like my braces ;}.

Also, Perl 5 is feature-stable, and probably always will be. Python is in this 2.x-3.x limbo right now where it's difficult to find libraries that are going to work as-is for much longer. If you write a Perl application well, maintenance will as easy as reasonably possible, which I think is the only real measure of a good language. Most of the 'ease of use' problems disappear once you know what you're doing, and the language learning curve is a relatively small part of a programmer's life-cycle.

Since 2.x is just as feature stable and was just released in the last incarnation (2.7) before an "extended maintenance period", I do believe the limbo you speak of isn't an issue for anyone actually using Python.

I can imagine it looking worrisome from the outside, though.

That's a rather twisted reasoning, with Perl 6 on the doorstep ;)

Perl 6 is not meant to interoperate directly with Perl 5. It's not an incremental update in any way. IMO, it would be a lot clearer if Perl 6 weren't called Perl.

I agree totally. Perl6 is to Perl5 what VB.NET was to VB6. They aren't the same.

So all the Perl programmers are going to find other jobs like the VB guys did?

Perl 6 is not meant to interoperate directly with Perl 5.

Indeed it is.

That's fair; I should have phrased that better. Here's your chance. :)

CPAN. CPAN is fricking awesome.

Or write Perl in Perl. Some languages allow code not only "as pretty as Python", but even prettier.

Some do ;)

I consider Perl's data structures to be genuinely inferior. Lists that cannot contain other lists are not reasonable in a high level language. Pointers are not reasonable in a high level language. Explicit function signatures are a superior language design.

Lists that cannot contain other lists are not reasonable in a high level language.

Perl has supported arrays of arrays since 1994.

Pointers are not reasonable in a high level language.

Perl has never supported pointers.

Explicit function signatures are a superior language design.

I agree with this. Perl 5 should have had them years ago.

If you put a list in a list in Perl, don't you have to specifically dereference the sublist when accessing it? Otherwise you get what looks to my eye like a pointer (a weird random number). The first google result I get is this: http://www.webreference.com/programming/perl/nested/ -- and to me "reference" == "pointer". And the fact that it is all weakly typed (that is, pointers are not a distinct type) makes it that much worse.

If you put a list in a list in Perl, don't you have to specifically dereference the sublist when accessing it?

You mean "array" instead of "list", but yes. Are there languages which don't require some special syntax for accessing nested data structures?

Otherwise you get what looks to my eye like a pointer (a weird random number).

When you stringify a reference, you get either the default stringification or an overloaded stringification, if you've overloaded stringification for a particular class. When you numify a reference, you get a unique number. Think of it as a cheap object identifier, because that's effectively what it is. It's not a great interface to expose to users, but that's its intent.

I argue that it's not a pointer, because you can't do pointer arithmetic with it.

...pointers are not a distinct type...

You mean "reference", and indeed they are distinct. They're RVs. That's a scalar type (SV).

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.

Reply on news.ycombinator.com