I would also recommend a hard smack in the head with some OO language like Java (and I don't even think Java is all that OO; it's just OO enough to be disruptive)

And a kick in the face with something functional like LISP/Scheme.

What I mean with the above two lines is: nobody can be a good programmer without *really understanding* OO and functional programming.

the great thing about perl is, that you can actually use *most* functional and OO techniques without being forced to.

update: more than any book I know, the camel book will teach you "the perl way" - i.e it will explain how to do stuff and why. I can recommend many more books, but if you're going for perl, it's at the top of the list for me.

What method(s) have proved most successful for you?

I learned algorithms and other useful programming paradigms (e.g, functional programming, recursion) from years and years of university classes. This high-level stuff can apply to any language, and is just as important as knowing a language well enough to apply it effectively. It took a lot more time to become really comfortable in the computer science, compared to the programming. I feel like I have all the programming skills I will ever need, but I can never learn enough computer science.

• code written by people besides me (esp. at PerlMonks)
• perldoc -f {function} or just  perldoc perlfunc
• perldoc perlre
• perldoc perlunicode / Encode
• perldoc {Whatever::Module::ImUsing::JustNow}
• perldoc {some_pragma} (e.g. strict, utf8, open, ...)
• perl -d some_prog or  perl -e 'test code...'

The ranking is based (approximately) on correlates well with the number of times I've used each resource in the 12 years that I've been using Perl, and/or the total time spent with each resource. (Update: these are all sources that I still use often.)

I first started learning perl by working with a fairly large and elaborate (multi-source-file) app that was written in Perl 4 by someone else. I didn't really have time to read a whole book...

During that early introduction phase, I recall being astonished, first of all at the relatively low proportion of alphabetic characters in the code (the app was heavy on regexes and substitutions), and secondly at how quickly I was able to read it with comprehension and adapt it (partly because I already had the basics of regexes from using unix "grep/awk/sed").

