I know what you mean but am not sure it's about pride. Trial
and error, and guessing are key strategies people use to
learn, expand and deploy their language skills. I'm always
learning new things about perl when ignorance and
incomprehensible documentation demand experimentation.
It's also natural for acquired skills to settle into habitual
patterns of unconscious behavior so they can be used
spontaneously without having to think about them.
I agree with your conclusion that this tendency needs to be
overcome when using language to speak with machines. They
demand a much more exact grammer and syntax since the
other constructs we habitually use to convey meaning such
as inflection and body language don't apply (yet).
So I think that saying 'never guess at code' is a little too
strict :-). Instead, guess away and learn new ways to do
things, but always double check your guesses, and question
your own coding habits.
--
Check out my Perlmonks Related Scripts like framechat,
reputer, and xNN.
| [reply] |
I guess it all depends on your programming mentality. I've been at it for a while now (although not all Perl), and I have never been able to stand writing more than a few lines of code without checking that it works.
This is probably a personality thing - I just get really depressed if I can't see the results of my code running every half hour or so. I have this dread of writing some elaborate routine that takes ages to implement, and then discovering that I can't do it like that and having to scrap all that work. I have to say since I came to Perl that's happened a lot less :)
I also can't imagine coding without half a dozen help windows open showing the docs for the modules I'm using in my program. I do know people who like to do the whole program in one shot, then go back through and pick up the problems later. Personally, I can't stand debugging, so I do whatever I can to make sure I never have to do a huge debug session. I dread trawling through thousands of lines of code to find the bug.
Also, similar to the tip mentioned above, I usually have a window open to a program called test.pl, wherein I test anything that I'm not totally sure of. A lot of my program gets written in there, and then copied in to the body of the main bit when I'm totally sure it workd. ____________________
Jeremy
I didn't believe in evil until I dated it. | [reply]
[d/l] |
| [reply] |
From "The Pragmatic Programmer", tip #44:
Don't program by coincidence
The gist of this is " ... if something seems to work, but you don't know why, make sure it isn't just a coincidence". | [reply] |
I often keep a perl -de0 window open to verify constructs that are less familiar. That and a copy of Camel III go a long way to keeping me on the straight and narrow. | [reply]
[d/l] |
I think in a way most of us are more or less guessing at the code we're writing, until we actually test it. But as a beginner who's only recently started to "speak" Perl, I usually trying to find a way to do what I want, and then look it up in a book to find out the exact syntax, usage, etc. That of course means that whenever I'm coding I have at least two books, and often enough the Perl CD Bookshelf, lying around - or falling to the floor, for that matter.
After some time, the things I have to do again all the time, and of course the basic stuff, just flow freely, but as soon as I want to do something new, I go and look it up - trying to keep it in mind for the next time, of course. And often the most useful resource, is PerlMonks. Although the books tell me how to do things, here I find more specific examples and sometimes even the exact solution I need to my problem, because someone has had it before, posted it in the Seekers of Perl Wisdom and got a helpful answer.
Something else that I find helpful, and in fact do all the time, is going back to my "old" code and see whether I've had the problem somewhere before, and if possible, just copy the code and adapt it.
But then, looking things up doesn't mean the code then actually works. Sometimes I have a problem which I think I know in what direction the solution has to go, and look that up. But then I realise that in fact, while this particular solution would work for another problem, I didn't assess the problem correctly and hence chose the wrong solution. Erm... Am I making sense here?
Anyway, I think looking things up doesn't hurt my pride. Point one, I am a beginner, after all, and point two, even if I weren't, there's always something that I haven't done before and hence haven't got a clue about. Just like you cannot speak a language perfectly, because a) you always make mistakes even in your first language, or neologise, or b) you may speak a dialect, or c), and this is the point, you don't know any kind of jargon which is not from your own field of work. Similarly, if I'd be working on a linux machine, I wouldn't have a clue, and wouldn't concern myself with, any Win32-stuff. (I wish...) Even if you know Perl, you don't know all of it.
--cs | [reply] |
I think all of you are wrong. I never read the manual (laziness), I always slap-dash things together as quickly as possible (impatience), and I think the damn compiler should just DWIM (hubris).
I hope a smiley wasn't required.
Seriously, though, one of the greatest things about Perl is that the learning curve is not steep. It doesn't take long before code that you think is correct actually is correct. That's probably why you soon lose the habit of looking up references. A pity, since the documentation is so easy to access from just about anywhere. | [reply] |
The way I think about this is "never fly any higher than
you are willing to fall." As you write the code, you
should be asking yourself, "how will I know that this
line of code is working?" Maybe you should put in a print
statement, or maybe you'll check values in a debugger.
Another trick is to use assertions, such as:
($loop_count > 0) or die "Loop counter: `$loop_count' value non-positi
+ve";<P>
Watching other people code, especially someone who is
very good, is educational, and can be fun. I picked
up a few good habits by watching a "Perl Death
Match," which involves watching people code as they
compete.
It should work perfectly the first time! - toma | [reply]
[d/l] |