Thank you, that's a better-written answer than anything I could get down. I'd just like to add that (as the article does a pretty good job of saying) perl is /unparalleled/ as a text-processing language. There is no other language that even comes close to perl's ease and utility for string manipulation.

That's a good point. When I think over what I use Perl for in practice, it's usually some form of text processing. Perl is just the swiss army knife of I/O munging.

This is why Perl is my main workhorse. I process text almost exclusively.

The only part of this I'm going to take issue with is "You should learn Perl because you're likely to encounter a lot of Perl code in the wild."

"...because you can learn something from it" is a far better reason, because it's actually valid. Now, specifying what you're suggesting could be learned would be a good step, but I'd take it as-is without a problem.

The former, though? No, Perl is no longer occupying visible roles to the point where any new programmer can assume they'll be seeing it at all, much less "encounter a lot of Perl in the wild." It's out here, sure, but it's hidden in commands we use or scripts invoked by background tasks non-systems-programmers have absolutely no reason to touch.

Learning to do irresponsibly illegible things in Perl will teach you some great regex and... Perl. Learning Ruby (or Python, or Java, or even PHP) will get you actual work -- that doesn't involve being sequestered in backwards academia -- far more often now than Perl.

> Learning Ruby (or Python, or Java, or even PHP) will get you actual work far more often now than Perl.

Please only say such things when you can back them up. Yes, learning Java will get you more jobs (though, who really wants to do Java for a living?), but you'll still enounter Perl in more jobs than the other languages you mentioned:

http://www.indeed.com/jobtrends?q=Perl%2C+Ruby%2C+Python%2C+...

What one can learn from Perl:

When programming in a language you hate, don't take naming arguments for granted. It could be worse: you could be programming in Perl, where all arguments come in a flattened array.

This is really not much of an issue, if you bother to learn the language. If you don't, then yes, things will be confusing.

    sub named_params {
      my %P = @_; # named params in hash %P
      my $foo = $P{bar} + $P{baz};
      return $foo * $P{multiplier};
    }
    
    my $rvalue = named_params( foo => 1, bar => 2, multiplier => 3 );

Or, some people prefer to just pass in a hash reference:

    sub named_params_hashref {
      my $P = shift;
      my $foo = $P->{bar} + $P->{baz};
      return $foo * $P->{multiplier};
    }
    my $rvalue = named_params_hashref({
      foo => 1,
      bar => 2,
      multiplier => 3,
    });

But of course, why bother letting common sense, and a single line of code stand in the way of your chance to deliver a pithy remark?

just like in javascript - oh wait, that is the shiny new trend in programming, there it can't be bad thing the lack of named params.

"PySlice" with karma 25 is probably your trolling account. If not, ASK about stuff you have no clue about. It is better than looking like a little troll kid, having "fun" lowering the quality of HN by stupid language war comments.

>>where all arguments come in a flattened array

That is optional, through the power of CPAN (and kbenson's methods, of course). Examples of alternatives:

http://search.cpan.org/~barefoot/Method-Signatures-20130222/...

http://search.cpan.org/~flora/MooseX-Declare-0.35/lib/MooseX...

http://search.cpan.org/~ether/MooseX-Method-Signatures-0.44/...

(Depending on if you use Moose or not.)

One of the cool parts of Perl is that the language is extensible, that is why it e.g. has a better OO than Python, Ruby, etc. (Or simple typing of parameter arguments, see the modules above. Or why MooseX::Declare has ... ah, look yourself, troll.)

"the" language is then more of a loosely couples family of languages.

Not half as much as any Lisp variant with good macros.

Edit: The possibility to extend your environment is generally seen as a good thing, unless you believe in cleanliness of bloo... languages for ideological reasons.

That is a lie. Some of the arguments are provided as global variables like $_, (no need to remember its name, since its value will be implicitly used whenever you omit a necessary argument) whose value is decided by something akin to Clippy choosing what seems most handy.

$_ is not global, it's lexical. It's value is not haphazardly chosen, it is the topic for structures that topicalize.

You seem to be proving what I said earlier[1]. You think you understand what's going on, but in truth you don't. Feel free to continue making assertions regarding things you don't know, I can't stop you, but be aware that to do so is dishonest.

[1]: https://news.ycombinator.com/item?id=5657901

$_ is very clearly and sharply defined. Only because you never took even a slightly look at the documentation does not mean you should just make up things. :)