Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Reinventing the wheel

by cavac (Chaplain)
on Nov 02, 2011 at 21:37 UTC ( #935499=perlmeditation: print w/ replies, xml ) Need Help??

Some of you might know, i wrote my own webserver in perl, based on HTTP::Server::Simple. In a few days, i'm going to have another lecture on the topic in Vienna. As always, i'm probably going to get accused of "reinventing the wheel".

In this meditation, i'd like to talk a little about why this accusation is - in my opinion - not only not an accusation, "reinventing the wheel" can, from a historical viewpoint, even mean "wow, you changed the world for the better". Not that this is ever going to happen to me, but i'll show you what i mean:

First of all, when somebody talks about "reiventing the wheel", he or she usually bases this on the context of the wheel being the ultimate tool for transport, as in the recently granted patent for the "circular transportation facilitation device". He or she also implies that reinventing the technology is a complete waste of time.

While the wheel itself certainly plays a major part in transport, there are a number of applications it's not usefull - either not alone or not at all.

Examples of this include rough off-road usage, where Continuous tracks around the wheels are a big help. Feet are one of natures solutions that also work quite well off road. Wings are a great alternative when you need to cover vast distances fast. Underwater, you might find Fins and propellers vastly more usefull than the good old wheel. And if you ever have to evacuate an airplane quickly, you will most likely use a slide.

So, after having established that the wheel is not the ultimate in transport technology (meaning that you have to look for alternatives as well), let's take a closer look at wheel technology itself. As clearly evident, early wheels where based on wooden and bronze disks without "real" bearings. That technology failed even before the iron age because it just wouldn't work on the increased loads and distances required for trading at that time. So, the wheel was reinvented using spokes and better bearings. Then, modern transports like bicycles, cars, airplanes, tanks, trains and what not came along. They all needed their specially designed wheels that have not much in common with the wheels in use by the roman empire. Just a few years back, another company did another reinvention of the wheel, called the "Tweel".

So, concluding the semantic part, reinventing the wheel is not only sometimes a good idea, it's often required for new breakthroughs to happen. We also just proved that the wheel is not the ultimate transport technology, just one of a number of solutions. And - here's one more interesting point - by reinventing the wheel, we, the humans race as a whole, learned a little bit more about the universe we lived in.

Before we go to the problem at hand, let's have another paragraph or two looking at another technology. Most people think of it as a recent invention, never realizing that its origins go back to at least 521BC (or more): Email. While Wikipedia lists early origins like morse code (mid 1800s), the idea of Email in its current form looks very much like the electronic version of the Postal system.

One of the first postal systems was in service in Persia. While the dates vary, there is a range from 521BC to even possibly back to 1700BC. From that time on, the system was constantly updated, changed, forgotten, reinvented and changed again and adapted to special needs. This took on some "strange" forms over time, like the short lived "fast mail service" called Pony Express. The Pony Express failed, but modern express mail and parcel services use a similar system of relay stations. They just reinvented the system by using trucks and planes. Email is not that different. It uses relay stations, delivers people's mail faster than its predecessors - and probably delivers more messages per day than Bristish Mail did in their whole history. It just did that by switching technology. By every "upgrade" and "reinvention", we learned a bit more about what works and what doesn't, how to use the technology available.

Now, arriving at the present: What more could i actually say? I wanted to learn about a modern technology, the World Wide Web. I wanted to adapt it to my needs, maybe improve bits of it. So, i "reinvented" some of the technology by writing my own webserver. I notified a browser vendor about a potential security flaw i found. I learned about what works and what doesn't. I made the software open source so others could learn from my triumphs and my failings.

Is that a really bad thing? Was that really a waste of time? And if it was, wasn't it mine to waste anyway?

Don't use '#ff0000':
use Acme::AutoColor; my $redcolor = RED();
All colors subject to change without notice.

Comment on Reinventing the wheel
Re: Reinventing the wheel
by JavaFan (Canon) on Nov 02, 2011 at 22:36 UTC
    And if it was, wasn't it mine to waste anyway?
    Don't be silly! You cannot judge how to waste your time. The accepted Perlmonks mores is that reinventing anything that's already on CPAN is bad, because the mere act of uploading code onto CPAN, makes the code awesome and the author a demi-god(dess). Reusing anything that wasn't written in Perl is horrible, one should always, without exception, prefer something written in Perl over a tool that has been improved over the past 40 years. Only people intended to destroy the Perl culture would use system.

      You are right, of course. How could i even dare to have a mind of my own? I am just a humble scribe, after all. ;-)

      But may i, my dear abbot, beg to ask a humble question while i'm kneeling here before the holy camel?

      The question is this: Why, if reinventing the wheel is such a bad thing, do we still work on Perl 6? ... No, wait, i just saw the error of my ways. If reinventing would be a good thing, shouldn't we have finished getting Perl 6 to a working state a long time ago?

      Edit: For those of you wanting to downvote this node: Do you know the meaning of humor? No? Try pull the other one....

      Don't use '#ff0000':
      use Acme::AutoColor; my $redcolor = RED();
      All colors subject to change without notice.

      Funny, I thought the accepted party line was "If you're going to write your own {mail server, mail parser, XML parser, web server, et cetera} and you don't know what an RFC is or why that matters, you're wasting your time."


      Improve your skills with Modern Perl: the free book.

        To be fair, you *are* crazy if you want to write your own MTA, but only because there are so many weird requirements and buggy implementations that you'll have to be compatible with.

      The accepted Perlmonks mores is that reinventing anything that's already on CPAN is bad, because the mere act of uploading code onto CPAN, makes the code awesome and the author a demi-god(dess).

      How ilLogicus of you

