Thanks to everyone for feedback. It looks easier to respond in one place, so here it is.

@ Zentara: I agree that there has to be some limit where you stop trying to do it all yourself. And there's no danger of me ending up in Assembly: Even the little bit of C that I've done was enough to make me (as Lawliet and starX say) very, very grateful for Perl.

@ Perrin: I wouldn't quite say that I'm bored. Let's all agree not to put it that way to my employer. Still, your advice is good. I have tried to "do more than I have to" with the code I write. (For example, I doubt that many 100 line utility scripts provide command-line parsing (via Getopt::Long) and a full man page (via Pod::Usage).) I actually do that for the same reason I tried this "reinventing the wheel" experiment: to push myself, to learn something new. Nevertheless, you may be right that my time would be better spent on new work.

@ Chromatic: I hear what you're saying, but much of what you wrote doesn't straightforwardly apply to me. (I admit my case is unusual.) For example you write:

Writing code for didactic purposes may be appropriate, if you learn something from it. Did you seek code review? Exploration testing? Adherence to the relevant standards? Algorithmic analysis? Did you compare the results to results from a widely-used, well-tested alternative?

As I said in my original post: I am the only person writing code in any sense where I work. And quite frankly I'm a complete amateur (and novice). It sounds like you are primarily thinking of professional, full-time programmers. (A reasonable enough focus for you, but it's not who I am.) Still, to respond to your questions:

• Nope, no code review. I don't really have anyone to ask. See below for why I'm not going to ask here as far as this experiment goes.
• I have no idea what exploration testing means in this context. So, I guess I didn't do it. I'm only just learning how to write tests at all. Yeah, yeah, I know, get out the torches and the pitchforks. (Coincidentally, I bought your book on testing about a week ago because I figured it was high time I learned.)
• There are standards for filesystem traversal? Cool. Who knew? Nope, I didn't look at those either.
• I do have an inkling of what algorithmic analysis means in this context, but nope, I didn't do that either. Again, I have no training or background which would allow me to analyze an algorithm in any very substantive way. I thought about what I needed to do, tried things, looked at how they failed, tried some more things, and so on. However, I probably should have done some algorithmic analysis. When I run my code against a fuller directory (eg, my $HOME), it wets the bed with a whole lot of "Deep recursion on subroutine main::walker" errors. During development, I only ran it on a smaller sub-directory. Damn.
• And, finally, I am in the process of comparing my results and code with File::Find. I certainly appreciate File::Find more than I did two weeks ago.

But all of that said, I think you missed one crucial point: I wasn't doing this intending to release it upon a production environment. I was doing it to learn. I was going to test it on the blogs at my work but only to compare with File::Find. All my actual scripts for work use File::Find or File::Find::Rule. I'm dumb, but I'm not stupid.

@ Grandfather: I have one module written for my work code, and you're right that I should continue to work on that. I understand OO Perl well enough to use other people's OO modules comfortably, but for my own code, I find procedural (with a little bit of functional) more natural so far. I should probably work on that too.

I wholeheartedly agree that teaching is a good way to learn, and I do actually answer questions on the rare occasion here, at Stackoverflow and on the Perl Beginners mail list. It's a great way for me to solidify my understanding of things. I also read a lot of posts to see how people approach things. I think I will pass on the invitation to post my broken wheel to the Cool Uses for Perl part of the site. (See above on "Deep recursion" errors. Damn.)

So where am I left? Well, I'm less thrilled with my experiment, now that my wheel doesn't roll properly except on small streets. I also think people poked some good holes in my reasoning. On the other hand, I do feel a lot more comfortable with callbacks and code references. Maybe this wasn't the best way to spend last week, but I'm not yet convinced it was a complete waste of the week either.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.