Many apparently do, but why they do I have not the vaguest concept.

I can give a couple of simple reasons why I care enough about this issue to bother at least pointing people towards a publicly available wheel and encouraging them to have a go at it.

First, there is self-interest. If people are reinventing wheels, they are usually not contributing useful patches and ideas to CPAN. A strong CPAN makes my life easier. Also, it has been my experience that despite what you say about integration problems, reinventing wheels usually leads to wasted time, less functionality, and more bugs, all of which makes Perl look bad. I want Perl to look great, so there will be lots of fun jobs for me.

In a slightly wider sense, but still out of self-interest, I want it to be accepted that using open source components is a reasonable way to write applications because it's the way I like to write them. If everyone just rolls their own all the time and that becomes the norm, managers will think it's strange when I tell them I don't want to write the ten thousandth template engine from scratch.

Obviously you and every other Perl developer can do whatever they want to, but there are some simple and sensible reasons why I (and others) will continue to encourage people to use CPAN and not reinvent wheels.

If people are reinventing wheels, they are usually not contributing useful patches and ideas to CPAN.

Really? If someone reinvents a wheel by creating a module that does X, while there is already a module doing X, he basically made a patch the size of a module. Reinventing wheels is usually done because someone didn't like the original wheel. It's often more efficient to reinvent a round wheel, than to submit patches for a square wheel (if only the creator of the square wheel likes squares, or because round wheels aren't compatible with the vehicles equipped with square wheels).

A strong CPAN makes my life easier. Also, it has been my experience that despite what you say about integration problems, reinventing wheels usually leads to wasted time, less functionality, and more bugs, all of which makes Perl look bad.

There are no quality requirements for CPAN. Anyone can already load any crap on CPAN, and many already do. Non-overlapping functionality doesn't make CPAN stronger, it probably makes it weaker. Choice is good (remember one of the slogans of Perl: there's more than one way of doing it?) Your reasoning would mean that the first module doing Y that was uploaded to CPAN is necessary the best one. Good heavens. Had Matt Wright made his formmail.pl available on CPAN, you would have preferred noone else would have created a form to email utility, but they all had used Matt's script.

Abigail

Reinventing wheels is usually done because someone didn't like the original wheel.

From what I've seen, it's usually done because someone is unwilling to deal with the politics or technical issues of installing a module at their site. Sometimes it's because they're too lazy to check CPAN or to spend any time trying to understand the documentation for existing modules. Or sometimes it's because the perfectly workable API that comes with the module doesn't match someone else's fantasy of the perfect API. Every now and then it is done because someone looked at the existing modules and they didn't meet the project's requirements.

It's often more efficient to reinvent a round wheel, than to submit patches for a square wheel

I have nothing against someone making a new module if the existing modules are not good. Often though, a patch is all that's really needed.

There are no quality requirements for CPAN. Anyone can already load any crap on CPAN, and many already do.

The cream rises. I would never tell anyone to use a bad module from CPAN.

Your reasoning would mean that the first module doing Y that was uploaded to CPAN is necessary the best one.

Certainly not. I never said such a thing.

Had Matt Wright made his formmail.pl available on CPAN, you would have preferred noone else would have created a form to email utility, but they all had used Matt's script.

Matt's script was not good. Someone would have fixed it or replaced it by now.

I don't advocate people blindly using whatever is on CPAN and never questioning the quality, but you'd be a fool to write your own HTML parser these days without a very good reason.

On my site http://jokubonis.20megsfree.com I present idea - The Square Wheel. At first I want surprise You that roll of Square Wheel is very restful and lenitive! I invite You to see videoclip on this page how a square wheel roll equal as easy round wheel. Be surprised and surprise Your friends.

...at least pointing people towards a publicly available wheel and encouraging them to have a go at it.

I've no problem with people "pointing to and encouraging" the use of CPAN--I've even been known to do this myself surprisingly. I do take umbrage at being told that the "solution" to my problem is in doing something completely different to what i am trying to do (and about which I hadn't asked for advice) just so that I can utilise a CPAN module I have no interest in.

My re-invented solutions have caused noone any "wasted time, less functionality, and more bugs", nor made "Perl look bad", because I've not made any of them available on CPAN nor anywhere else.

The only module I've so far uploaded to CPAN, was withdrawn within 1 day. I uploaded it because 3 people seperately encouraged me to do so. I withdrew it because one person, who views I respect, suggested that it "polluted the namespace" because I had named it as a pragma, rather than deeply nesting it in some obscure namespace where it would never been seen. Reserving namespaces is well and good, but if they are never allowed to be used, then they become wasted space. C'est la vie!

As for the rest of my modules. I re-invent for my own learning purposes. As and when I have something that I think is of sufficient quality to warrent inclusion, I will do so.

---

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
If I understand your problem, I can solve it! Of course, the same can be said for you.

Perhaps not. The basic premise is that if you are confident that you gain more utility (in the economics sense of the word) by doing it by hand, and are confident that you can do so in a way that safely meets your needs, you have passed the litmus test and should do it however you please, by all means. Particularly if your confidence is properly placed. The premise can be extended to assert that the test is yours to define. I suggested some talking points, but never claimed to know all of the criteria that you use in evaluating the benefits of reinvention versus reuse. I did assert that if you know enough about the problem and solution to do it better yourself, have at it.

The assertion I made is that many will fail to gain economic utility by doing by hand what has already been done in a well-written module. They will fail because their approach is not as robust, or because it took longer to implement and debug, or because it wasn't supported as future uses develop, or because it didn't benefit from the sharpening stone of mass-use, or because it is not extensible, or because of a number of other reasons.

But the person writing the code (and perhaps his superiors, customers, or shareholders) must be the final judge of whether it is a maximization of utility to invent his own wheel or try to make an existing wheel spin on his/her axle. I never intended to put myself in the position of saying yes or no to you coding however you please.

I pointed out that frequently, the wrong choice is made, favoring reinvention out of misguided lazyness. ...too lazy to figure out how a superior wheel works, not understanding that extra up front effort might lead to increased utility (free time, or better product) in the future. Certanly it's not always the case that code reuse is the best way to go. It is definately true that there are many instances where a new wheel works better. But just as certanly, there are way too many times that the wrong decision is made. This is particularly an issue for beginners, who may not yet have learned enough about the issues surrounding the chore they've set out to accomplish to write their own safe, robust, and effective solution. This is certanly the case with most of those who post questions about how to parse CGI or XML with regexps. They know enough to know that regexps are powerful tools in text manipulation. But not enough to know the shortcomings and downright dangerous pitfalls.

Your specific cases may well pass the litmus test, and you may even add or subtract items of your own criteria to that test. But every time you, yourself, use or don't use a module, you are in your own way weighing the alternatives. I only tried to bring to the forefront a few of the items that should be on ones mind as he weighs the pros and cons of using a particular module versus cooking up something altogether different.

Dave

"If I had my life to do over again, I'd be a plumber." -- Albert Einstein