Re: Reinventing the wheel
by Logicus on Nov 02, 2011 at 23:25 UTC

    The universe itself is constantly re-inventing everything that exists moment by moment. If you try to remain static you become a dinosaur.

    My sin, which causes me to feel similar feelings to the ones which have obviously prompted this meditation, was to invent something new which is similar to many existing wheels but has about as much in common with them as those Tweels do to traditional Wheels.

    I've reinvented Coldfusion they say...

    It's just like Microsoft XAML still others mutter...

    No I think it's more like lisp says another one...

    The irony being at the end of the day all the thing really does is provide a different method of specifying perl sub-routine calls and allowing them to be embedded in other data.

    So really I've reinvented the Perl subroutine declaration standard, and made it do new groovy things that it couldn't do before, without losing anything that it was previously capable of.

    But it sucks, it's sh**, and it can't possibly work, so i t needs flushing down the toilet according one particularly "prophetic" priest.

     s/proph/path/
Re: Reinventing the wheel
by davido (Archbishop) on Nov 03, 2011 at 01:45 UTC

    A few points:

    • Learning for the sake of knowledge is not necessarily re-inventing. How many frogs have been dissected? Surely documentation provides ample detail as to what one will find inside a frog's body cavity. There is merit in this form of re-invention: Experience.
    • Reinventing the Good Year Eagle LS-2 tire all over again for any reason aside from educational value would be stupid. But standing on the shoulders of the Good Year Eagle LS-2, tearing into it, educating oneself all about it, and redesigning it with "Run on Flat" technology would add value. If your goal is to create a tool that satisfies a need not addressed in existing tools, you're not re-inventing, you are inventing incrementally with the benefit of a solid understanding of "prior art."
    • There are many other reasons for reinventing. But there are many pitfalls too. The oft (overly) repeated mantra of "don't reinvent the wheel" assumes that the inventor hasn't any compelling reason to reinvent aside from the ignorance of being unaware of the availability of a suitable wheel.

    When re-inventing, either learn something by doing, prove something thought impossible, innovate something as yet unavailable, or refine something that needed improvement. Presumably in such instances enough thought goes into the final product that it has value-added over the existing solutions. In those cases you're really not re-inventing, you're developing.


    Dave

