Slashdot Mirror


Perl Advent Calendar Enters Its 17th Year (perladvent.org)

An anonymous reader writes: Thursday brought this year's first new posts on the Perl Advent Calendar, a geeky tradition first started back in 2000. Friday's post described Santa's need for fast, efficient code, and the day that a Christmas miracle occurred during Santa's annual code review (involving the is_hashref subroutine from Perl's reference utility library). And for the last five years, the calendar has also had its own Twitter feed.

But in another corner of the North Pole, you can also unwrap the Perl 6 Advent Calendar, which this year celebrates the one-year anniversary of the official launch of Perl 6. Friday's post was by brian d foy, a writer on the classic Perl textbooks Learning Perl and Intermediate Perl (who's now also crowdfunding his next O'Reilly book, Learning Perl 6). foy's post talked about Perl 6's object hashes, while the calendar kicked off its new season Thursday with a discussion about creating Docker images using webhooks triggered by GitHub commits as an example of Perl 6's "whipupitude".

19 of 37 comments (clear)

  1. Re:fast, efficient code? by zuxun · · Score: 2

    Perl can always be viewed as Python with C syntax. Why are some people so negative?

  2. Re:fast, efficient code? by Anonymous Coward · · Score: 3, Insightful

    Allow the Perl libraries to manipulate data at warp speed and securely, rather than attempting to cobble together your own assembly language routines. Spend your time where it matters, optimizing algorithms and user interface.

  3. Re:fast, efficient code? by Anonymous Coward · · Score: 2, Interesting

    If you read the post, it's about using a module for a common pattern. It happens that the module is faster than the naive approach too.

    Also, Perl is known as the fastest of the general-purpose scripting languages. Whether that reputation is true or not, I don't know. But given that the interpreter has had twenty years of optimisation work poured into it, why wouldn't it be?

  4. Re:fast, efficient code? by ooloorie · · Score: 1, Insightful

    Perl can always be viewed as Python with C syntax. Why are some people so negative?

    No, unfortunately not. Perl has a much weaker type system, allowing expressions like (3 + "3"). That affects both efficiency and correctness of programs.

  5. ADVENT by TheRealHocusLocus · · Score: 1

    You are inside a building, a well house for a large spring.
    There are some keys on the ground here.
    There is a shiny brass lamp nearby.
    There is tasty food here.
    There is a bottle of water here.

    --
    <blink>down the rabbit hole</blink>
  6. Re:fast, efficient code? by doom · · Score: 4, Informative

    Perl has a much weaker type system, allowing expressions like (3 + "3"). That affects both efficiency and correctness of programs.

    I've been a perl programmer for decades, and the number of hours I've spent debugging issues with automatic type conversion are in the single digits, and the number of problems I've encountered with string-to-numeric conversion is literally zero, and if you were burned by something like that in production, I'd ask you why you weren't writing tests.

    There are indeed some odd issues you need to deal with when working with perl5, but they almost all revolve around a lack of standardization. There's something profoundly weird about perl critics, they continuously just *make shit up* to fit their narrative...

  7. Re:fast, efficient code? by doom · · Score: 2

    My understanding is that it used to be the fastest dynamic language around, but some others have caught up to it-- it's not something I care about really, I just know it's fast enough I don't need to think about the issue.

    I more interested in the fact that it's unicode support is better than almost every other language.

  8. Re:Another article on Perl? slashdot is going down by TheRealHocusLocus · · Score: 2

    You are inside the Democratic Party, a place of broken dreams.
    There are some abandoned fireworks on the ground here.
    There is a shiny brass collar nearby.
    There are some tasty memes here.
    There is a bottle of tears here.

    --
    <blink>down the rabbit hole</blink>
  9. Re:fast, efficient code? by ooloorie · · Score: 1

    I've been a perl programmer for decades, and the number of hours I've spent debugging issues with automatic type conversion are in the single digits, and the number of problems I've encountered with string-to-numeric conversion is literally zero

    How nice for you. You must not be writing very interesting or complex software.

    and if you were burned by something like that in production, I'd ask you why you weren't writing tests.

    I am writing tests; I just prefer writing as few tests as possible. The more the compiler and runtime check for me automatically, the fewer tests I have to write.

    There's something profoundly weird about perl critics, they continuously just *make shit up* to fit their narrative...

    I was using Perl for two decades. I wouldn't go back.

  10. Perl5 will always hold a special place in my heart by Anonymous Coward · · Score: 2, Informative

    It was the first language I really learned in depth, and was seemingly built specifically for the tasks I worked on in those formative years.

    Test automation, log / output parsing, HTTP / REST client, system administration scripts; Perl5 was the perfect level of abstraction for me, it's still my default pseudocode / mental model base when tackling problems.

    The experience writing automation and admin scripts and apps made my current DevOps role a natural fit, we were doing a lot of the core principles before the term "DevOps" was even coined.

  11. Re:fast, efficient code? by Orgasmatron · · Score: 1

    I don't see the problem.

    root@maga:~# perl -e '(1+1)'
    2
    root@maga:~# perl -e '(2+"2")'
    4
    root@maga:~# perl -e '("3"+"Three")'
    a suffusion of yellow
    root@Trump:~#

    --
    See that "Preview" button?
  12. Re:fast, efficient code? by doom · · Score: 1

    I've been a perl programmer for decades, and the number of hours I've spent debugging issues with automatic type conversion are in the single digits, and the number of problems I've encountered with string-to-numeric conversion is literally zero

    How nice for you. You must not be writing very interesting or complex software.

    On more complex software you tend to use an object system that does additional type-checking for you (usually "Moose", "MooX" or possibly "Mouse"... like I said about lack of standardization...).

    But I'm completely serious about this point: the perl culture has never been fanatic about the way it does things, and there are any number of issues where it was decided that things were too loose and needed to be tightened up: string-to-number conversions are emphatically *not one of them*. They don't even throw a warning, not even running with "use warnings" on (you heard of strict and warnings, right? In your 20 years of experience?).

    There's something profoundly weird about the strong-typing-or-death fanatics... they've got a bad case of obsessive compulsive disorder and using a string as a number drives them up the wall, even though it *never* causes any problems. Verily, not even you in your 20 years of experience can cite a case where it caused any problems for you.

  13. Re:fast, efficient code? by dbIII · · Score: 1

    Ignore ooloorie, he has a very long history of jumping onto issues he does not understand to troll.

  14. Re:fast, efficient code? by ooloorie · · Score: 1

    There is something profoundly weird about Perl fanatics. All I did was point out an actual difference between the Perl and Python type system, and you spew lots of bullshit. I think the shittiest part about Perl isn't its type system but its user community and their lousy attitudes.

  15. Re:Perl5 will always hold a special place in my he by hughbar · · Score: 2

    Agree. I'm semi-retired now but still do a little freelance. A while ago, I worked for BBC, UK Amazon offshoot etc. all of whom were big Perl shops. It's 'unusual' probably because of Larry Wall's background but natural (Do what I mean) and concise but readable (unlike APL, for example). Those that complain that it's 'line noise' need to write comments (remember those?) use use perltidy more often. Meanwhile CPAN, if one is selective, gives a lot of extra productivity.

    I went to the London Perl Workshop yesterday: http://act.yapc.eu/lpw2016/ great day out, good community and, as usual I learnt a lot. Will try Perl 6 for something small this year too. I understand that it looks alien and takes some getting used to, but it's a great language.

    --
    On y va, qui mal y pense!
  16. Re:fast, efficient code? by doom · · Score: 1

    You've no doubt had much occasion to experience this shittiness in your 20 years of experience, but nevertheless you see, the reason I am objecting here is that the example that springs to your mind of a perl oddity is one of the things that in point of fact never causes a single problem, and it seems peculiar that you can't come up with a more cogent criticism, particularly when one takes into account your 20 years of experience.

  17. Re:fast, efficient code? by doom · · Score: 1

    Ignore ooloorie, he has a very long history of jumping onto issues he does not understand to troll.

    The deuce, you say.

  18. Re:fast, efficient code? by doom · · Score: 1

    I was trying to respond with a perl code example showing some features it has -- which are admittedly optional -- to write readable code, but slashdot is refusing to let me post them because of it's "Lameness Filter", which I think has actually let quite a bit of lameness through.

  19. Re:fast, efficient code? by ooloorie · · Score: 1

    I simply gave an example of the fact that Perl is not just "Python with C syntax", not an extended critique. Note merely said this affected "both efficiency and correctness of programs", not that it constantly caused problems.

    The reason I switched away from Perl wasn't its poor design (after all, I still use C++), but the fact that it has been dying slowly. That, and people like you.