Do not learn Perl
ubermonkey.net
ubermonkey.net
You'll see
Dictionary someDic = new Dictionary();
And dream of
%someDic = ()
someDic = {}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.
$someDic = {};
?
In short, if you wish to keep your sanity, do not learn how to use a pen and paper.
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)
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.
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.
I only mentioned websites to be fair to Perl.
"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.
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.
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.
"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."
Wow, It works!
Please downvote this comment so I can pay for behaving like this was a different site.
+1, Contrite!
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.