Perl Advent Calendar Enters Its 17th Year

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

fast, efficient code?

[ooloorie]

Friday's post described Santa's need for fast, efficient code

What does Perl have to do with "fast, efficient code"?

Re:

[zuxun]

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

Re:

[ooloorie]

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.

Re:fast, efficient code?

[doom]

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

Re:

[ooloorie]

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 comp

Re:

[doom]

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 sta

Re:

[ooloorie]

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.

Re:

[doom]

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.

Re:

[ooloorie]

I simply gave an example of the fact that Perl is not just "Python with C syntax", not an extended critique. [lmgtfy.com] 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 [githut.info] slowly [tiobe.com]. That, and people like you.

Re:

[dbIII]

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

Re:

[doom]

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

The deuce, you say.

Re:

[Orgasmatron]

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:~#

Re:

[doom]

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.

Re:

[Anonymous Coward]

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.

Re:

[Anonymous Coward]

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?

Re:

[doom]

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.

ADVENT

[TheRealHocusLocus]

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.

Re:

[TheRealHocusLocus]

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.

Perl5 will always hold a special place in my heart

[Anonymous Coward]

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

Re:

[hughbar]

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 y