|more useful options|
Re: What's wrong with re-inventing wheelsby spiritway (Vicar)
|on Jul 11, 2006 at 05:20 UTC||Need Help??|
I think reinventing the wheel has its place. As you point out, that's where many improvements come from. OTOH, for every decent new wheel, there are many crummy ones that simply don't work, or that are worse than the ones they try to fix.
Part of the problem, IMNSHO, is that we don't always see the difficulties when we're looking at a program from the outside. We think of an "obvious" solution, not realizing that there is some compelling - often overwhelming - reason why that solution doesn't work for this problem. Even as we delve into the problem, we might not recognize that our solution is faulty - or, we might not be willing to admit that we have to let it go. I can't speak for anyone else, but I get very attached to my ingenious solutions, and have a hard time recognizing when they're flat-out stupid.
One reason why there are so many wheels in CPAN is that many people write less than optimum code and upload it, not understanding all the finer points of the problem. This creates problems for people who want to use a module for something - how can they tell which ones are decent, which are less than decent?
This is where Perl Monks comes in... you can ask people here, and get a good idea of what really works. This is a real life-saver if you don't have the luxury of testing each module yourself. But the point is, having multiple wheels for the same thing often makes it difficult to find quality solutions. You can waste a lot of time trying to get some half-fast module to do what you need, only to find that it's simply the wrong tool for the job.
I think it's a great idea to reinvent the wheel for your own edification - to learn how a problem might be solved, to get a feel for what's involved. That might even give you an idea of what to look for in an off-the-shelf solution. But I also think it's unwise to upload it without running it past a whole lot of people, and listening carefully to their criticisms (such as, "it doesn't work", or "it's no better than the others").
I don't think most people deny the *possibility* that you might have built a better mousetrap. It's just that, like so many other things, the odds are against you. Maybe you could write a better sort program - but I wouldn't bet on it. Most of the solutions around have been reworked, optimized, and otherwise polished until there isn't much (apparent) room for improvement.
I think that another consideration - a vital one - is why you're writing programs to begin with. Professional programmers often (probably usually) don't have time to play around with unproved solutions, just to see if they'll work. They also don't have time to write things themselves, that already exist. Sure, if the modules just don't do what they need, of course they'll write it, or rewrite an existing module, or something. But because they have deadlines and schedules (and get tired, and sometimes even have a life) they want to work efficiently and competently. It's safer and less time-consuming to use what's already out there.
Amateurs have the time to play around. They can take as long as they want to get something right, or reinvent a wheel. They can look at new modules and hammer on them, see when they break, offer feedback to the programmer, all that good stuff. They can beta test stuff that professionals simply can't. Our goals are different - the pro needs to get work done for bosses or clients, and it better be right. Amateurs don't have these pressures. They don't lose money if they take forever to get something written; they don't get fired if their program decides to trash the hard drive. So yes, amateurs can putter around with things that the professionals can't.
Unfortunately, the range of competence among amateurs is wider than among professionals. Most pro's can't remain incompetent for very long. They either learn, or lose their jobs (unless they work at certain larger software houses whose naMeS will not be mentioned). Amateurs have no such limitations. Many amateurs are highly competent - in fact, many are also pro's just having fun in their spare time. Some, though, are frighteningly incompetent, yet they manage to figure out how to upload to CPAN. This is where the harm is. And this is one very important reason why we need Perl Monks.