The basics of syntax were never a problem for me, since it was close enough to C to be comfortable, and the sigils (back in the perl4 days, at least) were very easy to grasp -- having read their description once (I don't even remember which perldoc man page I read it from), it just stuck with me. I'm sure perldoc perlintro came in very handy in the early days, but by now I hardly remember looking at it.

(I'm not sure I would find it so easy if I were to start from scratch these days -- things have gotten more intricate and subtle, esp. with the sigils...)

To begin with the bundled documentation just start with perlintro and follow the references provided when you come to a section of the language that you need more information about.

On a *NIX box this is as simple as this command;

$ perldoc perlintro
[download]

While I agree with you for the most part (in that perl has *very* good on-line documentation/man pages) I personally don't *learn* very well from man pages and prefer a gentler/more readable introduction to new languages & concepts.

That's why I recommended the "programming perl" book.

To the OP: if money is tight, or you're comfortable with reading documentation in fairly short - and not too related - chapers, go for the online man-pages. Otherwise, I would still prefer to recommend the "programming perl" (and "learning perl") books from O'Reilly as the the first steps.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

These 2 books often get mentioned. They're quite high level. I found HOP fairly tough going but well worth it. At about that level I absolutely love Perl Hacks and particularly APP2. They're a good read, and guide you through lot's of wonderful Perl trickery. I feel they still work as tutorials even so. HOP, by contrast, concentrates on the functional programming you can do in Perl. Really great book, though.

At a slightly lower level, I tend to think (this is going to sound *very* trite) that the best way to learn is by having fun. (yuck). If you enjoy discovering things, they'll stick. Also, some people prefer books, some people prefer just getting stuck in and start coding.

In reality, you have to do a bit of both, of course. You need a good tutorial (I'd say Learning Perl, the perl docs, and online help. Whilst Programming Perl sits open on my desk practically every day, I wouldn't recommend it to beginners) Then get thinking how you can use perl to better solve one or two problems, and see how others did it, too.

Finally, Perlmonks and meeeting other Perl programmers is invaluable for the discussion.

Again, YMMV. Plus of course CPAN and here (perlmonks).

Cheers
Chris

What method(s) have proved most successful for you?

I can't really single out one method that works best. I'm much happier with a combination of methods.

• I've been a member of Perlmonks for close to six years. I just finished a period of visiting only occasionally, and I'm now back to reading and posting more often. Sometimes searching for an area that I'm working on will provide me with a two year old post that exactly answers my question -- fantastic! Sometimes I have to ask around.
• I've been going out to Toronto Perlmonger's meetings for about the same amount of time. It's like taking a post-graduate course -- with that many bright people in the room, there's bound to be some really interesting comments. The beer afterwards is fun as well.
• I've used the #perl channel on IRC intermittently, though more often over the last year. IRC is a weird animal -- don't take it too seriously and you'll be fine -- but keep in mind that there are also protocols and customs, not unlike Perlmonks. Even just hanging out and answering the odd question is cool -- and sometimes a question will be posed and answered that is really useful information. It can also get pretty noisy.
• I surf through CPAN looking for stuff -- keeping in mind that if I need to choose between something that was updated last week and something else that was updated in 2002, the newer package will usually win.
• I spend lots of money on O'Reilly books. Tim O'Reilly has been a supporter of Perl for some time, the O'Reilly books (with a few exceptions) are solid, amusing, well written reference books. My copy of the Camel is well-thumbed, and I continue to learn new stuff -- for example, I'd always known about positive lookahead, but never needed it until a few weeks ago. A bit of fiddling around and I had it working fine.
• When I can, I love to go to YAPC and immerse myself in Perl for three days. It's very neat to meet some of the folks in the community, and hear them explain their thinking behind a feature, a module, or the entire language. And, of course, there's the opportunity to drink beer.

• On-line tutorials; and
• Certifications (useful for HR people and managers who don't program -- but that's a whole different flame war).

What method(s) have proved most successful for you?

Same method I use to learn almost anything I do with some notable exceptions. Read up on it, talk to a few folks already doing it, and go do it. Taking up skydiving or something like that needs more hands on instruction! :-)

My method of learning Perl was to take a collection of Korn shell scripts that I used to do my backups at AT&T Bell Labs and convert it to Perl. My goal being to eliminate all the pipes and temporary files that I was using to get the job done. Part of the task was tracking what files systems and files were being backed up to what media in an HP Magnetic/Optical disk jukebox across 32 slots.

One of the clever things that the backup method used in the end was to create a partition on one of the pieces of media that contained everything to recreate the backup and restore suite that I had created including building Perl itself. But I digress.

Over the years I wrote Perl scripts in a vacuum of sorts because I was the only one in my immediate circle writing the stuff. That was until I ended up at Perl Monks. Then I found out that a lot of what I was doing was not ideal. (I won't say wrong... just could have been better.) So it is here at PM that I was able to hone my skills getting feedback from other Perl folk at my meager attempts and scripting.

TheDamian convinced me that my brain has been temporarily stored in a Mayonnaise jar on the front porch, and it can be retrieved with a snippet of perl. I hope I can run it before I wake up!

Beyond thinking out of the box, dominus taught me that there is no box. We are better off without boxes.

Many monks have been very very good to me. Thanks!

external links below
I have made great friends at the local Perl Mongers meetings. I have learned much more beyond Perl there!

I am grateful to my employer for providing the opportunities to learn at OSCON.

As a reference book, I like the O'Reilly (Camel) book "Programming Perl" by Larry Wall, Tom Christiansen & Jon Orwant.

Best wishes, and welcome to Perl.

Hey Larry, if you get rich selling locks of hair on Ebay, I would appreciate 10% :-)

I picked up Perl in the mid 90s, after hearing a lot about how much easier it was for certain classes of task, like networking. I used the pink Camel and friendly Perl folks online to do an honors project for my networking class. Later, I picked up Perl 5 as a side thing at my C/C++ job, and then moved on to doing Perl full time.

I don't know if it's still the case, but at one point, conventional wisdom was "If you know how to program, start with the Camel; if you don't, start with the llama". A lot of books have come out since then, and YMMV.

These days, I use the Camel and the cookbook as references, and PerlMonks for learning.

Early 1997: I was asked to put a guessbook on the website, so I got one from Matt's Script (yes that one), made some insignificant modifications, got it to run, and was amazed of new thought on what I can do with programming. Interesting to learn more (I didn't care much then that it was "Perl"), a friend gave me the Llama book. But lacking of programming experience or some computer sience background seemed to be the biggest obstacle for me to grasp the content. My brain was like suffering digesting problem.

