But does that mean others shouldn't scratch their own itch by writing argument parsers?

Yes. At least, it should.

One of the worst problems in software development is that many programmers are incapable of or unwilling to read existing code. It's too hard. They don't like the indentation. It's not fun. It's messy.

Whatever.

Matt's Script Archive reinvented a lot of wheels. It's difficult to estimate how many spammers still ply their trade thanks to his code -- written by hand -- ignorant of good security techniques and Internet standards. I have a silly habit of reading hand-rolled CGI argument parsers. Almost every one I've ever written make the same five mistakes (a couple of them active security holes), and most have at least seven bugs I can identify within seconds of reading them.

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?

Now perhaps you are the kind of coder who researches the problem domain, writes a comprehensive test suite, and validates the results against a well-known and well-understood set of specifications and requirements. If so, good for you.

Yet the person who believes that he absolutely must, for example, write his own web server for production purposes without reading and understanding the relevant RFCs or without consulting the current art of the domain for the purpose of writing something nebulously "better" or "faster" or "easier to understand" or "just so I can learn how to use hashes effectively" exhibits unprofessional, immature, irresponsible, and actively harmful behavior.

Have you forgotten it was mis-guided souls re-inventing argument parsing who created Getopt::Long and friends in the first place?

Feel free to respond with the tired old saw about how Einstein was a mere patent clerk when he developed his theory of relativity, as if that proves that an interested amateur outsider can significantly advance the state of the art by breaking free of existing conventions. It's an urban legend, for one -- a particularly well debunked one. Yet even if it were true, it proves only that it's possible perhaps once a century, and certainly not that it's likely.

(I rather suspect that people who've written and maintained argument parsers -- especially if they've dealt with feature requests and bug reports -- have a much better idea what argument parsers need to do than someone who's never written an argument parser before.)

I'm not saying everyone is a Picasso, or an Einstein. I'm not saying there isn't a lot of crappy re-invented wheels either. There's also a lot of crappy art and debunked physics theories too. But we don't get anywhere by telling Picasso at an early age to stop messing with paints and go milk the goats because 'everything to know about art has already been learned by others'.

I rather suspect that people who've written and maintained argument parsers -- especially if they've dealt with feature requests and bug reports -- have a much better idea what argument parsers need to do than someone who's never written an argument parser before.

And how exactly did these 'people' get that knowledge? Divine inspiration? What, where they born with argument parser code in their heads?

Neither you nor I have the power to predict who will become giants and who will merely blot the playground with weeds. But surely there will be no giants at all if all we do is stamp out seeds where we find them.

But we don't get anywhere by telling Picasso at an early age to stop messing with paints and go milk the goats because 'everything to know about art has already been learned by others'.

But surely there will be no giants at all if all we do is stamp out seeds where we find them.

That's a strawman argument, with very little connection to what I wrote. Surely my argument deserves more consideration than such callous dismissal!

And how exactly did these 'people' get that knowledge?

As I wrote in my original reply, by reading code, by examining prior art, by iteration and refinement, by reviewing the desires and needs of users.

The best code doesn't get written on the clock. It gets written in spare time by people with a passion (ok, and sometimes on the clock as a result). If all you can see is the cost of re-inventing wheels, then you probably don't see the benefit of something truly new and innovating either. I'm not saying it's a cheap benefit, all failures considered, but it's not your dollar being spent either.

It kind of is my dollar being spent. Every time a perl hacker rewrites File::Find instead of writing something new that I might want and putting it on CPAN, I lose something.

Don't get me wrong -- I have useless projects too. But there is a cost to these things. We only have so much time to spend on free software.