Language wars aside, what is the best way to learn Perl if one wants to use it primarily for web development? There are so many books and websites out there, it's hard to separate the good from the bad. If it helps, I am pretty proficient in PHP and know the basics of Ruby and Python.
I also recommend Catalyst/DBIx::Class. It's a deadly combination. Both are totally modular, so you end up creating a really flexible system when you build a large application. I recommend using Catalyst under FastCGI with nginx (using TCP to connect to your FastCGI processes.)
The best way to learn any language: Write something in it! Think of a particular webapp you want to build, and do it (referring to a book/CPAN/anything else. Perldoc is useful to learn specific syntax.
The CPAN modules are pretty useful, especially DBI (databases) and Mechanize (automate website interactions).
Perl has been my primary language since 2000. I would learn it in the context of building an application. Read chapter 1 of the Camel Book (the basics), which you can get online. Then just jump in and search the web or look in the book when you run into problems.
Note: tons of stuff has already been done for you at CPAN: http:://search.cpan.org
I've also found the Perl Cookbook and Mastering Algorithms with Perl somewhat useful. However, much of their content is now in bits and pieces on the Web, and so searching for your specific problem often is enough. If you don't know the site already, check out http://perlmonks.org/.
I left Perl behind some time ago, but I second epi0Bauqu's recommendation of Perlmonks. It's quite an amazing community and resource, and well worth exploring.
The best book for learning the language is "Learning Perl" published by O'reilly. If you work through all the exercises you'll "know" perl well enough for doing most things. Also helpful is the Perl Cookbook. Contrary to other advice, I didn't find Programming Perl (the camel book) as valuable as Learning Perl.
You could learn via web and man pages but perl is weird enough so that the Learning Perl workout is valuable.
benreeseman somehow missed the bit which said "language wars aside"!
If you're learning Perl for web development, after you've got through the Camel book and the basics, you would go to PerlMonks, as many have said, and I'd say the main task before you is to get to know the various templating systems.
There's a progression of using perl for HTML and it goes like this:
1) hundreds of annoying print() statements
2) fewer print() statements because you've discovered HEREDOCS, but still annoying
3) using a templating module
and in my case it was 3 a) using a templating module badly then 3 b) using a templating module properly.
So check out the options like HTML::Template, Mason, Template::Toolkit, and so on to see what they do.
My day job is basically as a feature programmer for a perl based web application system. Trust me. Learn python / ruby for web applications. Or stick to PHP.
The thing that made people love Perl is the same thing that makes more mature people hate it. The language is so flexible that you will invariably write bad code. You need a very strong set of coding standards if you'd like to write perl systems that remain maintainable.
Learn python or ruby to make your web app. Learn C# / ASP.Net if you'd like to be on a windows stack.
I've got different advice. Don't start with a full blown web app. Getting perl and apache and a db going can complicate the issue a bit.
Start by simply replacing some bash scripts with perl instead. Everything you can do with a shell script, you can do better with perl. When I was starting with perl, I started replacing my init scripts with better perl verions on my Fedora system. You'll be pleasantly surprised by how much shorter and more elegant init scripts become in perl!
I work in a company that writes almost everything in Perl, and as a result I have personally written tens of thousands of lines of the stuff, and I maintain and debug several times that amount. This code is used for everything from serving web pages to interacting with carrier SMS-C to number crunching. So believe me, Perl is definitely the devil I know.
That being said, the only advice I can offer you is unsolicited: don't learn Perl. Perl is a very powerful language in a lot of ways and in its day it was the only game in town for serious rapid development. It is fundamentally broken in a lot of ways though, and unlearning the brain damage that you will get from becoming a Perl expert could take a very long time (it has taken me years). I won't launch into a diatribe about these language characteristics unless you ask me to, but do not doubt that I could.
People talk a lot about how great CPAN is, and it does have a certain charm, but it is ultimately more trouble than it is worth. There are CPAN modules for everything, but just as often as not they are flawed or buggy or too limited and you don't realize this until you've sunk a considerable amount of time into the problem. Just the other day a colleague wasted an afternoon trying to get LWP::Parallel to work as advertised before realizing that it could not be done.
Perl is great for building prototypes, but when you go to deploy the stuff you realize that DBI fundamentally can't do connection pooling in the way you want, and mod_perl has an execution lifecycle that can only be described as 'whacky' (depending on how you include your handler modules, sometimes mod_perl will simply stop evaluating your module when it reaches an error, leaving your symbol table partially filled in with no error warning), and once you've used a couple of CPAN modules they'll all invite their friends and those friends will invite their friends and pretty soon your Apache children are using 15-50 megabytes of _unshared_ memory each. Yeah that's right, the interpreter goes and touches a bunch of pages of Perl 'code' post-fork and blows the COW and now all your RAM is belong to mod_perl. It's really cool when an 8-way Xeon server with 16GB of RAM can only handle a couple of hundred req/s before it starts faulting and crashing Apache children on malloc.
Do yourself a favor and use Ruby instead. Ruby is so much like Perl that you can almost call it a dialect, but just not quite as broken. Pretty broken still, but not nearly so broken as Perl. It has all of Perl's good characteristics and only most of its bad ones. And if the availability of libraries, or the lack of decent threading or other deployment characteristics bother you, then use JRuby which is now basically the fastest production Ruby and can call into all of the Java libraries (which _can_ do connection pooling in the way that you want). Personally I prefer Common Lisp and Rhino but you can't go too wrong with JRuby.
If you go the Perl route you will definitely come to regret it.
Truer words were never spoken. This is from one who once frequented perlmonks.org and thought himself great for doing so. I'm thankfully past that stage in my life. I encourage others to skip over it entirely.
Two things are certain in life: every language has its pluses and minuses, and every person has an opinion.
There are lots of things perl is bad at, but it has a lot of strengths, especially if you work in the biological space. I also know several successful internet startups that run on perl, so I have to disagree with benreesman's advice to not learn perl.
Is it good for everything? No. (and no language is)
If there are libraries for doing biological computation written in Perl that do not have available bindings for other languages then that would constitute a reasonable excuse for using Perl. This would be just as true if the library was only available 1990s Visual Basic, and is just as irrelevant a factor in the assessment of a language as a whole.
Beyond the availability of some particular piece of code (in my case the tens or hundreds of thousands of lines of legacy systems that I lack the resources to replace) there is literally no excuse for using Perl or for inflicting its insanity on another hapless generation of web programmers.
All of Perl's admirable qualities (convenient object-literal notation, first-class functions, correct Scheme-style lexical scoping, powerful and seamless regular expressions, convenient string processing and Unix integration) are available in other languages. All of them, period. Many of these languages do not share Perl's unforgivable faults (sigils to dereference variable namespaces, contexts, typeglobs, references, dismal error handling facilities, confusing and nonstandard object facilities). The only way to use Perl to build a large system is to lean on Conway's methodology, which consists of a book that reads like an airtight indictment of Perl by one of its chief implementors and a collection of CPAN modules that demonstrate a brilliant mind with a perverse allegiance to a cult-like cause. Do sensible class hierarchies without Class::Std, I dare you. Do reasonable try-catch-finally exception semantics without Error.pm, I dare you.
try { ... } otherwise { ... } finally { ... }; # works
try { ... } otherwise { ... } finally { ... } # no trailing semicolon, oops I just clobbered your next statement and produced a catastrophic failure that even an experienced hacker could stare at for hours without seeing
It only takes about two hours reading 'Perl Best Practices' to realize that it's a brilliant book, written by a brilliant mind to attempt to make Perl a workable language for building large systems. It's a shame because he comes so close, but it turns out you can't rewire a language like Perl with libraries alone, even if only because you can't compel others to use them.
Perl is a language for expert hackers only, no one else should be allowed near it. And even expert hackers are working harder than they need to because there is a constant intellectual tax on the inconsistency of the language. It only offers a little bit more power than Python, and actually less than Ruby at a much higher cost.
There is no excuse for Perl in the 21st century, and you clearly have not spent time trying to use it to build large and complex systems or else you would feel the same outrage that I do than anyone would continue to contemplate it.
I liked Ruby, but one of the things that turned me off from it for web development is deployment: not only do you need a server in front (such as Apache or nginx), but then you need to also monitor the couple of Mongrel servers for your app, which take up quite a bit of memory. Since I'll be using a VPS with only 256-512MB of RAM and want to create a couple of sites, I don't see Ruby as being a good solution.
I don't personally use Ruby very much, if for no other reason than it seems to invoke my innate fear of Perl ;)
That being said, JRuby is a seriously reasonable choice for a production dynamic language. I use Rhino instead because I think JS 1.7 is a better language, but you can't go wrong with either one. One of the nice things about using a dynamic JVM language is that you can have the all of the really nice benefits that Java offers for infrequently changing infrastructure code (checked exceptions, mostly) without any of its drawbacks for prototyping or rapidly evolving web logic (no first class functions or object-literal syntax).
If you find yourself interested in Rhino but put off by the somewhat unapproachable state of the language in general then let me know, I have some code that really bridges the gap that I'm in the process of preparing to be open-sourced but I'd be happy to share it with anyone who is interested on an exploratory basis.
I disagree with your assessment. Perl is used in many large scale distributed computational applications. It works great and has a great developer community. The only drawback for perl is the perception that people (like you) have about it. It was born in the system admin world, but it has grown up to be a full fledged language.
Perl has a number of books, but the one that seemed most useful to me is Intermediate Perl because it covers Perl's object orientation and references in great detail. To learn the basics of the language either spend money for Learning Perl (which I would not recommend you do) or use the online tutorials and websites.
Honestly though for web development, unless you either have a legacy Perl code base you have to work with or are already a Perl guru, nearly every other option for web programming will run faster and have lower maintenance costs (in time and effort) than Perl.
Since you know PHP and have dabbled with Ruby and Python, why not take a look at Seaside Smalltalk or PLT Scheme?
I agree with the advice to read Higher Order Perl, but read Wall's (Blue Camel) book Programming Perl first. Both are fun to read, but I found HOP much more useful after reading Wall's book. If you don't already know regular expressions, read Mastering Regular Expressions. Then for additional ideas try the Perl Cookbook, also from O'Reilly. For additional inspriration along the lines of Higher Order Perl, read On Lisp by Graham, which is not about Perl, but shows how the same concepts and more are elegantly applied in Lisp. The web documents Higher Order Javascript and the Little Javascripter are interesting if you want to also understand that Javascript, like Perl is fun in the same ways that Lisp is.
This is all good advice, but I'm not sure the Perl Cookbook is a necessary component. HOP definitely is, though. Learning Perl and Intermediate Perl are great learning books...they make a nice starter before the camel (though the camel is a must-have, no matter what, so pick it up at the same time and treat it as a reference until you're ready to dig deeper).
I agree with most of the suggestions here. Read the man pages, perlintro, perlreftut, all those. The Camel book is great also. And of course write scripts. One thing I would like to add is reading Higher Order Perl. http://www.powells.com/biblio?PID=29575&cgi=product&...
I can't say, although I agree with some people who say 'don't learn perl'. I would say Learn it, and then don't use it unless you have to. I'm just starting a class on it. I only intend to use it to fix existing code, or read it to re-implement it.
Can't agree with this one enough. Also, it is better to write a lot of small scripts, than to write one big one. They will be easier to debug, and you'll get more done.
Then, for webdev I recommend Catalyst http://search.cpan.org/search?query=catalyst&mode=all with it's great doc, http://search.cpan.org/~jrockway/Catalyst-Manual-5.701003/. Catalyst uses DBIx as ORM, http://search.cpan.org/search?query=DBIx%3A%3AClass&mode..., which also has a pretty good doc http://search.cpan.org/~ash/DBIx-Class-0.08010/lib/DBIx/Clas....
Finally, I suppose you will use Apache as a server, then you must look at its doc and mod_perl one (although you can also run the perl app as a cgi).