On Thu, 10 Oct 2002, Paul Makepeace wrote: > > This puts me in mind of the extreme programming "you're never going to use > > that" essay. A 20 character idiom that works on all the platforms you're > > planning on it running on can either be used directly, or you can call the > > Perhaps an indirect side-effect of this approach is that people will see > that 20-character idiom and then copy it. Which would be a shame, since > it's wrong. (The one posted misses colons as separators, and there are > plenty of Macs about that use that, not to mention DOS J: drive > prefixes etc.)
Using idioms that way is indeed Bad and Wrong. The way I see them, and I'd kind-of assumed that perl programmers who aren't of the cargo cult variety see them, is as a bit of magic that they might not have been able to originally come up with, but which when you are presented with, makes sense, and in a lot of cases, teaches you something about the power of the command it's built around. > If people are going to learn by copy/paste then it's preferable surely > they copy use Module;... If it's an area they know nothing about, then they'll undoubtedly learn a lot from reading the pod, avoid common assumptions about the problemspace, and possibly even find that the module solves more of their problem than they were originally having difficulty with. > For example, couple of months back I spent an unholy amount of time > debugging some damn tool that hardwired assumptions about its > filesystems (hfs,ufs,ext2, etc) so that when a couple of machines were > installed with ext3 it failed, but in an unbelievably oblique way. > > It's time like those you come away frothing "just use a frickin' module..." Surely you read[2][4] the documentation[1] which included all the assumptions[3] the software was based around. the hatter [1] because it always exists [2] and it's always read [3] and it's always complete, and current [4] mmmm, non-sequential footnotes as a literary technique
