So what you're saying is that it's easier to come up with a from-scratch solution than to take one that's 90% there and make modifications? Ummm...
Yes. Exactly. I can usually roll my own replacement for File::Find faster than I can figure out exactly how to use File::Find correctly for the particular problem I'm trying to solve.
Sure, File::Find likely has 90% of the solution I need already written. But that 90% usually constitutes 5% of File::Find's functionality and is something I can write in a few lines in a few minutes (yes, I know the classic 4 traps to avoid when writing a File::Find replacement -- if you don't, then either use File::Find or go learn them, perhaps by reading and understanding File::Find's source code). That takes me less time than looking up File::Find's documentation and finding the bits I need in there, but just barely.
However, most of the time, I need to summarize things by directory or detect empty directories or something else that is trivial to do with a hand-rolled replacement but that is frustratingly difficult to figure out whether it is even possible when using File::Find much less do all of the extra work to cram the solution into File::Find's frustratingly restrictive call-back API.
If you have a desk whose surface is 90% big enough for what you need, it is usually easier to throw an old door on a couple of saw horses to get your needs 100% satisfied (not using the desk at all) than it is to modify the desk to add 10% to its surface. Though I'm sure it is a fine desk.
Thanks for pointing out the need for s/through/throw/, BrowserUK
|