Re: Reinventing the wheel
by Anonymous Monk on Nov 03, 2011 at 02:27 UTC

    What more could i actually say?

    How many inches of code is this thing?

    Is that a really bad thing?

    Not at all, you did your homework

    Was that really a waste of time?

    Yes, if you think so, and No, if you don't

    It certainly wasn't a waste of my time :)

    And if it was, wasn't it mine to waste anyway?

    Bingo.

Re: Reinventing the wheel
by zentara (Archbishop) on Nov 03, 2011 at 10:32 UTC
    You never really know how a wheel works, until you tear it apart. I bet you now know more than most about the http protocol, now that you built your own. I think building your own webserver is a great educational exercise, because it exposes you to all the problems involved, and also makes you appreciate the pre-made wheels that are given to us.

    I think this also applies to object-oriented programming.


    I'm not really a human, but I play one on earth.
    Old Perl Programmer Haiku ................... flash japh

      I bet you now know more than most about the http protocol, now that you built your own.

      I don't claim to know all of http. But the important parts i think i understand, yes.

      I think building your own webserver is a great educational exercise, because it exposes you to all the problems involved, and also makes you appreciate the pre-made wheels that are given to us.

      There are a few quirks in the protocol, but i spend at least half the time wondering why a correctly implemented feature wont work... until i found the correct browser workaround. And not all of the browser bugs are bugs, some are backward compatibility workarounds in the browsers that i now need to workaround in the server. Insert facepalm here

      So, yes, i did learn quite a lot. And on the side, i even got a working product out of it ;-)

      Don't use '#ff0000':
      use Acme::AutoColor; my $redcolor = RED();
      All colors subject to change without notice.
Re: Reinventing the wheel
by thundergnat (Deacon) on Nov 03, 2011 at 15:43 UTC

    There is nothing wrong with re-inventing wheels. Re-inventing wheels is an excellent educational exercise and a fine way to learn how wheels work. One of the most effective way to learn how some high-level construct works is to have to take care of handling all the low level stuff yourself. It will give you an appreciation for how other wheel implementors did it (or possibly point out some problem in their implementations) and highlight the difficulties of making wheels that work with both racing bicycles and earth-moving equipment. And who knows? you may even invent mag-lev transport.

    The problem is with saying "Hmm, I need a new set of wheels for my car. It can't be that hard, I'll whip some up in my basement." and ignoring all the research and testing that has gone into make wheels better over long periods of time, when really, all you want is a new set of wheels. It could work, but you'll probably spend more and take longer than just buying something from your local wheel shop. Most likely, you'll end up with something that doesn't work very well or even ends up hurting you or someone else.

    Even more annoying to their fellow mechanics is when someone re-implements a wheel, then loudly proclaims that their wheel is "TEH BEST WHEEL EVAR!!1!11" and everyone else should immediately switch to using their wheel and that anyone who points out that this new wheel has only been tested on a 1957 MG midget, at 25 MPH, falls off randomly and requires buying a whole new set of tools to change the tires is met with "YOU AR TEH SUCK, FIND SOMEONE ELSE TO REPRE#SS, YOU ELETIST SNOB!!!". It may actually even be better, but without compelling evidence, few people are likely to switch.

      Even more annoying to their fellow mechanics is when someone re-implements a wheel, then loudly proclaims that their wheel is "TEH BEST WHEEL EVAR!!1!11" and everyone else should immediately switch to using their wheel and that anyone who points out that this new wheel has only been tested on a 1957 MG midget, at 25 MPH, falls off randomly and requires buying a whole new set of tools to change the tires is met with "YOU AR TEH SUCK, FIND SOMEONE ELSE TO REPRE#SS, YOU ELETIST SNOB!!!". It may actually even be better, but without compelling evidence, few people are likely to switch.

      That’s really stretching. You’d be hard-pressed to find any sort of real world example of that. In Perl. Around here. Lately. Relentlessly.

      Non, je nnnne reeeeeeeeegrrrrrrrrrrette rrrrrriiiiiiiien!

