[stewartbutler]

So many edge cases. I prefer to just use perl if I am doing anything more complicated than making a wrapper for some other executable. Harder to screw up, easier to test, same expressiveness, better portability (works with all shells and with windows), plus you get regular expressions for free.

Python is a good alternative as well.

[s_kilk]

Perl is brutally under-rated as a scripting tool these days. I suppose it's passed into software orthodoxy by this point, the notion that perl is a uniformly horrific tool akin to nuclear waste.

[naivepiano]

I think that this is because people are finding Python equally well suited for such tasks and more modern. Perl (easy to) obscure syntax is not helping either.

[jerf]

If you're doing a really grungy, grotty text mangling task in a UNIX pipeline, suddenly all those crazy Perl features start making sense. The reason why Perl is arguably not the best choice for other tasks, such as creating large systems, is precisely that it's actually got many distinct advantages over Python for that sort of task. It's also really good for "I have a UNIX pipeline but this one chunk of it needs a database and this other chunk needs a JSON file and a few other things that shell just can't do".

For instance, for the first time in 15+ years, I recently had a reason to use Perl's half-deprecated, off-handedly-included form printing support, and, you know what? It's really nice if that's what you want. Many dozens of lines of code replaced by what is basically a picture of what I want.

Python is a great language, but every once in a while "explicit is better than implicit", which is generally a philosophy I agree with wholeheartedly, results in a lot more "explicit", in the form of "code I had to write", than you might be looking for. (Or, alternatively, you start writing Python that is a lot more implicit, which isn't exactly a huge victory for Python here.)

Nowadays I'd also suggest that if you find yourself having a lot of those tasks, you need to ask some questions about how you're storing your data. But pretty much everybody ends up with some of these somewhere; it's hard to eliminate them, and not really worth it (due to diminishing returns).

[logicallee]

you can't learn perl 5 (as a new programmer) because of perl 6, and the last time I did a search for a perl 6 solution it didn't work for me, I actually ended up installing perl 5 and just doing it that way. I remember now, I literally googled "perl 6 installer windows" and clicked the first link and within 10 minutes couldn't install it. I think the installer just hangs - http://rakudo.org/how-to-get-rakudo/

so I just installed perl 5 and did it my usual way. But if I didn't know Perl already it would be a non-option. it's just not a language anymore, it's a legacy thing that if you already learned you can sometimes still use.

[marcosdumay]

Although Perl6 exists, Perl5 is completely unfit for any purpose on the modern world. And just the memories from helpless hours debugging any simple 30 lines script means that I'll resort to Haskell before trying Perl6 for text manipulation uses.

An younger developer may think differently, but I do think the 'Perl' brand is already too damaged for surviving the transition, even if Perl6 is better than modern languages (what I didn't see anybody claiming yet).

[childintime]

political correctness easily gets in the way of the serious warning that should go out to the younger folks: stay the f*ck away from bash and its siblings! do not ever think it is a solution worth considering! abandon!

instead use something with a cross-platform interface (Python, Chrome or Lua, whatever), compile your own executable or use a compiler that targets bash.

besides, it is only a matter of time before the systemd trojan invades this area, and your newly acquired skills will be obsolete </sarcasm>.