A meditation for a rainy day.

I was chatting with a friend about the "rites of passage" that people go through with various programming languages, and we got onto the topic of the things people build "just because", instead of using an off-the-shelf package. Back in the day, many people I knew who worked in Fortran built their own 2D or 3D APIs (mostly for driving plotters or Tektronix displays). It wasn't as cool to use someone else's--you had to build your own to get street cred. (Mine did backface culling. Woo hoo!) Over the years, I've built at least two parser generators in C (one LALR(1), the other LL(1)) when otherwise good alternatives were available, and I cringe to think of the wheels I've reinvented in Perl.

When you look around at what you and your cohorts are doing in Perl, what wheels have you reinvented just because you wanted to have built it yourself?

Here's an incomplete list of wheels I've reinvented in recent history:

  1. Several lightweight templating packages, instead of using HTML::Template or TT (though I use HTML::Template a lot now)
  2. Several chunks of code that make HTTP requests on raw sockets, instead of using LWP et al. (What was I thinking?)
  3. At least one HTML tokenizer/parser (using regex's, of course) instead of using HTML::TokeParser.
  4. A package for constructing XML document object models.
  5. A Wiki (instead of using any of the available ones)

What's on your list?

Replies are listed 'Best First'.
Re: "Rites of Passage" wheel reinventing
by kvale (Monsignor) on Feb 26, 2004 at 21:50 UTC
    I have often built recursive-descent parsers for various projects, when Parse::RecDescent would have sufficed. I once built an entire XML parser out of pure perl, when expat was just laying about ready to be attached to a perl module. Fortunately Larry Wall had more sense than I.

    My other major lossage was recreating a lot matrix algorithms before learning about the Perl Data Language PDL.

    Moral: Always looks for a wheel first, even if you want to roll your own. It will always turn out better :)


      It will always turn out better :)

      Nah. Not always. If everybody thought like that we'd still be using abacuses for calculating and horse draw carts for transportation. Innovation not just the child of necessity but also of a crazed belief that you can do something better/different.

      Ive spent a lot of time working on my pet wheel project, and I think its been a good experience for me, and frankly has given my fellow perlers a nice new shiny tool to make their development live easier. I thought I could write a better dumper, and frankly I think I have. Of course that better by my own definition, but, well, you have to pick your definitions from somewhere.


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

        I think you missed my point.

        Creating something new is not the mistake. Creating something new without looking at what is already available is the mistake.

        For instance, in your pet data dumper project, I bet you looked at Data::Dumper to see if it would do what you wanted. It did not, so you probably looked for ideas about the API, how to deal with circular refs, etc. So when time came to create code, you had the benefit of all that previous effort, allowing you to announce a module that already felt somewhat familiar and had more chance of being a successful meme.


Re: "Rites of Passage" wheel reinventing
by perrin (Chancellor) on Feb 26, 2004 at 22:38 UTC
    About 6 years ago, one of my friends reinvented RPC using HTTP. He wrote a couple of libraries around LWP and CGI that would allow you to use HTTP for abstract communications between systems, and we built tools that used this for publishing files and controlling remote services. At the time we didn't realize that he had invented a Service Oriented Architecture that would revolutionize the face of IT. Imagine our surprise when Microsoft and IBM reinvented it again a few years later and called it Web Services.
