Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re: Five Common Misconceptions While Learning Perl

by revdiablo (Prior)
on Dec 01, 2005 at 21:14 UTC ( #513440=note: print w/ replies, xml ) Need Help??


in reply to Five Common Misconceptions While Learning Perl

Excellent post. Well written, and agreeable. How did you get in my head like that? :-)

One thing I like to point out when someone plays the "I'm not using a module because I want to really learn Perl" card: a very important part of learning Perl is knowing when to be lazy. Doing everything by hand may help someone learn how things work behind the scenes, but it doesn't usually help learn how to solve real problems in the most effective way. In other words, not only is reinventing certain wheels usually a waste of time, it's counter-productive to the stated goal of "learning Perl".


Comment on Re: Five Common Misconceptions While Learning Perl
Re^2: Five Common Misconceptions While Learning Perl
by Anonymous Monk on Dec 01, 2005 at 23:14 UTC
    One thing I like to point out when someone plays the "I'm not using a module because I want to really learn Perl" card: a very important part of learning Perl is knowing when to be lazy. Doing everything by hand may help someone learn how things work behind the scenes, but it doesn't usually help learn how to solve real problems in the most effective way. In other words, not only is reinventing certain wheels usually a waste of time, it's counter-productive to the stated goal of "learning Perl".

    Using modules is only worth it if you're good enough at [Pp]erl to debug the flaws in someone else's module; this is usually even harder than debugging your own code.

    And yes, modules can contain bugs. Heck, even the perl binary occasionally has bugs; the more code you can understand and fix yourself, the less you're held hostage to someone else's failings.

    If you have the time to invest in understanding something directly, do it. Using a module is only a sound business decision if you can trust the author to have coded it right; otherwise you're setting yourself up for a pile of extra maintenance and bugfixes. Often, this involves reading and deciphering so much obfuscated module code that you might as well have coded it yourself, in a readible way, in the first place, and saved yourself the mental anguish of dealing with some foreigner's tortured notion of how to write decent English documentation.

    In short, if you want the job done right, you get what you pay for. If you're not willing to code it yourself, you have to check it yourself, and that's not better. Ultimately, you're the one responsible for the solutions you provide, so if you can't guarantee them, you can't trust them.

    Edited by planetscape - fixed the anonymonk's square brackets which were being linkified

      Using modules is only worth it if you're good enough at Perl to debug the flaws in someone else's module

      Extending that idea to code reuse in general, is using perl only "worth it" if you're "good enough" to debug flaws in that? What about an operating system? Or your computer's processor? Sure, all these things can and do contain bugs, but it's still very much "worth it" to use them.

        Extending that idea to code reuse in general, is using perl only "worth it" if you're "good enough" to debug flaws in that? What about an operating system? Or your computer's processor? Sure, all these things can and do contain bugs, but it's still very much "worth it" to use them.

        Not always, it's not.

        Diebold couldn't pitch a viable voting system based on Windows, because they couldn't prove all the failure modes.

        Any decently reviewed code will have the same issues: as a minimum, you need to audit all the failure modes for the hardware, OS, and modules, and fix them or deem them acceptable: otherwise, you have code that you MUST not sign off on.

        Advocating anything less is advocating lousy software engineering. An engineer MUST NOT sign off on sub-standard work, or he compromises his integrity, and the reputation of his entire profession. You can choose to accept or not accept a given piece component in your system, but only when what it does is well known, audited, and the risks of failure deemed acceptable.

      the more code you can understand and fix yourself, the less youíre held hostage to someone elseís failings.

      The problem with that reasoning is that the more code you write yourself, the more youíre held hostage to your own failings. Much-used modules get a lot of people bumping into all of their quirks; your own code gets much fewer beatings and will take correspondingly longer to straighten out.

      Iíve written about this elsewhere. There are good reasons to roll your own instead of using a module, but most of the time, the factors in favour of rolling your own are far outweighed by the factors in favour of using a module.

      Makeshifts last the longest.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (9)
As of 2014-12-19 01:01 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (69 votes), past polls