A Perl Beginner

T

The light

I wish to use Perl with a page i designed with Front page.What will be
best
way to start?
 
J

Jürgen Exner

The light wrote:

Hi The
I wish to use Perl with a page i designed with Front page.What will be
best
way to start?
Click to expand...

Perl is a universal programming language. It does not have pages. Frontpage
is a web page editor and web site publishing system. Those two have about
nothing in common.
Your question is like "I wish to use English for a newspaper that I designed
with a pencil. What would be the best way to start".

Maybe you should take a few steps back and reevaluate what it really is that
you trying to do.

As far as Perl itself is concerned: Because you mentioned Frontpage you are
probably using a Windows-based system. Therefore I suggest to go to
activestate.com und just install their ActivePerl system (it's free,
although you have to dig a bit for the free version). And then run the
build-in help "perldoc -q books" to check for suggestions on helpful books.

Of course, this will get you started with Perl. It has nothing to do with
pages or Frontpage or ...

jue
 
K

krakle

I wish to use Perl with a page i designed with Front page.What will be
best
way to start?
Click to expand...

It sounds to me like you want to use Perl as a CGI script. Front Page
produces a generated HTML document. You can't use Perl in an HTML
document (with exception of Mason and other embedded Perl
technologies). You can use HTML inside of a Perl script to output HTML
code. To do this you will need to familiarize yourself with CGI and
also read up on the CGI.pm module.

ie:

#!/usr/bin/perl -w

use strict;
use warnings;

use CGI;

my cgi = new CGI;

print $cgi->header("text/html");

print <<End_Html;
<html>
<head>
<title>HTML Document</title>
</head>

<body bgcolor="#ffffff" text="#000000">
<h1>HTML Document</h1>
<hr>
This is a basic CGI script.
</body>
</html>

End_Html

__END__


Basically, you're just outputting a header and HTML code for the
browser to read. And obviously you need to use a web server for your
script to actually run as a CGI.
 
X

Xiong Changnian

The light said:
What will be
best
way to start?
Click to expand...

I think it's a good question. I'd suggest you forget what you want
ultimately to do -- for the time being. Your mission may be just a tad
advanced for your first learning project.


First, download and install perl. It's available for your platform; I'll
bet you a dollar. See:

http://www.perl.org/get.html

You want perl itself; you can get more modules later. You'll get a lot
of them with the standard download anyway.


Second, be sure you have a decent text editor. You can use almost
anything, including Office Word, but a "real" text editor is the right
tool for the job. If you're not on a Mac, too bad; no BBEdit for you.
But you do have many choices:

http://www.google.com/search?q=text+editor

Crimson Editor is a free download for Windows:

http://www.crimsoneditor.com/


Third, write the following code in your new text editor and run it with
your new copy of perl:

use strict;
use warnings;

print ("hello, world");

See what happens. Now, make it say something else. Then, without looking
up how, change it so that it does a simple arithmetic problem, like 432
+ 9.05. Take a guess and try that. If it doesn't work, try something
else.

Try some more stuff, whatever comes into your head. If you have any kind
of programming background at all, write something that ought to work in
that language. Run it and try to fix it so it runs under Perl. Don't be
scared if it works first time!

Forget about HTML for now. Basically, nothing you write for a web
browser will do anything for you in Perl. Later, you will learn how to
get Perl to write HTML *for* you. Not yet.


Fourth, start reading about Perl. Others will tell you to start here or
here but I say it doesn't matter much where you begin, since you'll
eventually make the rounds of quite a few standard books and online
resources. You might begin, as one poster suggested, with:

http://learn.perl.org/

I didn't; I dove into the "man" pages, such as perlfaq, perlsyn, perlop,
perlsub, installed along with perl itself on your own machine. Soon,
you'll want a copy of the Camel Book:

Programming Perl, 3rd Edition, Wall, Christiansen, Orwant

It's an O'Reilly book so you should be able to find it anywhere, even at
Fry's. The Llama Book is also good to have and you might rather start
there:

Learning Perl, 3rd Edition, Schwartz, Phoenix

Do *not* try to read all at one sitting! Perl books are like fine
literature; you read a page, then you think about it awhile. If
something sparks a thought, write some code and run it. See what it
does.

There is no shame in copying code directly out of the book. But it gets
more fun when you tinker with it to see what you can change. Things get
interesting when you are fooling with an example from *this* book on
page 123 and you remember a line from *that* book; put them together and
see what happens.

Spend a lot of time reading docs and writing small programs. Then, spend
a lot more time reading docs and writing more small programs. Move up as
fast as you feel comfortable.

At some point, it will not hurt you to read one or another "best
practices" guide. They do not agree on all points so take them for what
they are: style guides, not word of law. But in general, clean code is
happy code.

Read this newsgroup. Read another newsgroup. Read this newsgroup some
more.

Spend some more time reading docs and browsing around online for
discussions of features that interest you. Go back and rewrite some of
the stuff you wrote a couple weeks ago. Make it better.


Fifth, find a Perl Buddy. The ideal Perl Buddy is also learning Perl but
is a little ahead of you. The neighborhood Perl Wizard is probably not
the best choice but if you can get him/her/it to speak, listen. There's
nothing wrong with a Perl Buddy who is just about where you are. Both of
you will learn from one another and nobody loses or feels he's wasting
time. A good Perl Buddy lives two houses down on the same side of your
street and works the same shift as you. Spend time with your Perl Buddy.

Continue to read every single thing about Perl you can lay hands on.
Write code until your fingers cramp, then take a break. Learn to look
with suspicion when someone tells you that you must Do It This Way. When
you hear this, go to the keyboard and Do It That Way. Then start over
and Do It Another Way.

