http://qs321.pair.com?node_id=36354


in reply to to post, or not to post...

Are you kidding? Coming up with a new module is cool, not embarrassing. I have the feeeling that this may be very useful to many Perl people everywhere, not just the perlmonks- be sure to submit this to CPAN. If your code does have bugs, you'll might get alot of feedback by email. That's great! This promotes the evolution of your code and great improvements. If everyone kept their code under the roof just because he/she thought it had bugs, we wouldn't have CPAN, the wonderful MySQL dbengine, or Linux (not mentioning perlmonks)! In short, you shouldn't be apologizing- you should be bragging about your cool new module that you submitted to CPAN! Have fun dude! NIfty mod! Congrats! Anyone that does "flame" has obviously never contibuted anything to the world of GPL.
AgentM Systems or Nasca Enterprises is not responsible for the comments made by AgentM- anywhere.

Replies are listed 'Best First'.
On reinventing the wheel
by merlyn (Sage) on Oct 12, 2000 at 06:48 UTC
    But you shouldn't build on prior art until you understand why the prior art is there. I suspect (but am waiting for confirmation) that japhy was not aware of the callback parameter, which would have reduced his program to about half its size, and then it would have handled proxy servers and all protocols, not just HTTP.

    The problem with reinventing things is that you now have two or more incompatible mechanisms to accomplish a task, which dilutes the effort, and can confuse the marketplace (should I use X or Y interface, since both seem to be in the CPAN?).

    Witness News::NNTPClient, an interesting implementation that predated Net::NNTP, but is now abandoned. I wrote quite a few programs using the old interface, but have finally just recently succeeded in cutting them all over. And I did that because I know that Graham Barr will be around to update Net::*, but who knows about any efforts to pick up the other package.

    SImilarly, a solution based on top of LWP will very likely continue to work and get bug fixes, because I know that LWP will continue to be maintained for some time to come. But if japhy submits his independent code to the CPAN, will he notice when Gisle updates LWP for a security fix, and re-implement that? I think not.

    So, the code doesn't do as much as LWP, won't be maintained the same way as LWP, and doesn't leverage off the existing code in any big way. Do you think I can recommend this little code for any production work? Hardly not.

    Now, if japhy writes code that uses the LWP callback, the codesize will be reduced, everything will play well with proxies and new underlying protocols, and the chances that the code will be maintained will be greatly increased. Everyone wins. I encourage japhy to rewrite the code to use the callback, and submit it. I would not encourage the current code to be submitted.

    -- Randal L. Schwartz, Perl hacker

      I will be voting this up. I honestly believe that this post makes one of the most fundamental points about good programming technique that I have seen merlyn make. If you read books on programming you will hear it echoed again and again in many different ways.

      The point is that the key to maintainability is to have each thing done in one place. You want to avoid using two parallel efforts. Not only is it duplicated effort, both originally and ongoing, but it is a significant maintainance problem.

      The easiest route to code-sharing in the short-term is called cut-and-paste. However if you stay aware of where your energy is going and work to get to code-sharing through having any particular task done once in your code-base, you will find that decision paying you back time after time again.

      For more on this I recommend virtually any classic, starting with The Pragmatic Programmer because it is not only classic, but also mentions Perl quite a few times. :-)

      There are many issues, but I think that if a few extra lines or a new method will actually in some way promote server efficiency (processing time), then they should be added without question.

      Efficient coding doesn't always mean less code. Consider the case where a fundamental method is for some reason missing from the object.

      I added a new method to Lady /TM specifically for updating a page counter. To make everything simpler, if the counter wasn't found during a pass through the index, it was added automatically. The previous method of updating a counter in a hash of counters was too slow, requiring an extra recursion through the index. Once to read it. Another to read it again and write the change.

      The new method specially developed for this task reads the counter table and holds the entire table, closes the file. Then quickly reopens it for a write access and prints the updated file.

      The method is much more efficient than would be an MS-Access ODBC implementation that would require that the large MS-Access driver is loaded. I "reinvented" Lady /TM because I had uses in mind that seemed simple. It seemed obvious that ODBC and MS-Access was over-kill for my immediate application which needed speed.

      When I sit next to my server and listen to the MS-Access driver load every now and then I am truly gratified for having "re-invented" Lady /TM.

      -Steeeeeve

    A reply falls below the community's threshold of quality. You may see it by logging in.