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).
The CPAN modules are pretty useful, especially DBI (databases) and Mechanize (automate website interactions).
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/.
Start with man perl, then read the following: perlintro, perlreftut, perldsc, perlretut, perlboot, perltoot.
This should get you started then read all the others, get the Camel book which is the defacto reference.
And write as much code as you can (which is really true of learning any language.)
Dropping into #perl on EFNet (now on freenode) used to be helpful, but it doesn't look like it anymore.
You could learn via web and man pages but perl is weird enough so that the Learning Perl workout is valuable.
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.
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.
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!
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.
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)
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.
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.
- b
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?
Seaside: http://www.seaside.st/
PLT Scheme: http://www.plt-scheme.org/I am looking forward to a time when O'Reilly's Programming Arc exists. It's still too early for that, though.
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 why start a new comment? This is what the "upmod" feature is for!