Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re-inventing the wheel is a 'Good Thing'

by Felonious (Chaplain)
on Apr 28, 2002 at 14:58 UTC ( #162660=perlmeditation: print w/ replies, xml ) Need Help??

It's almost an automatic given that whenever you post a question about some code you've puzzled over for days, someone will point out that module X or project Y already does that, and say "Don't re-invent the wheel!". That's fine. You should know that there exists code out there that has already solved the problems you're facing. And you should normally use that code if time or reliability is critical.
However, if you've got the time, "re-inventing the wheel" can be a very strong teaching tool. What better way to learn real programming than to actually do real programming, knowing you have a working example to refer to if you are stalemated by a problem? And when it's done, you can compare your works to see where you could have done it better. This often sheds light on things beyond simply "getting it to work", like writing more maintainable, re-usable, secure and efficient code, in a concrete way that books often have a hard time conveying. You begin to really understand things like, "why I need to implement file-locking 'this way' to prevent race-conditions" or "why I should not shell out to do this with backticks".
And once you've become enlightened, you won't be so quick to tell the next guy, "Don't re-invent the wheel!".

-- O thievish Night, Why should'st thou, but for some felonious end, In thy dark lantern thus close up the stars? --Milton

Comment on Re-inventing the wheel is a 'Good Thing'
(jeffa) Re: Re-inventing the wheel is a 'Good Thing'
by jeffa (Chancellor) on Apr 28, 2002 at 15:13 UTC
    Good points, but i do have a problem with not telling someone "Don't re-invent the wheel!" Finding out why they are trying to re-invent it first, then making the judgement call is better - but 9 times of out 10 the person in question does not realize that their problem has already been solved.

    Just a nitpick, i would have prefered the title "Re-inventing the wheel is not always a 'Bad Thing'". =)

    jeffa

    learning++
      Good points, but i do have a problem with not telling someone "Don't re-invent the wheel!" Finding out why they are trying to re-invent it first, then making the judgement call is better - but 9 times of out 10 the person in question does not realize that their problem has already been solved.

      I agree. And 9 times out of 10, once they know it's already been done, they'll use it. I'm just encouraging people, If they've got the time and want to improve their skills, not to let people dissuade them from pursuing something that might ultimately further their understanding of programming.

      Just a nitpick, i would have prefered the title "Re-inventing the wheel is not always a 'Bad Thing'". =)

      That's exactly the title I gave it when writing it:P I remembered some advice from somewhere though that it is more appealing to "argue" a positive than to "argue" a negative, so I renamed it.

      -- O thievish Night, Why should'st thou, but for some felonious end, In thy dark lantern thus close up the stars? --Milton
      9 times of out 10 the person in question does not realize that their problem has already been solved

      True, but even if someone realises their problem has already been solved, they may not choose the best solution. One of the main problems facing Perl is that the first Perl code/tutorials/books people often encounter are badly written. Many newcomers learn Perl badly, but are unaware they're doing so.

      If you choose to reinvent the wheel for any reason, point people towards better solutions. This prevents anyone using your code because they're unaware anything better exists.

        Unless of course *gasp* you write a better solution...
