Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Re: "Rites of Passage" wheel reinventing

by gmpassos (Priest)
on Feb 27, 2004 at 01:45 UTC ( #332168=note: print w/replies, xml ) Need Help??

in reply to "Rites of Passage" wheel reinventing

I can't forget to mention a Larry Wall frase:

  • "Do not try to discourage people from trying variances. We do not want to stabelish one church, we want to stabelish many denominations..."
  • We can't forget that reinvent the wheels is important to create a variance of codes, to create options, like in a genetic enverioment. And us, the users, will make the selection of what will live.

    For example, when I started to work with XML and Perl, I can't find any tool that work like I want, since I always want tools that are easy, direct and powerfull. Soo, Perl in the time already have a lot of XML handlers, but I started to do my own, with a different approach to work with XML. Today XML::Smart works exactly as I want, and has much more than I can imagine when I start to build it, since the community always make good contributions. Soo, XML::Smart today is a tool that enable any Perl user to use XML, even if it don't know much about XML. Also I have got good reviews of it, including from IBM, that is the main creator of XML by the way.

    Soo, if I can't find a tool with the resources that I want and the architecture that I need, yes, I will build my own. But before start building another CPAN module I always take a look around, including the source of what I find to see if they are in the right architecture, than I decide, to use it, contribute to it, or start a new module.

    Soo, I have reinvented some wheels:

    • Mail::SendEasy

    • Created it because I can't find a Mail sender based in SMTP (platform independent), that don't need big dependencies like libnet, that has authentication, and is able to send TXT & HTML messages, attachments, etc... All in one package.

    • Pod-HtmlEasy

    • Well, after wait/search 1 year for a Pod 2 HTMl tool that handles index, css, and enable personalizable outputs, I stop to wait and build one. Soo, now I can have nice and well HTML builds on the flight, where I also can set my own events, and handle links (L<>), codes (VERBATIN), and all the POD syntax without care about the HTML generation, entities, URI links, etc...

    • Class-HPLOO

    • This actually wasn't a new wheel, since I really can't find something that do that. I found Perl6::Classes, but it doesn't work very well, since is very easy to break the filter with complex Perl codes. But this is a bug of Filter::Simple and Text::Balanced, where I also make some work around to fix them on Class::HPLOO. But Perl6::Classes also have a complexer syntax, it isn't simplier as I want/need, since Class::HPLOO was designed to make the OO development faster and similar to Java, since my team work a lot with Perl & Java at the same time, and I was tired to listen the Java folks to disturb me about the Perl syntax for OO.

      Soo, now I have Class::HPLOO that make the development of new modules and classes for development of systems much more faster and easy. Also I can have Perl developers that are not soo experts on PerlOO working with 100% OO codes. And the Java folks are using much more Perl now, actually they think to build in Perl before to think in Java solutions.

    • XML::Smart

    • Let's mention Larry Wall again:

      "I fill computer programmer not as something it has to do as computers, it has to do as humans. It's like, ok, I will going to make this easy to the computers or for ther person envolved?".

      Soo, I think that XML need do be easy and simple to use and generate, since if it's not simple and direct, it won't make it job: "Be a language that integrate easy different applications and architetures.". Before XML::Smart I was really thinking that is much more easy to create our own formats, now XML rox.

    Soo, if I think that I can make something better, yes I will, since no one is oblicated to use it, only to love it! ;-P

    Graciliano M. P.
    "Creativity is the expression of the liberty".

    • Comment on Re: "Rites of Passage" wheel reinventing

    Replies are listed 'Best First'.
    •Re: Re: "Rites of Passage" wheel reinventing
    by merlyn (Sage) on Feb 27, 2004 at 01:59 UTC
        And we can't forget that we always can learn with the already existent art.


        Graciliano M. P.
        "Creativity is the expression of the liberty".

    Re: Re: "Rites of Passage" wheel reinventing
    by demerphq (Chancellor) on Feb 27, 2004 at 12:34 UTC

      The only one of these that I have reservations about is Mail::SendEasy. I'm not real convinced that ripping the guts out of MIME::Lite, Net::SMTP and the rest (metaphorically speaking) and putting them in one place is the wisest idea. For me it violates a bunch of rules. 1)Tools should be simple and single purpose. 2)Tools should be easily usable independently. 3)Code shouldnt be duplicated unnecessarily.

      You say that the dependencies are too large for your taste. For me that is a sign of a robust design. Each dependency can be maintained independently by people interested in the relevent field. Net::SMTP handles authentication, MIME::Lite among others handle attachments of a whole range of type correctly and automaticaly. (Meaning it will auto detect the file type and map it the appropriate encoding and MIME type.) M::L can even be used with OpenSSL to create S/MIME mails.

      I guess the reason im writing this is that over time my intention with MIME::Lite is to do the exact opposite of what you are doing with, that is to move as much of the internals in MIME::Lite that are implemented by stand alone packages into simply using the packages. I say this becuase when I inherited MIME::Lite (which is a very old module) there was all kind of code in there that handled various issues reasonably well but nowhere near as well as the dedicated modules can and do. So for things like email addresses it has code inside it that parses them, but not quite to spec. Wheras it can also call out to Mail::Address and have that parse the address code. Now I dont have to stay on top of the MIME RFC's as well as the SMTP RFC's. And when those RFC's are updated or enhanced, or the author of that module improves his code my module and the all the users of it benefit. Also when you think of testing and exposure using your module represents a severe risk. Your code is new, untested in the wild wheras Net::SMTP and friends have been tested on tens of thousands of machines and work on every platform perl runs on. How many years and bugfixes will go by before we can have the same confidence in your code?

      So from my perspective your Mail::SendEasy is probably a maintenance problem waiting to happen. You have to maintain compatibility with something like 6 or maybe 8 different RFC's. Thats a lot of work for a single volunteer author, and I wonder if its really wise to trust production systems to such a tool. I am much more comfortable trusting lib-net which is maintained as part of the core now iirc, Mail::Address for address parsing, MIME::Base64 for base64 encoding (also now part of the core), MIME::Types for mime type detection, etc etc. First off there are less single points of failure (if you get hit by a bus your user base will S.O.L., and given the modules ambitiousness its unlikely to be maintained by someone else), second I believe that by choosing smaller problem spaces to work in the result is more likely to be well maintained.

      So, in short I believe that this one module represents what I consider to be the worst reasons to reinvent the wheel.

      I will say that i like some of your other work quite a bit though.


        First they ignore you, then they laugh at you, then they fight you, then you win.
        -- Gandhi

        You say that the dependencies are too large for your taste. For me that is a sign of a robust design.

        Playing Devil's Advocate: there are times when you can go way overboard with dependencies. For instance, Crypt::OpenPGP depends on a huge number of modules, including Math::Pari. Math::Pari is based on the pari C library, which is extremely touchy to compile. When setting up a new system, I often have to restart the pari compile a couple times (usually, the pari binary packages for my system aren't up to date enough). Once installed, Crypt::OpenPGP works quite well, but the Math::Pari dependency is always a pain.

        : () { :|:& };:

        Note: All code is untested, unless otherwise stated

        Well, you can be right in some parts, but I had a demand for a long time for a tool that have everything in one package.

        Also, to implement Mail::SendEasy, I haven't implemented a full SMTP handler, or a full MIME handler, since I don't wan't to handle all the resources that this definitions have, just what is needed to send an e-mail with TXT & HTML messages and attachments, through a SMTP server that ask for authentication (what is common in this days). One thing that you can see is that Mail::SendEasy, yes it handle a lot of parts, but it code is simple and small.

        You said: Tools should be simple and single purpose.

        Mail::SendEasy is simple, and for the user side, it's for a single pourpose, send an e-mail. The final user don't want to know that exists SMTP, MIME, or any other technology, since an e-mail system is all of this together.

        Tools should be easily usable independently.

        Well, this is the main pourpose to Mail::SendEasy be created. What already exist there wasn't "easily usable" as I need for my users. Actaully before they need to install a lot of things and use a lot of modules together to can have what they want.

        Mail::SendEasy is soo simple, that this is the only thing that you need to know to start using it:

        use Mail::SendEasy ; my $status = Mail::SendEasy::send( smtp => 'localhost' , user => 'foo' , pass => 123 , from => '' , to => '' , cc => '' , subject => "MAIL Test" , msg => "The Plain Msg..." , html => "<b>The HTML Msg...</b>" , anex => ['/tmp/file1' , '/tmp/file2'] , ) ; if (!$status) { Mail::SendEasy::error ;}

        Code shouldnt be duplicated unnecessarily.

        Well, we can't make everything perfect (first thing that we learn in the life), for one side we win, for the other we lose, and what really matters is the final product.

        You complain that maintain Mail::SendEasy is hard and my code wasn't tested as Net::SMTP and MIME::Lite. Well, if we know what we are doing, this point of view is just an excuse to not do things. First, I have based my code in what is already there, what was already tested. Also I have 10 years of experience in Perl doing things much more complex than just a simple mail tool that I build in 2 hours, since I was tired to spend 1h installing modules and checking the behavior of the last version of each module, each time that a system need to send e-mails. But I really respect your opinion, since is your own opinion, build by your self, and in this days is hard to find people that care about that. in this days people just want to use and say what the others says.

        From my point of view, use a lot of different modules to do one thing is always hard, one beacuse the user need to learn 3, or more tools, before start doing anything (like in Java), and Perl is to be pratical. Also all of us know that a lot of dependencies, make a module to have a high probity to not work in the future (history show this easy), or to have bugs, since each dependencie cover an area bigger than what your main pourpose need.

        Well, Mail::SendEasy is there, and I know that it's in use in Europe by a big ISP to send e-mails. Also I know that it's in use by a FanClub to send more than 300.000 e-mails in one shoot. Soo, it's working for big demand too.

        Graciliano M. P.
        "Creativity is the expression of the liberty".

    Log In?

    What's my password?
    Create A New User
    Node Status?
    node history
    Node Type: note [id://332168]
    and all is quiet...

    How do I use this? | Other CB clients
    Other Users?
    Others about the Monastery: (8)
    As of 2017-10-21 23:44 GMT
    Find Nodes?
      Voting Booth?
      My fridge is mostly full of:

      Results (271 votes). Check out past polls.