Months later, I found a short introduction by Selena Sol. It described how to program (CGI) with Perl in a very simple way. Few lines of theory, straightforward examples, and just what I needed to know to start my own (CGI) programs. I was specially deligted with qq() and "here-documents" (I saw a lot of \" in that guestbook program). I also learned later that beside online resources, in front of my nose, there is a bunch of excellent Perl docs I could (and still can, of course) with man perl, man perldata, etc. Feeling enligthened, following the manuals was enjoyful.

Later, while I still wrote,

print <<HTML;
Username: <input type="text" size="10" name="username"><br>
Groups: <select name="group">
<option value="1">user
<option values="2">devel
<option values="3">sales
<option values="4">marketing
</select>
...
...
HTML
[download]

print textfield(
        '-name', 'username',
        '-size', 10
      ),

      popup_menu(
        '-name', 'group',
        '-values', [1, 2, 3, 4],
        '-labels', {
            1, 'user',
            2, 'devel',
            3, 'sales',
            4, 'marketing',
        },
      ),
      ... etc
[download]

I said, "Cool! What is it?". Now I got introduced to CGI.pm. My excitement was boosted.

But, I wasn't always sitting before the computers, so I thought that I needed a printed material so I could read it wherever and whenever I go. Somehow I forgot to got back to the Llama. I wasn't aware about other great Perl books. They weren't even in the local bookstore. I couldn't buy it online. I didn't have a credit card, and I couldn't afford it, after all. So I turned back to the local manual pages, and decided that, "This is my printed material resources!".

I didn't use Linux yet, that time. Workstations at office mostly use Win98. So how did I print the manual? Remember the old telnet program in Win98? I used that to login to the server, and executed man perl... commands. I copied-pasted a screen after a screen, use a word processor to layout the text (making heading, monospaced the code sample, etc). When editing was done, I just then printed it using dot matrix printer on the continues form paper, waited patiently until it completed, bearing with the noise, and apologized to the people. Basically, I had "one book" for each man page. I brought them everywhere, proudly answer what it was when friends asking. I read them on the go, on the bed, wherever and whenever possible. I got back to the computer to practice what I've just learnt. So it went, starting from perldata, perlsyn, and so on, for the rest of the year.

Early 1998: I became more confident with Perl. Something called PHP came along. Uninterested. I moved on to perlref, and there I got stuck. I just always took it in the wrong way. I even wrote,

sub afunc {
  my($x, $y) = \@_;
}
[download]

I can't remember how the enlightenment came to visit, but it was when reading the perldsc. And another pandora box opened. Moving on to perlobj, perlmod, and, perltoot "books" was fascinating. I'm not saying it was easy, but it wasn't as hard as when I started to learn Perl. Unfortunately, I stopped on perlembed "book", and didn't even open perlguts. Later, I started to read "real books", and other Internet resources, as well as the printed TPJ (office subscription).

Still don't understand C, until now. But I was happy with Perl, already. The rest was just history. I heard about Python. Interested, but dropped it soon. Still didn't pay attention to the evolving PHP. Java later provoked with full of buzzwords, but never interested. JavaScript was entirely different beast, but went side by side with Perl. And I think that I "suffered" this "hammer syndrome". I learnt more about programming, understanding more on OO, and even enjoying my software engineering experience, at general. All with Perl, and other languages (by literature comparison). In short, I was happy with Perl.

Well, I'm happy with Perl!

Books I have found helpful (links to Amazon):

• Programming Perl (3rd Ed) (a.k.a. the Camel book)
• Perl Best Practices
• Effective Perl Programing (a.k.a. the Shiny Ball book)
• Network Programming with Perl

Books I have heard enough good things about to recommend even though I have no personal experience with them:

• Learning Perl
• Higher Order Perl

In the begining I learned the most from 'Learning Perl' book I borrowed from a local library. Later on I read 'Programming Perl' which was a real fun. (And yes, 'Learning Perl' was fun too.) After that, getting friendly with 'perldoc' got me a good ride, and I'm on it all the time.

I own a few Perl books, but rarely read them now, unless on some boring sunny afternoons.

I never used any of those beginner-tutorials for Perl.

Rudif

I would not say I'm even close to enlightenment yet, but I think I can give you some suggestions.

Plain and simple. Find work that is challenging (in Perl, of course) and your first impression is that you can't do it. You know, that project you've just got and it looks daunting so you'd rather take on something else? Just go ahead and take it on. You'll learn a lot on the way.

I'm not saying this might work for you. Its just how I learned most of my current Perl skill set.

As the maxim goes, "Only Perl can parse Perl". Therefore the only logical conclusion is that you wrote Perl.
Hey, wait a second, Larry, is that you?

Um, no. I'm working on my third or so Perl parser right now, depending on how you count. And the hard part of parsing Perl is not actually the parsing, it's the lexing, so this parser will write its own lexer automatically, because I'm too lazy to write any more lexers.