[cpplinuxdude]

Let's not forget what perl was created for; it's a practical extraction and report language.

Initially it was used to extract tables from text documents, and its always had a strong focus on text manipulation and regular expressions.

Its implicit variables and syntax mean you can write very, very concise code. Yet by following stylistic guidelines of your choice, you can write code that looks sane and maintainable.

I really like the fact you can import os commands and call them as a part of the language. It makes writing scripts a breeze. In fact writing anything in perl is a breeze. Check rosetta code, you'll see Perl 6 is one of the most concise at every turn.

As much as I really like python, I find that calling system commands is a pain.. calling os.system is obviously far from great, and calling subprocess can get cumbersome.

I haven't played with perl in a while, but my past experiences with perl was always getting a lot done, with very little work.

[pyre]

Just to note that it's not all puppies and unicorns. There are a lot of low-level commands that are all tied up in different modules in Perl. Like having to remember where what you want falls into the File::* namespace... or maybe what you need is in Cwd.

I worked with Perl for 4 years, and while it's not the gauntlet of pain that people make it out to be, there were several annoyances (like needing to always hit the docs for that stuff).

[kbenson]

The biggest problem I have programming Perl 5 is discovery of what the best current module is to get past the pain points of the past, and the best way I know of that is to keep current with community discussions. E.g. Path::Tiny is awesome for automating a lot of the file ops you could want to do into one simple, useful, well structured place. As soon as you're exposed to it, you'll immediately want to scrap the use of 3-4 other modules you might have been using in lieu of it. What's the best way to learn about it? Possibly reading Perl community blog posts. It's unfortunate, but with a couple decades worth of modules on CPAN, it can be hard to find the gems of the bunch without some help.

[mst]

That's what the mstpan posts on http://shadow.cat/blog/matt-s-trout/ are for; I'll be doing more starting Dec 1.

[justinator]

Perhaps, https://metacpan.org/pod/Task::Kensho

[kbenson]

Yeah, I'm aware of Task::Kensho (although I forget about it all too often). But even that is at this point more a point-in-time snapshot of what was relevant a year or two ago. In most cases, they are still relevant and some of the best choices, but there are new items that aren't on the list (e.g. Path::Tiny) that I would argue really should be.

I understand it's a trade off. We don't have a large standard library in Perl like Python does, and that means there's a bit of searching required to find what to use, but that's often a benefit as well as a drawback. Would we have Path::Tiny if we had something that provided some but not all of the capability, and not as well? Would we have DateTime (or would it be popular) if we had a core DateTime-like module that was problematic, but mostly worked? Part of the beauty of having a small core set of libraries and an large and vibrant set of extended libraries is that the constant churn leads to newer and better things. Really what I'm lamenting, is that while there are these benefits to the churn, it still does lead to some painful situations where you find you've been using a poor choice for your needs just because you didn't know of the better choice that was out there. It's acceptable if it leads to DBIC, DateTime, Path::Tiny, etc, but it still sucks some times.

[justinator]

I'm right there with you. Having a small core has several drawbacks.

Having a LARGE core does as well, and mostly that any modules in the Perl core seem to also have their API and features frozen in time. Even if those features and API are not so good - it's in core! So, there's a reason to keep them how broken they are for backwards-compatibility sake.

I've also felt the burn of a core module that's then removed, and the new maintainer now going absolutely wild changing things. I understand exactly why they want to change things, and would not disagree with their ideas in a vacuum, but it causes great grief to me when I'm supporting apps that relied on in-core modules that have been upgraded out of core.

I wanna say that this problem is being used as a lesson for Perl 6 - that the core for the, "official/main/whatever" distro is going to be kept very spartan, but it's going to be encouraged to build upon that distro for your own Perl 6 releases. So, if you want the, "Web Framework" release, it'll come with all the bits and pieces you need to get that going - however editorialized that selection will be.

Moritz talks about this concept, here:

http://perlgeek.de/blog-en/perl-6/how-core-is-core.html

Although this post is pretty old, and I'd hate to say that their line of thinking now.

[awwaiid]

Note, however, that Perl6 is a completely different language with a different set of standard libraries and ecosystem and pros-and-cons. You'd be as well off comparing Perl6 to Ruby as you would Perl5.

[cpplinuxdude]

I only used it for small scripts. I'd think twice before using it for anything more significant.

What did you use it for, if I may ask? What how big a project are we talking about?

I would have thought hitting the docs wouldn't be a part of the annoyances list. Did you feel you had to hit the docs more than with any other language?

[jquast]

> As much as I really like python, I find that calling system commands is a pain.. calling os.system is obviously far from great, and calling subprocess can get cumbersome.

Have a look at the 'sh' python module to ease your pain: http://pypi.python.org/pypi/sh

[kamaal]

I think having to use/install something is precisely the pain people are talking about.

[jrumbut]

Especially for the kind of glue scripts we're talking about, having to install new language packages across a heterogeneous environment consisting of thousands of boxes is not an easy option.

For me the greatest advantage of the Perl5/shell integration is that you can use Perl's sane data structures, flow control, and code organization features instead of their bash equivalents which have endless pitfalls and can be less portable than basic Perl5.

[cpplinuxdude]

That's useful, thanks.