Re: Re-inventing the wheel is a 'Good Thing'
by ignatz (Vicar) on Apr 28, 2002 at 16:00 UTC
    Advice that never gets old:
    • "Doc, it hurts when I do this." "Don't do that."
    • If it ain't broke, don't fix it.
    • Don't reinvent the wheel.
    I would have killed for a don't reinvent the wheel back at my first Perl gig when I decided to write a half assed template toolkit.

    People who tilt at windmills need to accept the fact that other's may not want to join them on their quest.

    ()-()
     \"/
      `                                                     
    
      Well it is also advice that might be bad.
      "Doc, it hurts when I do this." "Don't do that."
      That one I usually agree on, but there are lots of times when you have to. Consider the patient coming into the doctor saying "It hurts when I breathe." That happens in engineering too. :)
      If it ain't broke, don't fix it.
      This is considered by many to be really bad advice, in software specifically we could mention all the XP and refactoring guys - they strongly advocate fixing unbroken code constantly. It is called "improving the codebase by constant refactoring", and yes, it is really fixing, and it is often of perfectly working code. In all areas, including software, the mentality of not fixing "whole" things might lead to stagnation, and hinders evolution of better products. In my opinion, better say.
      Don't reinvent the wheel.
      Same here. Even the wheel might work even better, and sometimes the best way to make the wheel roll smoothly is to start over with nothing, just thinking... I wonder what the best way to transport a box forward would be?

      Don't get me wrong. All of those advices are valid up to a point, and it will always depend on the situation. But I think it is plain wrong to just take them for given, and not even considering questioning if those advices are really the best for any given situation.

      There might be a lot of benefits to ignore the old sayings when programming. :) Then again, there will be situations where those advices really are the best... consider the patient coming to the doctor saying "It hurts when I hit my head with this hammer." or when all you need is to fix the flat tire on your bike.

      I would have killed for a don't reinvent the wheel back at my first Perl gig when I decided to write a half assed template toolkit.
      I've done that and tons of other "stupid" stuff as well, and no matter how little, at least I learned something from it. I now know lots of stuff, useful or not, that I would have no idea about otherwise, and that might very well come in handy in one situation or the other. I think you can get a lot more punch out of any given module, snippet or wheel if you also have a basic understanding on what it does and why.

      Then again, I might be plain delusional. :) It is very late here after all, and as always, YKMV.


      You have moved into a dark place.
      It is pitch black. You are likely to be eaten by a grue.
Re: Re-inventing the wheel is a 'Good Thing'
by tune (Curate) on Apr 28, 2002 at 17:07 UTC
    I think sometimes you can go with the already existing solution , and sometimes you should choose your path.

    If your question aroused when you were learning and found an interesting problem, which makes you itchy to work out, then choose your way, and write the code yourself. Probably it will do no harm if the result is not perfect or lacks of features.

    If your boss is standing behind your back bugging you, then go with the already invented wheel (CPAN modules, existing methods, etc.)

    --
    tune

Re: Re-inventing the wheel is a 'Good Thing'
by cjf (Parson) on Apr 28, 2002 at 19:41 UTC
    Don't re-invent the wheel!

    First off, I hate metaphors, so for clarity's sake I'll say "Don't rewrite existing code that has been thoroughly tested." Now, perhaps it's a bit more clear that the justification for rewriting such code compeletely depends on the situation you're in.

    Some points to consider:

    • Is the code for production use? Will it be placed online? Reliability and security are key for these. So best to use extensively tested existing code if it's available.
    • What will you learn from writing the code? This is the best argument for re-writing code.
    • Licensing issues - maybe an existing piece of code uses that evil artistic license and you want to rewrite the code, improve it (may or may not happen), and release it under the GPL ;-).
    • Time, Time, Time - Re-writing code takes it. So if you're on a tight schedule, or merely wish to minimize time spent on a given project, you have yet another reason to use existing resources.

    So my general rule is when solid code already exists, use that for production use and only rewrite code as an educational venture.

    Update: Forgot to mention the whole wasted developer time issue and how much of the open source community is greatly opposed to it, for some good, and some not so good, reasons. Consider it mentioned and see The Cathedral and the Bazaar for more details :).

Re: Re-inventing the wheel is a 'Good Thing'
by tjh (Curate) on Apr 28, 2002 at 22:17 UTC
    Felonious: "It's almost an automatic given that whenever you post a question about some code you've puzzled over for days, someone will point out that module X or project Y already does that, and say "Don't re-invent the wheel!". That's fine."

      It's possible to search prior art as thoroughly as one can, not find anything, code and post, and still get a "Don't re-invent the wheel!" admonition. Sometimes, I think we don't know we've reinvented something. There are many modules (many of which are excellent), often under arcane names or we don't know the cannonical name for the thing we just reinvented ...

    Felonious: "What better way to learn real programming than to actually do real programming, knowing you have a working example to refer to if you are stalemated by a problem? "

      ++Very true when someone's in 'student mode'. I'm a big believer in reinventing wheels when it's convenient, useful, or necessary to do. But when speed and/or certainty are at stake, it's probably a luxury at best, a costly boondoggle at worst.

    jeffa: "True, but even if someone realises their problem has already been solved, they may not choose the best solution."

      Many times, for neophyte to middle-skill coders, this is a real problem. There are other threads here about speculated rating (popularity or XP-like) systems for CPAN modules, PM-like comment threads attached to each module for other's to review, etc. I for one, would like some type of solution, at least like the PM discussion threads. Trying to choose among competing modules can be confusing and time wasting (see above:). When in unfamiliar territory I normally search with Google and at PM for module discussion when I'm having some difficulty choosing a module. It would be useful to have much of it in one place.

    BUU: "Unless of course *gasp* you write a better solution..."

      Absolutely, and a rating or discussion system that was maintained and managed as well as PM is would be outstanding, since many of us may not always know why one is better than another.

      (wow - Imagine trying to agree on the rating system validity) Ok, I recant - the rating system idea seems overly complex. I vote for multi-topic threaded discussions for each module...:)

    Just my 0.02 meditation.

Re: Re-inventing the Wheel is not Always a 'Bad Thing'
by tadman (Prior) on Apr 29, 2002 at 01:36 UTC
    If nobody ever bothered to reinvent the wheel, we would still be driving around on stone wheels with wooden pegs. I'm happy to see people take a new crack at an old problem, because sometimes they actually come up with something astoundingly new. Naivety can be an asset, without it most people would never undertake seemingly impossible tasks and would just stick with the status-quo.

    There are many historical examples about how rethinking an old problem that has been "solved" has yielded fundamental breakthroughs. One is the halogen lightbulb, which is really just a new twist on an old idea, but with incredible benefits.

    Some of the CPAN modules out there that have already invented the wheel are so old, or poorly implemented, that they can hardly be considered for some applications, especially commercial ones. This is only because there are so many modules, some good, some bad, and of course, some ugly.

    Software bio-diversity is important for real innovation.
Re: Re-inventing the wheel is a 'Good Thing'
by Molt (Chaplain) on Apr 29, 2002 at 11:15 UTC

    Okay, I admit it. I'm one of the people who tend to tell people not to reinvent the wheel, and yet whilst doing this I often have my incredibly crufty Inline::CPP self-built analogue of Data::Dumper sitting happily in an editor on my desktop.

    Hypocritical? Maybe.

    Pragmatic? Most certainly.

    When I tell people to reuse existing wheels it's because it sounds like they're after something to use in a larger project, and the best way to get something that works reliably and quickly is to use the tried and tested solution. It should work well enough, and you probably won't end up with as many holes for people to poke at as if you'd just deployed the untested and unviewed by others code.

    So, why am I redoing Data::Dumper? Does the original have problems? From what I gather the answer to this is 'Yes, but I don't think I'm yet up to the task of fixing them, or building a better version'. I'm doing it to develop my skills, my understanding, not to develop a product. When I do things requiring persistant data for production work I reach for the original, or another recognised varient upon the same basic theme.

    Essentially I think there's three circumstances.. When you need the wheel to work properly and don't have the time or ability to build Wheel++ then go with the existing wheels; when you have time to learn new things try and develop your own version of existing things- you probably won't acheive the same quality, but you learn, and you can use the original versions more effectively when the time comes; and the final state is both having the time and ability to build the better wheel in which case go to it.

    One favour though, please try and modify the existing wheels rather than creating a new one wholesale unless there's absolutely no way round it. We lesser mortals do not want to spend too long learning to build new axles!

    Now, if you'll excuse me I have to hack some more at a wheel that's looking remarkably square at the moment. All part of the wheelwright's craft, I hope to get nice round wheels eventually though and when that comes I'll let others use my wheels.

      my incredibly crufty Inline::CPP self-built analogue of Data::Dumper

      Interesting. You and I should chat. :-)

      So, why am I redoing Data::Dumper? Does the original have problems? From what I gather the answer to this is 'Yes, but I don't think I'm yet up to the task of fixing them, or building a better version'. I'm doing it to develop my skills, my understanding, not to develop a product. When I do things requiring persistant data for production work I reach for the original, or another recognised varient upon the same basic theme.

      Bravo. I too have been reinventing this particular wheel. (See Reinventing the wheel: Dumper Difficulties). I can guarantee that you will learn cool stuff.

      Not to be egotistical but I know im up to the task of fixing them (at least at the perl level). If you or anyone else was interested in working with me to produce an XS version of my code then I would be happy indeed to have the collaboration.

      As for using Data::Dumper for persistancy purposes I strongly recommend that you dont if the data strcutres in question are self referential, and if they involve refernces to items contained in aggregate objects. These will be dumped very subtly and seriously wrong.

      Which brings me to my point. Anonny monk (Yillt?) said that wheels dont get to be standard unless many people have looked at them... True. But Data::Dumper is an example of where many many worked patched reviewd and analyzed (and they are some of the best) but did they notice the subtle bugs? No they didnt. In fact I didnt even notice the bug in my own code becuase I foolishly assumed that Data::Dumper couldnt get things that wrong. I completely agree with tadman when he says we would still be driving around on stone wheels mounted on wooden pegs.

      The moral for me is that reinventing wheels is fine and dandy, so long as you have studied the shit out of the subject first...

      ... Or are doing it for plain and simple self satisfation, either as a learning exercise or as mountain climbing. Why did I climb it? Hmm, good question. I suppose because it was there?

      Yves / DeMerphq
      ---
      Writing a good benchmark isnt as easy as it might look.

Re: Re-inventing the wheel is a 'Good Thing'
by DaWolf (Curate) on Apr 29, 2002 at 20:57 UTC
    I like reinventing wheels.

    Please don't get me wrong, I love to discover a module that is excellent but I also like to know what I'm doing right and what I'm doing wrong as graff noticed on Formatting MS Access Currency Values.

    I can't tell you how his post made me happy, I was being told exactly what I was doing wrong and I understood. Don't get me wrong again, all the others - molt,gryphon - were great and yes I was in a hurry to finish a project's part, but graff's post was vital to me.

    I only began to use modules ver recently and I think they're fantastic, but you can't focus only on them or you'll become nothing but a code blacksmith - joining code pieces so your app works - and this is very bad.

    I think, and I say this with all due respect, brothers and sisters, that sometimes you forget you're dealing with people that doesn't have half of your skill. I'm not kissing a**es here, but look this example:

    In the already mentioned Formatting MS Access Currency Values it was pointed to me the following solution: How do I add commas to a number?. Ok, it's great and I understood - it took me some time to research about that code but I did. But I think sometimes the solutions you people "throw" looks more like obfuscated code than enlightment.

    I know that nobody here is payed to answer everybody's doubts, but I really think we should be more clear on the answers. It's easy to make people copy and paste code, but then we wouldn't helping perl to keep growing and to keep being used for more and more newcomers.

    As a foreigner, I really hope I don't get misunderstood here, I love perlmonks, and I always recommend this community for my friends because it's great.

    Peace, brothers and sisters.

    my ($author_nickname, $author_email) = ("DaWolf","erabbott\@terra.com.br") if ($author_name eq "Er Galvão Abbott");

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://162660]
Approved by particle
Front-paged by cjf
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (7)
As of 2014-12-22 00:40 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (110 votes), past polls