Beefy Boxes and Bandwidth Generously Provided by pair Networks
Come for the quick hacks, stay for the epiphanies.
 
PerlMonks  

Re^3: Perl Monks += TMTOWTDI (fallibility)

by Aristotle (Chancellor)
on Apr 16, 2003 at 10:48 UTC ( [id://250835]=note: print w/replies, xml ) Need Help??


in reply to Re: Re: Perl Monks += TMTOWTDI
in thread Perl Monks += TMTOWTDI

The question is: they certainly make mistakes, too, but are you less fallible than TheDamian, Abigail or merlyn?

Makeshifts last the longest.

Replies are listed 'Best First'.
Re: Perl Monks += TMTOWTDI (fallibility)
by Abigail-II (Bishop) on Apr 16, 2003 at 12:02 UTC
    Actually, maybe he is. I think we should be very careful to put people on pedestals like this. Damian, merlyn, myself, and others you didn't mention might sometimes have ideas noone sane would ever have, inside the sugary layer with chemical flavours are regular coders. If would take some code of Damian, and post it here for review, without telling it was from Damian, it would be shredded to pieces, if only because it doesn't use strict or warnings. Merlyn probably has posted more articles containing buggy code on Usenet than the average monk has read articles. As for myself, well, my code is of course perfect, it's just taking the rest of you a long time to agree.

    Never assume that because it's written by person $X, it has to be good. Unless $X eq "Knuth" and $X is willing to pay money for each mistake found.

      Wise words indeed. I've often wondered about the need to elevate certain individuals in a community to god-like status. This, of course, transcends Perl (and programming languages, and software, and so on) but still, more often than not, seems detrimental. I don't think it really provides an incentive to most programmers, but then again I never paid attention in psychology ;)

      Also, as you touched on, near-fanatical devotions to certain paradigms doesn't help much either. Any code that doesn't conform to these specifications is instantly looked down upon. It's also the first thing that's looked for as a problem in posted code, often causing the reviewer to ignore actual errors and give advice like "add use strict, then repost" which doesn't really help anything.

      So basically "me too" to the parent post :)

        I might be inclined to post that on occasion, when the code shown is messy and the mistake not obvious. So even making an absolute out of "add use strict, then repost posts are useless" is (mostly *g*) useless.

        Makeshifts last the longest.

      Yes, maybe he is. Did I say otherwise? I said the question is if so.

      That TheDamian's code would get shredded for not using strict alone is a pointless fact. I doubt a lot of people would be able to fully grok the stuff he does, let alone recreate it under strictures.

      It's not a matter of whether code written by $X is good or bad; it's a matter of the probability of $X writing good code in relation to the probably of oneself writing good code.

      Makeshifts last the longest.

        it's a matter of the probability of $X writing good code in relation to the probably of oneself writing good code.

        True, however, if you can't understand the code, should you really be using it? How maintainable is the code if only Damian knows what it's doing? What's to prevent Damian from taking advantage of his vastly superior knowledge and inserting code that will turn my processor into a nuclear weapon and holding the world hostage until they pay him the sum of 1 Million Dollars! I mean, look at his picture, he's evil. EEEVIL.

      Hear, hear.


      Examine what is said, not who speaks.
      1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
      2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
      3) Any sufficiently advanced technology is indistinguishable from magic.
      Arthur C. Clarke.
Re: Re^3: Perl Monks += TMTOWTDI
by Anonymous Monk on Apr 16, 2003 at 11:47 UTC

    Well, I'm incredibly egotistical so I won't answer that. I will however say that using someone else's code, even if they are a far better programmer than you, creates several additional areas of concern. You have to ensure:

    • The code is not intentionally flawed.
    • The code is not trojanned in transit or due to server compromise
    • The original programmers are at least as competent as you at the task at hand
    • There are no licensing issues (including maintenance issues)

    I left out unintentional bugs although I've often found (keyword: found) far fewer in my code :). A much larger problem (especially in Perl) is style. I can read my code far, far easier than most other people's. I'm not talking about indentation, and unimportant/easily fixable issues here, but larger (mildly subjective) design issues. Often I've found it quicker to write a module than to read it, understand it, and do a quality assessment.

    However, your point is obviously a valid area of concern. To an extent it is the same issue that I'm using perl instead of writing my own language (rest assured, it is in my todo.list). You could even take it down to the level that I should be creating all hardware and software from scratch (unfortunately I'm not that good... yet). There must be a level of trust, or more accurately an acceptable risk threshold, when dealing with any technology. I'm just a little more paranoid than most.

    There are other advantages to this approach as well. If I had always just used existing tools and taken the easy way I don't think I would know half the things I do now. I also occasionally come up with something that improves upon the existing. And as crazy as it might sound, I also enjoy writing what is often considered tedious code (XML parsers, template systems, drivers). It's sort of a "well I haven't written project x yet, might as well go ahead." Or more articulately, as Richard Feynman once said "What I cannot create, I do not understand."

    So yeah, I'm just babbling on now, I intended this to be a two sentence response, really :). So point taken, but there are a bunch of other things to consider, and even if they don't outweigh your point, it clears out a couple bytes of my memory needed for reinventing stuff :).

      Yes, exactly. I wasn't advocating blind trust, either.

      Nor was I saying not to ever reinvent the wheel - it's the only way to learn. You just should be very sure your own wheel will end up round wheel before you dismiss existing ones and embark on creating one, when you're writing production code. There's also the issue of not having to maintain the wheel yourself if it's a standard issue one.

      And so on.. I think we basically agree here. :)

      Makeshifts last the longest.

        And so on.. I think we basically agree here. :)

        Not so fast! ;)

        You just should be very sure your own wheel will end up round wheel before you dismiss existing ones and embark on creating one

        Ah, but failure makes you appreciate the detail that goes into many programs. It leads to increased understanding of the issues that arise and tradeoffs that you have to make. Even completely "failed" projects can create something usable - knowledge.

        The maintenance point is a good one as well, better to get other people to do that work (as long as they don't mess with my interfaces ;)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://250835]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others learning in the Monastery: (5)
As of 2024-03-29 13:13 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found