•Re: "Rites of Passage" wheel reinventing
by merlyn (Sage) on Feb 26, 2004 at 22:55 UTC
    A few others that come to mind:
    • Some form of object or complex data persistence
    • Something to avoid writing SQL when interfacing with RDBMs
    • CGI param parser
    • Event loop manager
    • Class wrapper to autogenerate accessors (always a bad idea, but everybody's gotta learn the hard way)
    • Session management for CGI

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

      I'm curious - why would you consider a class wrapper to autogenerate accessors to always be a bad idea? I've got on working on my production site that I've been tinkering with for over 3 years and it's actually improved our development time and reduced complexity.

      The example I can think of is that we have a number of reports which are similar in structure. They all take a set of parameters that are a subset of all parameters. Which parameters are report-dependent, but they all need to be handled similarly. So, the report class will say "I'm using these parameters" and the parameter class will add the appropriate attribute(s) to the report class.

      Parameters are broken out because they also:

      • Generate their HTML::Template datastructure
      • Hold their default value
      • Know how to retrieve values from CGI into the report object
      • Know where their values come from

      We are the carpenters and bricklayers of the Information Age.

      Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

        why would you consider a class wrapper to autogenerate accessors to always be a bad idea?

        They tend to encourage people to spread accessors everywhere throughout their classes and use them as a crutch for a broken design. Autogenerating mutators are even worse, because now you're not just grabbing internal data, but modifying it, too. You might as well be passing around a bare hash reference and tell everyone to do what they want with it.

        Accessors (and to a lesser extent, mutators) can be used well, but they shouldn't be everywhere.

        In fact, I'm starting to wonder if Class::DBI was actually a step backwards over Ima::DBI, which Class::DBI is based on. The reason is that Class::DBI exposes the entire database layout, while Ima::DBI performs some action based on the database using pre-defined SQL. I haven't come to a firm conclusion, though, and certainly many people have used Class::DBI to great success.

        : () { :|:& };:

        Note: All code is untested, unless otherwise stated

Re: "Rites of Passage" wheel reinventing
by hardburn (Abbot) on Feb 26, 2004 at 21:57 UTC

    I did a chess move validator in C. Did it in the hardest, most bug prone, and least efficient way, too. (A chess board is small enough that it's practical to build a lookup table of all possible moves with O(1) efficiency, and with a pretty low constant, too. I was trying to do it on the fly.)

    At the moment, I'm writing some bloging code because I don't like the way everyone else's blogging code does things. I'd use Bryar, but it doesn't seem to currently support HTML::Template, and much of my site is already written using that instead of TT.

    : () { :|:& };:

    Note: All code is untested, unless otherwise stated

      I don't know about reinventing wheels, but I must confess to having written a chess move parser in every language I've ever learned. And truth be known, more than one version. The smallest was in lisp, the fastest in assembler---after so many years it has become a ritual, a sort of necessary task before I even pretend to 'know' the language of the moment. So I suppose I'm guilty of re-wheeling, in fact re-wheeling the same wheel. I guess I do know about reinventing wheels after all.


      "Never try to teach a pig to sing...it wastes your time and it annoys the pig."

      Im confused, how do you reckon you can lookup table all the possible moves? Maybe i misunderstand you but wouldnt that require knowing all possible games and putting all possible board positions in the lookup table? (Which I think would mean that you could solve the problem of the prefect game.)


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

        Nah, you just need to have a board with one piece on it and generate all possible moves for that piece from that postion. Then put that data in the lookup table and do it again for the next piece or position. You'll still have to do a little runtime work like check that the piece isn't jumping over other pieces (except for knights) and isn't landing on a square already occupied by a freindly piece, plus few other special cases (like pawn attacks). For the most part, though, lookup tables get the hard part done.

        : () { :|:& };:

        Note: All code is untested, unless otherwise stated

        I thought of this as an individual move validator. "Is this move legal?" sort of thing.

        Which I think would mean that you could solve the problem of the prefect game.

        <funny>All in O(1) time, and built on-the-fly!! This should be a pretty nice chunck of code...</funny>

        "In few words, translating PerlMonks documentation and best articles to other languages is like building a bridge to join other Perl communities into PerlMonks family. This makes the family bigger, the knowledge greater, the parties better and the life easier." -- monsieur_champs

Re: "Rites of Passage" wheel reinventing
by gmpassos (Priest) on Feb 27, 2004 at 01:45 UTC
    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".

        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".

      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 SendEasy.pm, 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 => 'sender@foo.com' , to => 'recp@domain.foo' , cc => 'recpcopy@domain.foo' , 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".

Re: "Rites of Passage" wheel reinventing
by Nkuvu (Priest) on Feb 26, 2004 at 21:59 UTC

    I think there should be a bit more distinction in your meditation. Maybe it's there and I just missed it. But I feel there's a big difference in 1. rolling your own because you don't know the wheel exists already, 2. rolling your own to learn how that particular wheel works, and 3. rolling your own to be able to say that you did. But of course these aren't necessarily mutually exclusive.

    Just my two copper-plated zinc bits.

      I think it's important to add 4. rolling your own because the other guy's wheel is square. Or at least not quite round in spots. Without #4, we'd all be using Babbage's Difference Engine (or worse--see demerphq's reply above).

      : () { :|:& };:

      Note: All code is untested, unless otherwise stated

        Yep, missed that one. Thanks.
Re: "Rites of Passage" wheel reinventing
by talexb (Canon) on Feb 26, 2004 at 22:50 UTC

    Just wanted to thank you for reminding me about 'backface culling' -- at CEGEP (what they call college in Quebec) back in 75/76 we had access to an HP 9810 Programmable Calculator, and one of the geeks managed to do 3D plots of cos(x)/exp(x^2) -- with backface culling (although I never knew what it was called until now).

    That was an absolutely fascinating tool -- one day, I decided to plot sin(x) on the x axis and cos(x) on the y axis to see what kind of wacky curve I'd get. Of course, it started drawing a unit circle. D'Oh.

    Alex / talexb / Toronto

    Life is short: get busy!

      ... one day, I decided to plot sin(x) on the x axis and cos(x) on the y axis...

      And x on the z axis lol. Sorry, but i couldn't resist ;)
Re: "Rites of Passage" wheel reinventing
by demerphq (Chancellor) on Feb 26, 2004 at 22:00 UTC

    Data::Dump::Streamer, some logging kit, a horrible horrible wrapper for MIME::Lite from when I first started perling. Funny thing is now im the maintainer of MIME::Lite. :-)

    As for the rest, most of the things ive reinvented have been for learning purposes and I doubt they count.


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

Re: "Rites of Passage" wheel reinventing
by stvn (Monsignor) on Feb 27, 2004 at 03:11 UTC

    Having not gone to college for Computer Science, or anything at all like it (I finished 2 years of Fine Arts Painting). I never had to build the requisite stacks, trees and other such classic CS data-structures, nor did I have to re-invent the wheel because a teacher didn't allow the use of modules (as it seems is the trend by all the homework that the college interns at work have to do). So for my own self-education I have re-invented countless wheels and re-created the equivalent of alot of low-level unctions found in most "standard libraries" (usually pretty badly I'm sure).

    This too is actually my prefered way of learning a new language. I build some well known and understood data-structures and/or re-implement my favorite module/tool from another language. For instance, I built a Tree object in C# recently to help learn the language, and I am currently building an HTML::Template-like module in C# as well (cause I hate the code-markup mix of ASP.NET). These efforts have helped me immensely in understanding the ins and outs of C#, and of course this too has helped me in Perl as well.

    Basically, what I am saying is that wheel re-invention can be an excellent learning tool. But I do agree with alot of the posters above, that re-inventing the wheel makes no sense if you are ignorant of the other options out there.

