Python and Ruby have most of the fundamental advantages of Perl. I don't really miss Perl itself all that much when using them. CPAN on the other hand is damned hard habit to kick. It's addicting having a massive collection of (often) battle hardened code available for virtually any task.
I actually don't mind Perl's type indicators which show up in front of variable names, as it makes it clear throughout the code what you are working with (this coming from someone who rarely uses Perl anymore).
The 'problem' with Perl's type indicators are that it's slightly unintuitive to, say, create a hash using %, but to access a hash (and return a variable) you use $, so the punctuation indicates the return type rather than the type you are accessing and might not make sense without context. Whatsmore, it requires you to remember two things - the type of brackets required and the return type, one of which is largely redundant.
Incidentally, I'm pretty sure they're changing this with Perl 6 and making it to that the symbol indicates the type you are accessing. I'm split as to whether this is a good idea or not, especially as they're retaining the still largely redundant curly brackets when ordinary brackets will now do.
Do not learn how to use a pen and paper. The paper will get under your skin, especially if you give yourself paper cuts. You'll be able to bend and twist C++ code in ways you never dreamed of, like into a paper airplane. You'll miss all the intricate quirks and nuances, like how your pen stops writing when you use it upside down.
In short, if you wish to keep your sanity, do not learn how to use a pen and paper.
To me it is still a good idea to learn Perl, for the following reasons (different from the article):
You figure out why Python and Ruby were invented
It'll help you can figure out how to port existing Perl programs (that no one in your company wants to touch) to either Python or Ruby
You can more easily write code so hard to read that it virtually offers lifetime job security
(to be fair, without Perl I don't think the Internet would have had as much success in the very beginning since it was easier to put up a site with it. not to mention many of the major sites I still go to were built on it)
It's not about websites -- raw text is what Perl was made to handle. It really is the Swiss Army Chainsaw, the Duct Tape of the Internet -- I try never to use Perl anymore, but when I need it, it's there, along with CPAN, calmly biding its time.
Perl is horrible, ugly, unclean, unmaintainable in the general case, inelegant (ahem accessing nested arrays by multiple index? ahem)... and in spite of all that, used sparingly and in the right situations, it cannot be beat.
CPAN is the key to Perl. Lots and lots of code that Just Works. Sometimes the elegant, bulletproof solution is not the best one -- sometimes the solution that takes 2 lines and 5 minutes is, in fact, the correct solution for the task at hand. And that latter task is whence Perl sprang. It also amply describes the chaos of the Interwebthingy from around 1994 to 2001.
Things are different now. Corporate-like. But in the beginning, it was the Wild West, and you used the sharpest tool you had handy. Perl was often that tool.
> Perl is horrible, ugly, unclean, unmaintainable in the general case, inelegant
Depends on the coder. To me "maintainable code" == "readable code" == "self-documenting code" and that's very easy to achieve with Perl. Unfortunately most of the Perl found on the web and in Perl books set bad examples for those learning Perl such as abusing the default variable $_, abusing regex for simple string operations, using procedural code where an OO model would be more clear, abbreviating names of variables and functions to just a single letter, using Perl's obscure built-in parameters without explanation, and using all of the above to create obfuscated one-liners to perform complex tasks. All of these bad habits have spread like a virus into the habits of Perl coders and it takes time to break these habits.
Unfortunately some shops think the answer to sloppy Perl code is to replace all Perl code with <my pet language> as if that will make everything better but instead the new code is just as unreadable because it encourages different kinds of bad habits. And I'm sorry to all you LISP fans here, and this may even get me banned from this web site, but hooray for you because you can emulate Google PageRank with 5 bytes of LISP code that throws the LISP interpreter into some obscure self-awareness mode that transcends human understanding but is that readable? Is that maintainable? Is that self-documenting? I don't think so. Yeah, that's cool you can do that but I'll stick with Perl, thanks.
"CPAN is the key to Perl. Lots and lots of code that Just Works."
The problem with CPAN is that a lot of times the stuff on there only just works with certain platforms. Besides, with Google, the advantage of having a CPAN is neutralized.
> with Google, the advantage of having a CPAN is neutralized.
I could not disagree more strongly. Perl has CPAN, R has CRAN, Ruby has Gems... why does this pattern recur, over and over, in successful languages? Probably because it works. Someone is working on a problem, thinks "gee, I wonder if someone else has solved this in insert language here??" In some languages they get to head off on a wild goose chase via Google. In others, they type 'install Foo::Bar' or 'install.packages(fixMyProblem)' or whatever, and with luck, continue on their merry way, NOT switching contexts or handling an interrupt. From a programming perspective, THAT RULES.
Google does not solve all problems, not by a long shot.
> Perl is horrible, ugly, unclean, unmaintainable in the general case, inelegant
Bollocks. It has some bizarre vestigial organs and functional redundancies from its evolution, but so does every language. Sometimes it's easy to take concision too far, but you prefer the alternative of mandatory verbosity?
Go look at some of the things people are doing with Moose and POE and try to claim inelegance.
I think it's just these two articles so far (considering the link in the opening line of the article). Which is probably a good thing, since they'd all be pretty similar:
"Don't learn [interpreted language X]. It has [features A, B, and C] that you will miss when you have to go back to programming in [more popular compiled language Y]. You'll be so frustrated with [Y] that you'll have to quit your job to work full-time on [X] -- which is coincidentally what I plan to do."
Don't learn Tcl. It has Tk, Expect, Interp, Tkcon, wiki.tcl.tk that you will miss when you have to go back to programming in Arc.You'll be so frustrated with Arc that you'll have to quit your job to work full-time on Tcl -- which is coincidentally what I plan to do.
I downvoted you because I think discouraging learning is a bad thing in general. Perl may be ugly in some cases, but it also has some good ideas. Even if it's the worst language ever, though, it would still make sense to learn it so that you would know why it's the worst language ever. Otherwise, you're just asking someone to accept it on faith.
For me, perl's killer app these days is the one-liner.
Where python has (for me, at least) muscled in on perl's niche as general-scripting-language-of-choice, perl remains unmatched as the most terrifyingly useful extension to the command-line that ever there was.
