Most of Perl is documented by the originators, better than most things I've had to wrangle.

Many of the books out there contain good stuff, but many more contain bad stuff. Trust is important, or experimenting or cross checking for verification.

You can "ask an expert", either directly (usually for pay) or in a community setting, like the Monestary, IRC, or Usenet.

Or, you can just bang on it a bit yourself until you find out that it breaks (or doesn't) to your satisfaction.

There's nothing I know that wasn't found out from one of the above. It's not rocket science (but even rocket science fits the above {grin}).

-- Randal L. Schwartz, Perl hacker

Ok, a few more questions then, one by one:

Most of Perl is documented by the originators, better than most things I've had to wrangle.
I agree fully! Perl has been a joy to learn because of this, but that code came from the Perl documentation, so now I'm slightly wary of it.

Many of the books out there contain good stuff, but many more contain bad stuff. Trust is important, or experimenting or cross checking for verification.
Very true, anything that you would highly recommend after Learning Perl, Programming Perl, and The Perl Cookbook?

You can "ask an expert", either directly (usually for pay) or in a community setting, like the Monestary, IRC, or Usenet.
Yes, but I often don't know to ask. I never would have known to ask about the %SIG-handler code, it's most places that I've ever looked for info. It would be nice if someone at work coded some, specifically Perl, ya' know, someone to peruse my code on occassion, but there's nobody.

Or, you can just bang on it a bit yourself until you find out that it breaks (or doesn't) to your satisfaction.
I guess this is what I'm left with, it's the best way to learn really, but takes much longer. I suppose that if you were my father, I'd only want to "figure it out for myself", but I'm past that stage of my life now and I'm ready to "learn from other people's mistakes". Damn :^) where's Dad now?

There's nothing I know that wasn't found out from one of the above. It's not rocket science (but even rocket science fits the above {grin}).
yeah, not rocket science, just computer science :^).

anything that you would highly recommend after Learning Perl, Programming Perl, and The Perl Cookbook?

Well, allow me to plug that other book that I make a few cents from, Effective Perl Programming.

After that, it really depends on what specific Perl application area you are looking at. I have a list of books I would spend money on, and you can check the reviews there.

Yes, but I often don't know to ask. I never would have known to ask about the %SIG-handler code

Yes, one of the suckiest things about not knowing is not knowing what you don't know. So that's why we have peer review, design review, code review. No man is an island, especially that one the survivor people were on.

It would be nice if someone at work coded some, specifically Perl, ya' know, someone to peruse my code on occassion, but there's nobody.

But think of the experts you have here! Maybe I need to get vroom to create a section called Code Review, where we could post snippets (perhaps anonymously, with a private feedback link) and let others issue code review, but telling still others that this is perhaps questionable code.

---

update: see Code Review section, anyone?

---

-- Randal L. Schwartz, Perl hacker

I see only one problem here, it's with the Or, you can just bang on it a bit yourself until you find out that it breaks (or doesn't) to your satisfaction. part.

When the realization that it breaks comes with a hacked computer or a bunch of corrupted files, the price might be a little steep.

Is there anywhere a list of "The things you will never guess but that will get you fired anyway"? Things that will cause problems only under circomstances that are difficult to produce in a test environment. Things like flock's, or Taint mode come to my mind but I am sure there are some more out there, and I am scared ;--)

Actually, I can think of a lot of things that I know only from participation in forums like this. These tend to be things that someone else found out by banging on it. Some of them actually get officially documented somewhere but I think many of them still aren't.

Another good source of undocumented secrets is the source code (the source code for Perl, for modules, for the Microsoft C RTL).

The problem with %SIG handlers has been discussed a few times in the comp.lang.perl.* newsgroups (I don't read comp.lang.perl.misc anymore so it was probably most recently in comp.lang.perl.moderated).

Another great forum is p5p. I subscribe to the weekly summary but we've had another long gap in summaries so I'll have to resort to schlepping the web archive for interesting threads if I want to stay "on top".

Others have given good suggestions for other answers (And I second merlyn's recommendation of Effective Perl Programming. I just got a copy and it's full of the little subtle tricks that you can normally only gain through experience).

What I can add is that I don't recommend Advanced Perl Programming for topics such as GUI's, signals, or sockets. I've just finished my first sockets based program, and APP didn't help beyond learning to use the IO::Socket and IO::Select commands. I used to recommend APP for learning Objects and Modules, but now the perlboot, perlobj and other pages are actually better documentation for it. APP skims the surface of the advanced topics you're looking at too lightly.

On the other hand, I thought the treatment of references in Effective Perl Programming was quite good--it's one place where I think it's <Heresy>better than the Camel book</Heresy>.

Effective Perl Programming is excellent. I would grab it every once and a while and read a section. Do that enough times and its bound to sink in.

The same goes for The Perl Cookbook.

Depending on what you do, have a look at Mastering Regular Expressions.

Do you have a Perl Monger's group in your area?