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


in reply to Re: OT: A reasonable temporary password generator?
in thread A reasonable temporary password generator?

Perhaps it's mother's day making me prickly.

Sometimes when I look at the list of use ABC .. XYZ at the top of a script trying to creep below the fold of my poor teraterm I cringe.

I ♥ the CPAN. (I hope that entity displays right for everyone)

Replies are listed 'Best First'.
•Re: Re: Re: OT: A reasonable temporary password generator?
by merlyn (Sage) on May 11, 2003 at 11:52 UTC
    Sometimes when I look at the list of use ABC .. XYZ at the top of a script trying to creep below the fold of my poor teraterm I cringe.
    Why? That's that many lines of code that more than one person has used, evaluated, and tested for the purpose at hand. Code re-use is a very good thing. Independent implementation is not. I even wrote a column on that (surprise {grin}).

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

      Obviously you're right that using someone else's good work is beneficial. But I personally believe you're making too general a statement. As you've written it, you aren't really saying code re-use is good, you're saying only code-reuse is good.

      This is the same fabulous rhetoric, "Don't reinvent the wheel." There would be no Perl at all if Larry had taken these adages to heart b/c he could have re-used the shells, C, awk, and sed and pretty much covered what the first few versions of Perl did and then some. If one can make a wheel 5% better by putting in 10,000 times the work, does it make a fool? I don't care if my neighbor spends all day working on wheels. I'm not obligated to use any of them. Perhaps s/he'll hit on a nice one and might share.

      Lots of kids here would probably cringe if I said, "I just wrote this great script. It has 42,000 lines of code and runs great." That's what we do when we import 50 modules. Or even 10 that each import a couple families. Many modules are so completely generalized to be portable that they contain scads of things you never use but have to pay for the loading of anyway. Date::Manip is one of my favorite modules but I've had it bring down a corporate intranet from a well-used CGI. It helped write the app quickly but it had to come out when the app was finally in full swing.

      I have a module I am working on as a drop in replacement for CGI.pm's HTML routines because I like them so well but don't need anything else since I've got Apache::Request to cover param() and so on. Is it better than CGI.pm? No way. Is it as well tested? No and never could be. Is it as well written? Not particularly, not yet. Is it faster? Benchmark says, 200-500%. And I could have used the very nice HTML::AsSubs instead, but at a speed penalty of 2000%.

      Will this module ever be persuasive enough to make it into production applications or to CPAN? Maybe not, but I think other mod_perl kids might like to have it since I'd like to so it's worth trying out.

      I really love to write code, sometimes even when it is destined for the bit-bucket. It somtimes seems like many Perl hackers hate to write anything except sig blocks. :)

        As you've written it, you aren't really saying code re-use is good, you're saying only code-reuse is good.
        I don't think so, especially if it lets you draw the following conclusion from that...
        This is the same fabulous rhetoric, "Don't reinvent the wheel." There would be no Perl at all if Larry had taken these adages to heart b/c he could have re-used the shells, C, awk, and sed and pretty much covered what the first few versions of Perl did and then some.
        The important difference between what Larry did to create Perl and what most people do when they "reimplement" a templating system or a CGI param parser is that Larry carefully studied prior art.

        I have no problems with people reinventing things when they've already studied prior art. But 90% of the time, I see that people are merely reinventing things because it "wasn't invented here" or "I think I can do better" or "I didn't know something already existed" or "the author is not accepting my patches". Those reasons are insufficient for me, and I'm doing my best to stop that.

        -- Randal L. Schwartz, Perl hacker
        Be sure to read my standard disclaimer if this is a reply.

        One thing you're missing is maintenance. There's a difference between reinventing a wheel because that's what you set out to do, and doing it due to false laziness. When it's not specifically this wheel you're trying to construct, but an entire car, you should take some well tested wheel and reduce your own amount of work and maintenance (incl bugs and all that goes along).

        If your goal is to build a dynamic website, then use one of the existing templating systems. If your goal is to write a templating system, then (well, duh) write your own.

        Some wheels are not very round; many have flaws. Reinventing wheels is good, as long as you're doing it consciously. Obliviously fumbling around for not knowing better will just dramatically increase the amount of lead in your foot.

        Makeshifts last the longest.

        I agree with you, merlyn and Aristotle, completely on the principals and I'm playing Devil's advocate here, so bear with me.

        I have no problems with people reinventing things when... Now I'm not trying to be combative but I think this point is worth making: Why do you have a problem at all? If it's production practices, a module set to go up on CPAN, or anything you will ever suffer to work on or maintain, I'd understand. This particular page is not about those things though.

        Since peer pressure is all the Perl community has to keep quality up, I understand the insistance, however many hackers take the quality, style, philosophy, practices, whatever, of others' way too personally. If it works and works well, I don't care what it looks like. I love to see code or approaches different from mine because then there is something to learn.

        There are multiple templating systems for a reason. I'd gladly duel with pistols anyone who had tried to talk Andy Wardley out of writing the Template Toolkit just because there were already good templating systems available. A wheel can be better in the eye of the beholder for many reasons. As we learned earlier, "There are some stunningly novel ideas in Perl" -- Paul Graham, and from an article lacking evidence but nicely written: Perl is a vastly inferior language to Lisp [sic]. Who here ran right out to get this better wheel? It made me slightly curious b/c I've heard the same from a hacker I respect, but from hacking on Emacs configs I already know that Perl is a better wheel for me.

        There's a difference between reinventing a wheel because that's what you set out to do, and doing it due to false laziness. You are implying that those are the only two possible reasons. And you ignore the huge amount of human technological advancement that has come from exactly "Obliviously fumbling around." The most important reason to me is whether or not it's fun and worth learning about.

        I've written at least three templating systems, all similar and almost all from scratch. Stupid? No! I had fun doing it and learned a lot about more than just what I was coding up; more than I could have using someone else's. The beneficiary was me. Would I use one of my templating hacks in a situation where money was riding on it? No! Would I put it on CPAN and boast about how great it is? Ha! I am in love with the TT2 and will probably never take another in its stead.

        I do agree with you both on the whole. I think generalizing absolutes to "X is wrong," "Y is right" is a function that will break down whenever it gets unexpected input.

        Your devoted fan,
        Your Mother
        PS: What did you get me for Mother's Day?