Re: "Rites of Passage" wheel reinventing
by Limbic~Region (Chancellor) on Feb 26, 2004 at 23:03 UTC
    I am not sure if Tie::Hash::Sorted qualifies. The wheel it replaces needed replacing. People have mentioned they thought I was re-inventing this wheel but ordered ne sorted.

    Cheers - L~R

Re: "Rites of Passage" wheel reinventing
by samtregar (Abbot) on Feb 27, 2004 at 04:43 UTC
    1. Several lightweight templating packages, instead of using HTML::Template or TT (though I use HTML::Template a lot now)

    Funny you should mention it, HTML::Template is first on my list!

    One you didn't mention, though, is an OO wrapper for DBI. I'm sure we've all got one of those rotting away in the attic. The day I realized SQL wasn't that bad was a good day indeed...


      There's two ways to look at this:

      1. it's a mistake to reinvent the wheel if a good implementation matches your needs. If it's nearly there, consider adapting it, but don't reinvent.

      This approach applies well to those focussed on getting the job done, to the end product. The proffessional job. Sometimes that's the right way to look at things. It's probably the fairest if someone is paying you to do the work (after all starting from scratch will probably take longer).

      2. By all means reinvent the wheel. Then you'll see why I did it that way first. You'll make the same mistakes, probably abandon your project and then use my/someone elses existing one.

      This approach might actually be the correct one if your main concern is process and understanding. The journey, but not necessarily arriving. Why? Because sometimes when it's not a job it's the learning thats important. In these circumstances, making the mistakes informs you of why other implementations did it that way in the first place. Then you can start afresh understanding more deeply an existing implementations (in terms of both it's strengths and weeknesses). You make an informed decision.

      I must have programmed several hacked-up parsers (even after having completed my CS courses on parsers and compilers) before really understanding why the seemingly theoretical approach of my courses could be valuable. Now I know - a hacked together parser is probably not maintainable.

      I personally think that a rounded programmer should practice both of these approaches. Probably the wasteful one in his/her spare time, but nontheless blindly applying approach 1. doesn't necessarily deepen your knowledge - which I personally value highly.

      How's that for a bit of meditative thinking?
Re: "Rites of Passage" wheel reinventing
by dragonchild (Archbishop) on Feb 27, 2004 at 13:39 UTC
    In CS101, everyone writes a version of several search routines, several sorting routines, and many other common algorithms. In Chem101, you go through a number of common experiments. In a way, these are rites of passage, as well, but not the ones, I think, you're referring to.

    As for wheels ...

    1. A OO representation
    2. Numerous chess-validators
    3. Alpha-Beta algorithms (back when I was messing around with a Go-playing program)
    4. PDF::Template, Excel::Template, Graph::Template ... when I could've just written plugins for TT. (I'll write them, once we convert to TT.)
    5. And the one I'm least proud of - a scheduling algorithm for a small airline company, in Pascal.

    We are the carpenters and bricklayers of the Information Age.

    Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Re: "Rites of Passage" wheel reinventing