All the programs you are writing are learning projects. It doesn't
matter what rules you break so long as you don't build bad habits.
Decide for yourself what a "bad habit" is. Air your opinions cautiously.
Be ready to change them radically and quickly.

Write more code.

Write more code.

Start insisting that your code really works.


Sixth, you are now ready to tackle the *job*, which need you first
mentioned. Narrow your field of study to the specific areas that touch
on the job. Read more stuff. Post questions here. Talk to people. Code
up your solution. Make it work. Make it better.

Done.

* * *

In Case of Failure:

You will repeatedly encounter, at short intervals and at many levels,
failure. Your code will not work as expected -- or, occasionally, *will*
work when you think it shouldn't. You may encounter what Pirsig called
the "gumption trap" -- air hissing from your brain. You may try
everything you can imagine and still fail to get the motorcycle running.

You will receive much sage advice from Real Programmers when your code
fails. Here is my two cents:

* Remember that failure is the most important part of learning in
general and especially of programming. There is no learning without
failure. All your learning efforts are nothing until, intentionally or
not, you fail. Only then can you put your brain in gear and try to
figure out WHY.

* Understand that programming is a purely intellectual, logical
exercise. The machine does not care what you think, only what you write.
Your muttered pleas, threats, and curses are unheard.

* Read Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig. It's
not about Zen and it's not really about motorcycles, either. It's partly
about the process of thinking and partly about a man who took a very
long trip inside his head. Nobody should attempt to solve any problem
without this kind of background. (IMO.)

* Look at your code awhile without thinking too much about it. Wait for
your error to stand up and talk to you. While this may seem silly at
first, it is the fastest way to find some bugs. It's a useful skill to
develop and the only way to do so is to try it.

* If your code is throwing an exception or reporting a warning, perl
will report a line number in the source. This *may* be near the actual
place you screwed up. Remember that when perl reports a slew of errors,
only the first one or two are likely significant. Concentrate on those.

* Bring out the debugging tools. Simple problems are often discovered by
salting your code with print statements. Perl has a debugger; learn to
use it. Learn how to set breakpoints and step through just the buggy
code, avoiding the stuff that works.

* Be honest. Did you do something you *knew* was a bit funny? Did you
use a word, symbol, idiom, or gadget without *certainly* understanding
it? Go back to the docs and read up. Be sure you understand exactly what
you think all your code really does. Watch out for "black box"
explanations rolling around in your head. Open them up and see what's
inside.

* Go back to your last working backup and run it again. (You *are*
making and filing away regular backups. Right?) Does it still work? If
not, what could possibly have changed? If so, what have you changed
since?

* Watch out for value traps. You may want to do something that you think
will be easy or a really good idea; later, you are blocked from solving
the big problem because you are mentally committed to this relatively
minor technique or feature that you "know" is Right. Consider trashing
the special neato thing and making the routine work without it. Later,
you might figure out a way to restore the neatoness; maybe you'll forgo
it.

* Tear out buggy code blocks and replace them with code that *must* run,
even if it doesn't do what you want. When your main program works again,
grab all the stuff you cut out and write the bare minimum of framework
needed to run the buggy blocks. Ruthlessly eliminate irrelevant features
from the test bed. As soon as it works, ask why.

* Construct a purely synthetic expression of the bug. Imagine that it is
all Perl's fault and you will show the world with your terse example
that reduces the bug to its essential elements. Can you write a new,
self-contained bundle of code that does the same nasty thing? If not,
why? If so, can you find the bug now? When you decided that the new,
test code would fail in the same way as your project, what assumptions
did you make? Which hold?

* See if there isn't a CPAN module that does it, what ever it is. Some
would say you should do this even before writing code but I say, you
learn by DIY. At some point, you may want to just get the job done,
though.

* When frustration begins to flood and gumption ebbs, take a break.
Pirsig recommends recutting rusty, stripped, or jimmied threads on nuts
and bolts while recharging one's personal gumption tank, exhausted from
trying to figure out why the engine won't start. I recommend documenting
your existing, working code. Write clear, complete documentation for
each subroutine. Fill in comments beside working code. Write POD. Return
to sections you've already commented and rewrite the docs. Check for the
common condition that you have edited the code but the docs no longer
track. Bring them up to speed.

* Loop all the above. These are not numbered steps; perhaps I should say
"wander through the above". Return frequently to the simple exercise of
looking over your code and checking for the obvious -- missing
semicolons, improperly paired braces, $ when you mean @, [] when you
mean ().

* Turn it off. Life awaits beyond the cathode ray tube. Purchase a ball
of an agreeable size and shape and throw it. If you can find a young
person to throw it back to you, so much the better. Take out the
garbage. Drink your favorite beverage. Eat; low blood sugar stalls the
brain. Sleep. Pay your bills. Roof the garage. If you have employment,
pursue it. Return refreshed.

* If you're still stalled after several iterations of the above, you
should at least have a very clear idea of what you don't like. Condense
this to its bare essentials -- a veritable Perl haiku of a bug. If the
disagreeable behavior persists, this is now the time to post to a
newsgroup. Wait for suggestions. Try them.

* Loop....
 
T

Tad McClellan

The Llama Book is also good to have and you might rather start
there:

Learning Perl, 3rd Edition, Schwartz, Phoenix
Click to expand...


The Llama book is in its 4th edition now.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Beginner Tips 1
Algoexpert for a beginner 0
BEGINNER: Question 0
Hello from beginner with some questions! 3
Is C, C++, and C# Useful For Beginner Game Development 1
Var and let simple beginner problem 1
Coding language for complete beginner? 0
Beginner coding 3

Members online

Total: 41 (members: 1, guests: 40)
Robots: 316

Forum statistics

Threads
473,767
Messages
2,569,571
Members
45,045
Latest member
DRCM

Latest Threads

Top