I think the author made it clear that this wasn't a File::Find replacement here:
There is a very notable module that helps with this task, and that is File::Find. While this is an incredibly useful module, this tutorial is designed to give you a basic understanding of recursion in Perl, and should hopefully be beneficial to you for more than just file and directory processing (though that will be the focus).
He seems to be pitching this as a learning exercise. Your node pointing out some bugs adds to the learning experience.
Perhaps it should be made more clear that it isn't production usable code, but...
Lighten up. ( /me braces for the -- onslaught :)
Update: I agree with merlyn in general, but I think
a gentle suggestion that the author update the node with
mention of the bugs and fixes would work just fine. Perhaps
it would be even more helpful for a beginner to learn
from someone else's common mistakes ? After all, this
is a forum. | [reply] |
The problem is that I consider it unethical to teach something without knowing it well enough not to introduce well-known bugs. It's just bad for the community at
large to propogate bad memes under the banner of "helping", because it doesn't
help, it hurts.
It's the equivalent to spreading rumors that could harm someone else's reputation without first verifying them from an independent source, which I also consider to be unethical. Why do you think newspapers have such strict rules on "fact checking"?
-- Randal L. Schwartz, Perl hacker
update: in response to
Update: I agree with merlyn in general, but I think a gentle suggestion that the author update the node with mention of the bugs and fixes would work just fine. Perhaps it would be even more helpful for a beginner to learn from someone else's common mistakes ? After all, this is a forum.
I would have no problem if the original node had been posted "in quotes", as in "I'm thinking of writing a tutorial, can someone review the following draft before I publish it...". But that wasn't done. It was posted as a done deal, and thus pushed my hotbutton.
| [reply] |
It creates non-portable code by reinventing a fine portable wheel
Firstly, I appreciate you pointing this out... It shows me that I was not adequately clear in my intent with this tutorial.
However, even at skimming the (original) first 3 paragraphs, it is clearly stated that I'm not reinventing any wheels!
This node is more of a "how-it-works" as opposed to a "how-to".
...until you have studied in detail why every part of File::Find is in there. Besides the three bugs I just mentioned, there's probably even bugs I can't see at the moment!
Please, before you hasten to nitpick the details of implementation, step back from your Perl-guru perspective and look at this from the standpoint of a newer programmer looking to understand something like File::Find.
To detail every part of that module, and why it's in there, would defeat the entire purpose of this tutorial. If my goal were to teach people to rewrite from scratch a new File::Find, I would simply cut and paste its source here (and in response to "until you have studied..", I have, and am quite dismayed at such an assumption).
That would be entirely counter-productive!! To a newer programmer trying to understand directory (or any) recursions, it is a difficult enough task simply trying to comprehend the what, why, and how of it.
To be burdoned by the many exceptions, catches, "look out for"'s, and so on.... would be discouraging, to say the least.
| [reply] |
If you had merely mentioned "but this has a bug with respect to symlinks" and "but this regex is not correct for dot-newline and dot-dot-newline", your argument would be much more sound. But you didn't. So you picked an example that while at first seems like a good example to demonstrate recursion, is actually a known dangerous territory. This is my gripe. I guess the title of my rant isn't "stop reinventing the wheel", but "when you reinvent the wheel to teach, be sure you teach proper things!"
As for ...
To a newer programmer trying to understand directory (or any) recursions, it is a difficult enough task simply trying to comprehend the what, why, and how of it. To be burdoned by the many exceptions, catches, "look out for"'s, and so on.... would be discouraging, to say the least.
... that's exactly what programming is all about! Especially with recursion, you must consider things like "will this ever terminate" and "am I looking at the right data" and "what can go wrong". Those cannot be overlooked, simply sweeping them under the rug.
The basics of recursion can be illustrated with something like factorial, which has easily defined end-points and recognizable computations. The flaws of recursion can be illustrated with something like the fibonacci calculator. But even these examples require at least a footnote to say "note that we aren't verifying that the number is an integer here", in my book anyway. Why do you think we have so many footnotes in the llama? I say one sweeping statement in the text, but in the footnote, I'm able to more carefully specify it so that I don't outright lie.
-- Randal L. Schwartz, Perl hacker
| [reply] |
you are perfectly rite it doesn't take into account the symbolic links and the permissions of a file lets say if we wanna copy.
The other thing i wanna point out this is not reusable at all | [reply] |