by Ctrl-z (Friar) on Feb 27, 2004 at 11:32 UTC
    Interestingly, I find im guilty of most of my questionable reinventing in perl. Other languages, that have well defined Standard Libraries, I seem less likely to muster the hubris.

    is that just me?

    time was, I could move my arms like a bird and...

      I think that it cuts two ways. For example, CPAN has many XML modules. Do we need them all? Probably not, but there is often one that suits your needs better than say a standard DOM or SAX parser library might. This means that I'm less likely to reinvent the wheel, as there's bound to be a module that meets my requirements.

        Don't forget that if there is a lot of modules just for XML, this means that they are not covering all that the users needs. A developer won't spend it's time to build a module just to say that it has his module, specially for XML that is not a simple thing to handle. Also means that the main XML modules that are there are not simple and easy to use as the users want. Since XML was created to make the integration between different systems/programs and architectures easy. And if the use of this is not easy, is just crap. Each developer, of each XML module is just tring to find a better way to do things.

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

Re: "Rites of Passage" wheel reinventing
by Kageneko (Scribe) on Feb 27, 2004 at 16:42 UTC
    1. Muds, mushes, etc - About every six months, I start a new one from scratch. Eventually I'll actually finish one :) My most recent used perl as the scripting language and overdosed on the Safe module. I'm still sorta sad I never finished it.
    2. Simple scripting languages - Designed for very very specialized things. For example, I wrote this weird test harness language that turned out to be very similar to what make uses.
    3. Simple templating systems - Again, really specialized. My most recent helps me convert some D&D text files into HTML. (this is the result). They automate class tables and such.
Re: "Rites of Passage" wheel reinventing
by blue_cowdawg (Monsignor) on Feb 29, 2004 at 13:16 UTC

    In Thoughts on script portability I touched upon some of the reasons why you might "re-invent the wheel." Sometimes all you have are sticks and stones and you have to be inventive.

    I can think of another reason you might want to re-invent the wheel. If you have a crusty professor like I am when I am teaching you are darn sure going to end up re-inventing the wheel.

    When I was teaching Perl to college students I often would pose a problem to them, for instance (right out of my lesson plan:)

    Write a script to parse an input file and create a tree of HTML elements and their leaf nodes.
    Now if I had to solve that problem in the real world I would be looking to CPAN in the HTML::* space for the right module. But for someone learning Perl it is a good intellectual excercise to have to invent that wheel and program for it.

    Peter L. Berghold -- Unix Professional
    Peter at Berghold dot Net
       Dog trainer, dog agility exhibitor, brewer of fine Belgian style ales. Happiness is a warm, tired, contented dog curled up at your side and a good Belgian ale in your chalice.
Re: "Rites of Passage" wheel reinventing
by Paulster2 (Priest) on Feb 28, 2004 at 16:56 UTC

    Well, not that I have rebuilt any wheels in recent history, but I have done things in one language instead of another, just because it's a little more challenging. I bet all of us do that though. The other thing is that when I write stuff, I bet that it has already been done, but it would take me a lot longer to find what someone else has done than it would to build my own.

    I need to get out more.


Re: "Rites of Passage" wheel reinventing
by fraktalisman (Hermit) on Feb 29, 2004 at 13:07 UTC
    Another aspect is reinventing one's own wheels.
    I often write scripts that allow my customers to do something on the web with as little knowledge as possible of things like HTML, CSS, etc.
    When those tools finally start being used by the real customers, my to-do-list is constantly growing. Sometimes when I look at the project and the suggested updates, I decide it's after all easier and a cleaner solution to start the whole thing new instead of patching around. So then I restart from scratch, pasting some useful pieces of the old code if possible.
Re: "Rites of Passage" wheel reinventing
by Aristotle (Chancellor) on Feb 28, 2004 at 11:35 UTC
    I can't believe noone mentioned CGI.pm itself. Yes, of course, a templating system also. But hey, at least even without even knowing of CPAN, and as a whee Perl toddler, I understood that separation of concerns was a good thing. :)

    Makeshifts last the longest.

Re: "Rites of Passage" wheel reinventing
by rkg (Hermit) on Mar 02, 2004 at 01:59 UTC
    I find myself (re)writing OO date modules on top of Date::Calc again and again... hard no-clear-right-answer functions that run into the nuances of the calendar, such as this_week_last_year, ytd_last_year, etc.
Re: "Rites of Passage" wheel reinventing
by ambrus (Abbot) on Feb 27, 2004 at 19:46 UTC

    I'm guilty too in reinventing wheels just because I didnt look up for already implemented modules.

Re: "Rites of Passage" wheel reinventing
by PhiRatE (Monk) on Mar 04, 2004 at 13:37 UTC
    <matrix>You do not know a problem, until you have tried to implement a solution</matrix>