|
in reply to Re: Perl secrets
in thread Perl secrets
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 :^).
|
RE: RE: Re: Perl secrets
by merlyn (Sage) on Sep 14, 2000 at 04:15 UTC
|
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] |
RE: RE: Re: Perl secrets
by mirod (Canon) on Sep 14, 2000 at 04:18 UTC
|
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] |
|
|
