Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Perl isn't Going Away Soon (Or Ever)

ostatic.com

Post reply on HN
Print view View original

81–88 of 88 posts

Re: Why Perl isn't Going Away Soon (Or Ever)

#81

Post by chromatic »

ianb wrote: post #80
chromatic wrote: post #78

Earlier quoted context omitted.

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…

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).

Re: Why Perl isn't Going Away Soon (Or Ever)

#82

Post by ianb »

chromatic wrote: post #81
ianb wrote: post #80

Earlier quoted context omitted.

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…

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 overlo…

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.

Re: Why Perl isn't Going Away Soon (Or Ever)

#83

Post by chromatic »

ianb wrote: post #82
chromatic wrote: post #81

Earlier quoted context omitted.

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 overlo…

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 wor…

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?

Re: Why Perl isn't Going Away Soon (Or Ever)

#84

Post by adam-_- »

plinkplonk wrote: post #25
gamache wrote: post #23

Article's conclusion: After a short lapse, Perl development is picking up and enthusiasm for Perl 5 is as strong as ever. I would agree. A little over a decade ago, Perl suffered from the same problems which plagued JavaScript in its early days: ease of writing shitty code, mountains of shitty sample code, and a community which did not vehemently encourage the writing of unshitty code. This caused a backlash which la…

"Perl development is picking up and enthusiasm for Perl 5 is as strong as ever." I will take your word for it, but I do have to say (speaking as someone with a lot of grey in his hair) that I haven't seen a young developer choose to work primarily in perl (over ruby or Python or Java or C#) in ages. Most new projects/startups don't seem to choose perl as their primary language. I readily concede that this is probably…

I am a young developer working primarily in Perl.

Reasons? Friendly, knowledgable community. CPAN and Catalyst.

Admittedly I don't know any other [under]graduates using Perl (outside of bio/geology).

Re: Why Perl isn't Going Away Soon (Or Ever)

#85

Post by _delirium »

sreque wrote: post #50
plinkplonk wrote: post #25

Earlier quoted context omitted.

"Perl development is picking up and enthusiasm for Perl 5 is as strong as ever." I will take your word for it, but I do have to say (speaking as someone with a lot of grey in his hair) that I haven't seen a young developer choose to work primarily in perl (over ruby or Python or Java or C#) in ages. Most new projects/startups don't seem to choose perl as their primary language. I readily concede that this is probably…

Older people use it is because they don't want to change or learn something new. Especially in a company already entrenched in Perl development, their is little benefit to switching to a better language compared to the cost of forcing people to learn a whole new technology stack when they are more than content with Perl. However, new companies are much more free to build on whatever technology stack is most appropria…

I actually tend to find the opposite: I know lots of CS majors who love perl and C, and lots of web-design-focused non-cs-majors who love ruby, python, and php. Both groups are approx the same age (late-20s/early-30s).

Re: Why Perl isn't Going Away Soon (Or Ever)

#86

Post by gamache »

chromatic wrote: post #79
gamache wrote: post #34

Earlier quoted context omitted.

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.

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. :)

Re: Why Perl isn't Going Away Soon (Or Ever)

#87

Post by ianb »

chromatic wrote: post #83
ianb wrote: post #82

Earlier quoted context omitted.

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 wor…

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.

Re: Why Perl isn't Going Away Soon (Or Ever)

#88

Post by chromatic »

ianb wrote: post #87
chromatic wrote: post #83

Earlier quoted context omitted.

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 an…

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.

Post reply on HN