Re: Reinventing the wheel
by Jenda (Abbot) on Nov 03, 2011 at 16:07 UTC

    "Reinventing the wheel" is more often than not a remider that a wheel exists and as such meant to give you a chance to examine the existing wheels (you may not have known about) and see whether you really do want to spend time building your own. It might be the case that you know the old wheels and for whatever reason important enough to you, you decided to build a new one. It might, and quite often is, the case that you simply were not aware of the old wheels and one of them fits your needs perfectly. And it might be the case that reexamining the suggested wheels will improve the design of your new one.

    Yes, the time is yours to use as you wish, most of the "you are reinventing the wheel" posts just try to help you make an informed decision.

    Reinventing the wheel because you want to learn is good. Reinventing the wheel because all available wheels are suboptimal for your needs is fine as well. It's reinventing wheels because you did not know the old wheels that's a waste of time.

    Jenda
    Enoch was right!
    Enjoy the last years of Rome.

Re: Reinventing the wheel
by moritz (Cardinal) on Nov 03, 2011 at 16:26 UTC

    Related to the learning effect, but not entirely the same:

    Sometimes you need to reinvent the wheel (and recognize how poorly you did it) to recognize the value of the existing wheels.

    It has happened a few times to me and others close to me that I thought all the existing solutions to some problems where too complicated, overdesigned and/or overkill. Then somebody set out to reinvent the whole thing in simpler, learned more about the problem domain, and the end result looked not much simpler (if at all) than the existing solutions, and far less powerful.

    And that's not so surprising if you think a bit more about it, because most good pieces of software (or other engineering results) are iterations of previous, worse products, and the people who made them gathered lots of experience in the process.

    When you enter a new problem domain, you're overwhelmed by its complexity, and can't distinguish essential complexity from accidental complexity.

      Very well said. But sometimes you think you can simplify the process.eg.i thought I could simplify business management by using automatic software systems and making use of technology to get a better view of processes and using material tracking, automatic payments, flowcharts, displays etc. Now i think that would be better than people with registers and inefective haphazard management.How do you know if its essential or accidental complexity? But like you said im still new to it and probably overwhelmed by its complexity. Maybe gaining experience first and understanding would help. But still :) (please reply to this post not the previous one as I forgot to login)
Re: Reinventing the wheel
by Your Mother (Canon) on Nov 03, 2011 at 16:34 UTC

    I completely advocate building whatever you want: competition, evolution, test-bed, self-fulfillment, et cetera. That said—and there is some excellent commentary already—something no one has mentioned yet is the potential loss, to all parties, involved.

    Let’s pretend I’m a reasonably seasoned web dev—suspend disbelief if you would be so kind!—and I’m dissatisfied with Template Toolkit. I know all the alternatives, from TT3 in Alloy to Mason and Mojo::Template to Text::MicroTemplate and all points between. I’m informed. I’m competent. I can write tests and documentation and manage a civil mailing list. (It could happen!)

    The only major concern about doing a new templating system at this point is, why should I divide the effort? Isn’t even one of the current ones close enough to what I want for me to sink 5% of the time and effort it would take to start from scratch into improving and contributing to it instead? Ten years ago the answer probably would have been no, there’s plenty of unexplored territory. Today the answer is yes, my time and effort would repay me and everyone else better by joining a going concern as a contributor rather than starting over.

Re: Reinventing the wheel
by ruzam (Curate) on Nov 03, 2011 at 16:57 UTC

    There's a basic problem with this ideology of reinventing the wheel: Who defines the wheel?

    I believe the 'wheel' is that line between what you want to spend time on and what you don't. It's unique to each individual and changes continuously with your needs.

    For some the wheel is a complete mouse trap, for others it's just a steel spring. The wheel can include the all encompassing world of CPAN or nothing more than the Perl language itself. Heck, just proving you can (or can't) do something is often wheel enough.

    Anyone who suggests you're wasting your time reinventing the wheel, simply has a different definition of a 'wheel'. I for one don't believe it's possible to 'reinvent the wheel', because for you it was never a wheel to begin with.

