Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Perl secrets

by BastardOperator (Monk)
on Sep 14, 2000 at 03:44 UTC ( #32398=perlquestion: print w/ replies, xml ) Need Help??
BastardOperator has asked for the wisdom of the Perl Monks concerning the following question:

I consider myself to be an o.k. Perl programmer. As in most things that I do, I long to be the best that I can. I recently posted a reply to a question "Single-machine IPC via sockets" and other things to say in the dark in which I gave example code for using Unix domain sockets.

merlyn replied with the following:
"Ahh, this uses the ugly %SIG-handler code that breaks servers sooner or later. There are better ways to reap kids. I have a few samples in my columns. Best look for examples that use a no-wait waitpid at strategic points in the top-level loop."

Excellent! I learned something today (as I do most days :^) ). The thing is, where does one find information like this. I'm not a computer scientist, I haven't studied algorithms, I don't know too much about the BigO theory, and I don't have a ton of programming experince (~ 1year). So, where do I find this stuff out ahead of time? I've got a couple programs with that "ugly %SIG-handler code" running currently, and I would've continued the same way had merlyn not said anything.

Is a book like Advanced Perl Programming the answer? Or is it really just a matter of experience, having things break or not work optimally, before I'll know and be able to spot these things ahead of time? I try to keep up with the newsgroups and this site, but apparently there's some things that I've missed. I'd love an all-inclusive answer, but 50 url's to web-sites would do :^).

Comment on Perl secrets
Re: Perl secrets
by merlyn (Sage) on Sep 14, 2000 at 03:54 UTC
    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

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

Re: Perl secrets
by tye (Cardinal) on Sep 14, 2000 at 07:22 UTC

    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".

            - tye (but my friends call me "Tye")
RE: Perl secrets
by swiftone (Curate) on Sep 14, 2000 at 19:09 UTC
    Is a book like Advanced Perl Programming the answer?

    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>.
RE: Perl secrets
by jlawrenc (Scribe) on Sep 14, 2000 at 21:45 UTC
    After programming Perl for a year or two. :) I have a couple of things I could add.

    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?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://32398]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (5)
As of 2014-08-01 01:28 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (256 votes), past polls