in reply to Re: Perl Monks += TMTOWTDI in thread Perl Monks += TMTOWTDI
Damian is fallible like every else. O'Reilly has released several very bad books. Randal has made mistakes in articles. Search results don't tell much, especially for more complex queries. Perlmonks reviews are hardly ever in-depth, and tend to be regurgitating the API docs.
Trust nothing. Analyze the code for yourself.
Re^3: Perl Monks += TMTOWTDI (fallibility)
by Aristotle (Chancellor) on Apr 16, 2003 at 10:48 UTC
|
| [reply] |
|
| [reply] |
|
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 :)
| [reply] |
|
|
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.
| [reply] |
|
|
|
|
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.
| [reply] |
|
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 :).
| [reply] |
|
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.
| [reply] |
|
|
|
Re: Re: Re: Perl Monks += TMTOWTDI
by toma (Vicar) on Apr 17, 2003 at 08:28 UTC
|
The music that you are willing to give a listen
might not follow a strict set of rules.
Code is analogous to music.
My idea is that you might have a favorite artist
or a favorite art critic,
and this is analogous to having
a favorite module author or module reviewer.
You might invest a few dollars to buy the newest
release from your favorite musician without
first listening to it.
This is analogous to spending a few hours
evaluating a module from your favorite
CPAN author without knowing why you need the module
or if it is any good.
It should work perfectly the first time! - toma | [reply] |
|
|