Re^2: Five Common Misconceptions While Learning Perl

[Anonymous Monk]

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

[revdiablo]

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.

[Anonymous Monk]

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.

[revdiablo]

I would say voting systems have a higher standard than the majority of other applications. In that case, your point holds some water for me. For almost every other application, though, your standards strike me as extremely unrealistic. You're free to hold yourself to these rules, but using them as a measuring stick for others is going to lead to a lot of disappointment.

[Aristotle]

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.