in reply to Perl secrets

Information is obtained in many ways, young grasshopper. {grin}

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

Replies are listed 'Best First'.
RE: Re: Perl secrets
by BastardOperator (Monk) on Sep 14, 2000 at 04:08 UTC
    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 :^).
[reply]
      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

[reply]

      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 ;--)

[reply]
        Well I tend to be good at finding bugs, so you can always use me as a windshield. :-)

        Seriously, if such a list was readily producable, it would likely be readily fixable, and therefore already fixed. Most of what is out there that can go wrong will be found by someone banging into it. But while that does happen, I have been so far happy with how well Perl stands up to some serious abuse.

[reply]

In Section Seekers of Perl Wisdom