in reply to Paradigm Shift - Don't use strict
In Object Oriented Perl I show a few examples of (what I consider to be) reasonable uses of the ref($class)||$class idiom (e.g .section 4.2.1 and section 12.3.5).
Of course, this does not consistitute "cargo cult" programming because I (presumably) deliberately chose to use the technique and (presumably) know why I'm doing so.
And I guess that's the point: that there's nothing wrong with using just about any technique -- if you know what you're doing and why it's the appropriate thing to do.
For example(s):
- I rarely use strict in my modules.
- I often use a roll-my-own export mechanism, rather than Exporter.
- My code brims over with symbolic references and typeglobbing.
- I almost never write comments.
- I'm not averse to using a well-placed goto (or twenty -- e.g. Switch.pm).
- I often provide multiple interfaces to a module.
Am I cargo cult programmer? I doubt it. After all:
- I rarely use strict in my modules...because I rarely make the kinds of mistakes that use strict catches and (more importantly) because I know to turn it on when confronted with an otherwise-mysterious bug.
- I often use a roll-my-own export mechanism, rather than Exporter...because I find it much easier that way to get exactly the behaviour I need.
- My code brims over with symbolic references and typeglobbing...because that's the kind of under-the-surface program manipulation that my ideas often require.
- I almost never write comments...because, if the code itself isn't enough of a comment, then I know I probably need to rewrite it.
- I'm not averse to using a well-placed goto...because it's occasionally the very best solution to a complex control flow problem.
- I often provide multiple interfaces to a module...because I know that different people like to think -- and code -- differently, and that "intuitiveness" means eleven different things to ten different people.
What about someone else who doesn't use strict, who rolls their own exports, references symbolically, fails to comment, indulges in the occasional goto, and who multiples interfaces without necessity? Are they a cargo cult programmer? Maybe so. Or maybe not. It isn't what you do...it's why you do it.
Rules are not sacred. They're merely social mechanisms, provided to protect the inexperienced, and to streamline things for the experienced-but-working-to-an-impossible-deadline. Cargo cults are just sets of rules with sociological bases, rather than logical ones. They're all about programming the way Granddad used to program, not because I understand why Granddad did things that way, but just because Granddad did things that way...and it never did him any harm!
Is that an acceptable way to operate? Well it wouldn't be for me, but it might well be for you, or for her, or for them. And if it makes your/her/their code harder to maintain, perhaps that's a small price to pay for the valuable lesson that hardship has to offer. And perhaps it's a price the majority are happy to pay in exchange for the emotional comfort of doing things in the familar way.
Is merlyn right to disparage such coding practices? Almost certainly, since that's what he's being paid to do. Does that condemnation translate to a universal proscription? Almost certainly not (nor do I think merlyn thinks it does).
The trouble is, by just looking at the code (absent the coder) there's no way to tell whether one is seeing the results of superstition or satori. But that's the essential issue.
As the Jargon File illustrates in its Zen-like appendix:
A novice was trying to fix a broken Lisp machine by turning the power off and on.Or, to misquote from The Fifth Element:Knight, seeing what the student was doing, spoke sternly: "You cannot fix a machine by just power-cycling it with no understanding of what is going wrong."
Knight turned the machine off and on.
The machine worked.
"What" is not important. Only "why" is important.
|
---|