A L wrote:

> Joseph
> ###My background...  Well, I had my first encounter with
> Perl in the Fall of 2000.  It was not pretty.  At the
> time, my only programming experience was Pascal taken as a
> high school student.  However, I really wanted to learn
> programming better, and was told that Perl is the language
> to learn to get things done.  But, I hated Perl the first
> time because I had a huge issue with debugging when it
> won't let me do things because I missed a period or
> something important, which I was unaware of.

This is something that you will have to adapt to.
Programming is a pretty exact art.  Every character must be
there for a reason,  So is good writing for that matter.
Unfortunately, the speed with which we can send messages ahs
had its impact on the quality of proofreading.  It can be a
very healthy discipline to have to meet the demands of the
compiler.

[clip and save--I've said it before, I'll say it again]
I see the compiler as a sort of guru--a stern but fair
taskmaster that has no ego, no will or motivation of its
ownm and thus is able to reflect only what is offered to it.

[/clip]

Make the compiler your friend.  When it prints an error
message, it is because it is unable to understand the code
as written.  The Perl interpreter is particularly
forgiving.  If at all possible to make sense of the code, it
will.  Then its a bit of a detective game to locate the
errors cited.  Sometimes the errors will not be obvious,
since the compiler will read the code until it finds
something that just can't be translated.  The process of
finding those errors is also good for you.

>  Then, I learned a little bit of Java.  I liked Java with
> all its structures and class less than I did Perl.

That's too bad.  Not that you prefer Perl, but to be put off
by classes and structures.  Structures and classes, and the
thinking required to develop them, are the most powerful
tools available to support creative programming.

> Now, I'm trying to master Perl to an extent where I feel
> comfortable enough to create things I want to create
> without feeling at a total loss or frustration to call a
> computer stupid for not doing what I had written.

A computer can only do what it is told.  When we see results
we don't like, we have to look at what we are telling the
compiler.

> Also, I'm using Linux.  So, to answer your question about
> studying the basic concepts of command-line programming
> with Perl, I think that I do know a little bit to test my
> codes, but I do have my Perl reference manuals beside me
> to look up things whenever necessary, as I am always
> learning something new and cool.
>
> Angela

It might be worth re-examining your approach to
problem-solving.  Any problem can be either a burden or a
challenge.  a lot of the difference comes in how you
approach it.  If you just get angry at the compiler for
sending you error messages, then you miss out on the help it
is offering you.  For me, it is actually a great
convenience.  When I am on a roll with the logic, I take
only moderate care about the code.  I don't intentionally
neglect sysntax, but I focus on logic.  Then each time I
finish a new function body, I:
perl -c my_program_name.pl
before I try to run.  I just accept that I may have to run
this command and toggle back to the script to catch my
errors.  It's just part of the process, and I've learned to
enjoy it.

By using highly structured code, I can usually keep the
complications to a minimum for the process I am working on
at any given time.  My current project just went beyond 1500
lines.  I can't imagine trying to keep track of all that if
it was unstructured.  As it is, it's no problem.  There is
not a single function in that file that can't be viewed in
whole in a single screen.  This makes it very easy to
isolate problems.

I would recommend at a minimum that you test the DBI and CGI
modules each in isolation before trying to do an integrated
web-based data access system.  Each tool Perl offers has its
own purpose characteristics, and quirks.  It is easiest to
get familiar with them one at a time.  The deeper your
familiarity with each, the more readily you will be able to
make them integrate smoothly.

Joseph


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to