Re: Reinventing the wheel
by dwalin (Monk) on Nov 04, 2011 at 13:08 UTC

    There is nothing wrong with reinventing the wheel. Wrong is not abandoning your wheel when you find another one that is significantly better than your own.

    Anyway, as I have found the hard -- and therefore, more convincing -- way, "to reinvent or not to reinvent" is hardly an essential question. *The* essential question is, what will cost me less, reinventing or adapting? From that perspective, the glory of achievement seems to diminish rather fast.

    Regards,
    Alex.

Re: Reinventing the wheel
by sundialsvc4 (Abbot) on Nov 04, 2011 at 13:24 UTC

    Yes, it really depends upon your project’s DFQ (Dissected-Frog Quotient), followed by your cauldron-burn and fire-bubble.   ;-)

    Seriously:   “laziness and hubris” are virtues.

    Just about everything that is ever done is more or less a reinvention of what someone else has done, and some of those things have indeed been significant improvements.   But a lot of time has been wasted over the years by folks who, having stumbled upon a “new” business requirement, just charge right into it without dissecting any frogs first.   They didn’t bother to look at CPAN, or simply didn’t know that it existed, or didn’t learn how to use it.   (Heck, they might not have really figured out what they were doing, CPAN or no!   “Cowabunga!!”)

    It can go the other way, too.   I once watched a group of people who ought to know better, at a great big famous computer company that certainly should know better, suddenly decide that another language is “better than Perl, just because it’s different from Perl, Perl is old, etc.”   They quickly established that the other language de jour had packages too, but they didn’t actually stop to see if the packages in the other language actually proclaimed to do the same things.   (Nor, if they did so, whether the packages actually worked.)   Mumbling something trendy about “scrum” or somesuch, they abandoned their perfectly-good private offices, crowded into a classroom for six hours a day where they gave each other copies of the latest cold or flu, and toiled mightily(!) ... striving to replace Perl code that works with non-Perl code that doesn’t.   (I suppose they succeeded in that quest.)   :-/   But the project was dead-meat from the start, because although they had a project process (“scrum,” seemingly grabbed from the latest sexy-trendy textbook of the day), they didn’t have a project plan.

    Thus ... my comment is actually serious.   This is engineering.   The guy who seems to be sitting on his asterisk in the air-conditioning, doing nothing but reading books in the library and drawing on pieces of paper all day, is the guy who’s actually working; not the ones who are assembling a great big structure out there in the heat.   Dissect those frogs!   Get out there and plan your project before you start on it.   Research what has already been done, thoroughly.   Methodically test the possibilities to see which one will move your project forward fastest and with the least risk.

      Yes, it really depends upon your project’s DFQ (Dissected-Frog Quotient), followed by your cauldron-burn and fire-bubble.

      You know, i think i just found a perfect quote for my next project meeting. I doubt many of my coworkers actually know their Shakespeare, though.

      Btw, it's "fire burn and cauldron bubble", not the other way around unless the project is based on reverse polish notation ;-)

      Don't use '#ff0000':
      use Acme::AutoColor; my $redcolor = RED();
      All colors subject to change without notice.
Re: Reinventing the wheel
by ForgotPasswordAgain (Deacon) on Nov 04, 2011 at 22:38 UTC
Re: Reinventing the wheel
by blue_cowdawg (Monsignor) on Mar 18, 2013 at 19:25 UTC

    If some of us didn't try and reinvent the wheel once in a while we'd still be using logs and parties of slaves numbering in the neighborhood of 100 or more to move big stones around.

    I make beer as a hobby. Why bother? After all I could just go to the liquor store and buy a six-pack of beer that is akin to making love in a canoe. Maybe I could spend more and buy one of those high falutin' beers made by that guy that jumps into vats of beer. Or spend even more money and buy imported beer.

    But wait, maybe I can make it myself and spend less per bottle. And it won't be beer that's sorta like making love in a canoe. Maybe it won't resemble the output of the average Clydesdale. There's also the sorta reasons I might build my own dresser instead of going to the furniture store. That concept of craftsmanship... yeah...


    Peter L. Berghold -- Unix Professional
    Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (14)
As of 2014-09-22 13:11 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (192 votes), past polls