Perl Resources and Reviews

Diving for Perl

Table of Contents

• What's New in Perl?
• Why Use Perl?
  A Conversion Attempt
• The Big 3 Perl Sites
  Perl Hot Spots
• Top 10 Perl Tips
  Advice for Making All Your Perl Experiences Bright
• Perl Stars
  People Who've Helped Make Perl Perl
• Perl Books and Reviews
• Perl Related News Groups
  Where the elite meet to Perl
• Randal's UnixReview Perl Articles
  A long series of articles created by guru Randal Schwartz
• The Perl Journal
  Perl has a magazine!
• Perl Reference Guide
• Perl Man Pages
• Expert Perl Topics
• Advanced Perl Datastructures
  Lists of lists, hashes of hashes, Perl does datastructures
• Perl Gets a Compiler
• Perl for Windows
• Ordering the Camel Book
• Perl Compared
  Perl Takes on the Pack
• Perl Modules
  Lookup Pre Built Pre Tested Perl Modules
• A Good HTML Perl Manual
  It's easy to use and pretty fast too.
• Places Miscellaneous
• Tom's Take on Perl Databases
• Cool Perl Code
  Perl modules that do almost everything, already done!

Why Use Perl?

I must make money on every copy sold? Perl isn't sold so no money do I make. Perl is freely downloadable and usable by anyone on the planet.

I must yearn for net fame by making Perl popular. Yah right! Trust me, in the world of Perl I'm a nobody, just a satisfied user.

Then I must be a language bigot! Mechanically repeating Perl is the answer, Perl is the answer... Nope. I tend to look at the question first and then create an answer. Perl is just a useful tool. I actually do most of my programming in C++ so I must be flexible :-)

I'm a hack and like obscure write-once close to the OS wierd syntax languages. Whoops, hitting a little to close to home on this one...

So just why do I like perl so much?

Perl is Fun!

Perl was built by programmers for programmers, not to win language design purity contests. When using Perl you feel at home. You say what you mean and mean what you say. Perl is quick to the point with an economy of expression. You can do everything you could do in C but with much less coding effort. Make a change and run the program. Perl has a powerful engine, responsive handling, and yet sports a roll bar. It's not for amateurs. Perl is how programming should be.

Is the above a bit over the top? You bet. But I was going for spirit not acccuracy. Your mileage may vary of course which is why we have freedom of choice.

Perl Has Complete OS Access

This was a very freeing development. Most of us can do C in our sleep, but the flexibility of an interpreted language with all the power of C and more won a lot of Perl converts.

Perl Combines the Best of csh, sh, awk, sed, grep

And Unix does have a big toolbox. It's amazing what you can do combining together different combinations of sh, ls, grep, sed, cut, paste, awk, and find. Or rather it's amazing what you can do if you:

• remember what all the commands in your toolbox do
• remember the arcane grammar needed to coax guru status behaviour from the tools
• remember how to combine everything in whatever shell you are using
• remember the little differences across different Unix systems

Basically the tools became unfocussed, the number of tools became large, and simple they were not. If you could remember how to do a complex sed substitution from one month to the next I'd give you a 5 star rating. My little brain couldn't handle it. We used to have contests to see who could remember all of ls's command line options. Nobody could. Or someone could always site a platform where ls was slightly different.

Part of the problem is that csh, sh, and awk were simply never good enough general programming languages. As a consequence Unix suffered from the shell of the month syndrome. People kept on inventing new improved shells. Many a large project was implemented in obscure shell languages that nobody but the author understood.

Perl made inroads because it is a general programming language combing the power of the shell languages we all loved with OS access and good performance. You could learn one somewhat obscure language and write scripts as easily as ever. And these scripts were truly portable!

Perl has Advanced Language Features

Perl is Portable

On the whole though Perl does deliver on its promiss of portability.

Perl is Usually Fast Enough

Perl is Usually Robust Enough

Perl has Tons of Free and Useful Code

Perl is Embeddable and Extensible

Perl has Tons of Users, Active News Groups, and Constant Upgrades

Perl Makes the Web Come Alive

Knowing Perl Can Get You a Job

The Big 3 Perl Sites

Perl's Home

THE source for everything you need for Perl, which makes this page much smaller!

CPAN - A Comprehensive Perl Archive Network

CPAN aims to be The Perl archive, the only Perl archive you will ever need. Go here if you want to find Perl code.

Perl for Windows

Perl is still most at home under Unix but it's starting to feel comfortable with Windows.

The Perl Journal

Top 10 Perl Tips

Use Perl!

When in doubt use Perl. Whenever a project comes up you'll wonder if you should use C, C++, sh, csh, ksh, TCL, awk, Python, Sather or one of a dozen other languages. For a more detailed language discussion go here .

Definitely use Perl before using other scripting languages like sh, csh, ksh, and awk. Perl is more powerful, more portable, and has a much larger audience of proficient programmers and available code.

Choosing between other high end scripting languages like TCL, Python, and Sather is a harder decision to make. Python is a better pure OO language than Perl, but some may not consider Python as good a scripting language as Perl. TCL has a lot of good utilities like Expect, great integration with GUIs, TCL is simple, and is also ported to a lot of environments. TCL is also slow and has some problems as a language. Sather as an Eiffle varient has a lot to offer too.

With the addition of complex data structures, OO capabilities, and almost complete Unix OS integration Perl5 has become a viable alternative to using C++. Perl's interpreted environment makes using Perl a pleasure in comparison with the compile and link cycle torture of large C++ programs.

There are clear cases where Perl is not an appropriate choice:

High Performance Situations

Perl is not as fast as C or C++ for many categories of applications. I would not use Perl to code a telecom switch. I would not use Perl to implement a high transaction capable database server. But I would use Perl to implement almost anything else. Perl is faster than you think. Before blowing off Perl for performance reasons you might want to run some benchmarks first.

And of course if you are dealing with a lot of text manipulation or regular expression matching then Perl will likely be faster than most C programs you could write.

Long Lived High Activity Servers

I've found servers dealing simultaneously with subsecond timers, SIGCHLD, other signals, and a high transaction rate eventaully die for memory corruption reasons. Others may not have had this experience, but I cannot recommend Perl for these type of applications.

Integration with Existing Frameworks

If most of your project is in C or C++ then Perl may not be appropriate. It's still not easy to integrate Perl and C so writing wrappers may not be worth the effort. One good approach in these situations is to create a gateway program that uses a message based interface so you can send requests/replies between a C or C++ based server from Perl clients.

Reuse It!

Check the modules list and other code repositories before embarking on a new major project. You might find it already done. Hey, you can still roll your own, but at least by seeing what others have done you can do an even a better job.

Read News Group: comp.lang.perl.misc

Watchout. Reading comp.lang.perl.misc may make you more knowledgeable about Perl, a better Perl programmer, keep you in touch with what's happening with Perl, and introduce you to some really nice people.

Read News Group: comp.lang.perl.announce

All the new interesting Perl libraries come through comp.lang.perl.announce. If you find just one useful you may save days of coding.

There's More than One Way to Do It

An old Perl credo, and like most old credos it has a basis in fact. So why is it in my top ten hints list? It's hard to explain, but stay flexible. Look for new ways of doing things by looking at others peoples code. Don't try an carry the idioms you used in C over to Perl. Learn the Perl way.

Treat a Perl Script as a Program

Scripts tend to be quick and dirty hack jobs. Perl delights in the quick and dirty, but Perl also allows you to do so much better. Treat your Perl programs as programs and not toss away scripts. Allow change through command line arguments. Have help that can be printed out from the command line. Disign your code to use modules. Include logging and exceptions. In short, don't get lazy because Perl is just a scripting language.

Trap Errors Using Eval/Die

Perl allows you to throw errors with the die command and catch errors by using eval to execute code. Using die/eval is an excellent way to structure your error handling. For some reason many people avoid using die/catch (including me he said sheepishly) until late in their Perl development. Use it early and often.

Format Normally

Use all the rules and intuitions you've built up to format your Perl programs. Often because Perl is considered a scripting language people may be lax in formatting Perl programs. Don't fall into this trap. Because of Perl's terseness good formatting styles and comments are even more important.

Make Modules

When programming consider you are building reusable components and not just one giant Perl program. Factor out code into objects, create good documentation, and follow the advice for making modules.

Use -w

Perl's -w command line options turns on warnings, warnings that often alert you to problems in your code. For example:

   #!/bin/perl -w
   

Like most lint type facilities it will flag things that aren't really problems, but it's still worth using.

Use strict

Perl's use strict directive checks to make sure variables are declared before use. It's a handy check to make sure you are doing what you think you are doing.

Perl Stars

Larry Wall

The founder and guiding star of Perl. I met Larry once at a Perl talk he gave to a system administrators group. He is as nice in person as he is talented.

Tom Christiansen

Another leading Perl light. A master programmer Tom is very active in Perl news groups and Perl development. Between creating code masterpieces, giving guidence, and answering reams of questions Tom also manages to play the Pope defending Perl against the infidels

Randal Schwartz

As a Perl guru Randal has authored several Perl books, writes Perl articles, answers the tough Perl questions, is an awesome programmer, and in general has become one of the pillars of Perl.

Tim Bunce

Tim has done a lot great work on getting the generalized Perl database interface up and running. I'm sure Tim does a lot more great Perl stuff, but I use the database modules a lot and really appreciate the work he has put in.

Tom's Take on Perl Databases

:Nick Bauman  writes:
:How about another Perl-related speed question?
:
:If I have a large DBM file that I want to parse through quickly to match 
:a pattern in, will the actual pattern matching part of the program run 
:faster using the DBM/NDBM construct versus the same data search through 
:in a flat file, say tab delimited fields, line delimited records?
:
:In short, will searching though a DBM file be faster than searching 
:through a flat (text) file? Assume Perl 5.

If you have to pull out all the keys and pattern match against them, then
it won't be faster, and in fact will probably be slower.  You can't do
range or pattern queries with any of the dbm libraries.

One thing I do in several database applications of mine is store the keys
in a flat file that I get grep (or agrep) through, and then once I get
some hits, then I pull out the real records, which might be stored in
any of format.  

Everything I do seems to be a database application, and never once do I
use a commercial database.  Go figure.  Here are a few of my experiences.

1) A big flat text data file -- the line I'm grepping in the index
    contains a seek address.  for example

	backbone cabal 104198
	backbone site 104450
	backgammon 104903
	background 104982
	backspace and overstrike 106058
	backward combatability 106211

    Here our index has as its last element the master file's
    byte address to seek to in order to pull out the record.  This index
    file, though, can be accessed via look, grep, or agrep style
    searching.  (This is an old program of mine that works just fine.
    It's not on the web.)

2) A separate file per key, such as HTML files.  One application 
   takes line like this

	Backdraft
	Backfire
	Bad Moon
	Badlands
	Balance
	Balduvian Barbarians
	Balduvian Bears

    And when I get some hits, I change them into filenames.  For 
    example:
	Bad Moon
    becomes
	/deckmaster/cards/bad_moon.html

    This is demo'd in 
	http://perl.com/deckmaster/index.html

3) Real DBM stuff.  If you're keeping something in DBM format, but
    have to grep the keys, you'll be slow.  Consider
	ftp://perl.com/pub/perl/scripts/ggh
    which allows you to access the netscape global history file.
    For simple lookups, it's super fast, but for greplike lookups,
    it has to pull out *all* the keys.  Now, in this case, I can't
    really keep a flat text file around of the keys, since it 
    changes dynamically.  

4) On other db applications, it's fine to keep a flat textfile around.  
    For example, in the man system, even though I store the data
    in dbm files, when you want to do an apropos, it goes to the 
    flat text file.  This is much faster.  But if what you want
    to do is grep on different fields in your database flatly,
    you'll need a separate flat index for each quick-searchable
    field.  

5) When all you're doing is figuring out text and/or html files, then 
    you may want to look into glimpse for regular work or glimpseHTTP or
    Excite.  The lqtext system is also interesting.  These are 
    all *VERY* rapid, much better than a grep can be.  I use 
    glimpse for the perl bugs database at http://perl.com/perl/bugs/index.html,
    and I use Excite for the general site index at
    http://perl.com/Architext/AT-allperl.html .

6) Sometimes flat text files have enough of a structure that you
    need a dedicated application to look around at them.  The stuff
    at 
	http://perl.com/deckmaster/forms/angelgrep.html
    is such.  You can look at the whole system here:
	ftp://perl.com/perl/ext/CGI/eg/angelgrep/

6) I have a database with complex fields.  Here's a sample record:

	[ # Ali Baba
		"A/4",  "U3/U",         "Red",  "Summon Ali Baba", 
		"Ali Baba", 
		"R",    "1/1", 
		"R: Tap target wall.", 
		"Julie Baroh", 
		"``When he reached the entrance of the cavern, he pronounced the words, `Open, Sesame!' '' 
                        --The Arabian Nights, Junior Classics trans.", 
	],

    This gets changed in memory into this:

    %Card = (
	'Ali Baba' => {
	    artist       => 'Julie Baroh',
	    color        => 'Red',
	    cost         => '01 R',
	    first_rarity => 'U3',
	    name         => 'Ali Baba',
	    powtuf       => '1/1',
	    power        => 1,
	    toughness    => 1,
	    printrun     => 'A/4 U3/U',
	    text         => 'R: Tap target wall.',
	    type         => 'Summon Ali Baba',
	    # .... many other fields
	},
	# many other cards
    );

    And then when people need to do queries, they supply actual
    perl code, like

	power() == 1 && toughness() == 1

    Which is really

	$Card{$_}{power} == 1 && $Card{$_}{toughness} == 1

    Which when run in a grep query, like

	@hits = grep { USER QUERY HERE } keys %Cards;

    Gives you everything you want.  This is great for small
    databases, but pretty slow for large ones, since it
    requires an incore database.  But since most queries seems
    to look at everything anyway.

    Reading in structured data like this can be a tad slow,
    although recent perl memory allocation experiments have
    shown that some work can be done here.  The work by 
    Rafael Manredi in his Storable extension is quite interesting
    also.  Find it at:

	${CPAN}/modules/by-module/Storable/

7) Note that storing of complex records in a flat dbm file is
    more than a bit tricky.  Remember that you cannot store 
    multilevel datastructures directly in them, because you
    cannot store pointers.   See ${CPAN}/modules/by-module/MLDBM/

8) At some point, you may want a "real" relational database. 
    MiniSQL is pretty nice, or you might check out a commercial
    one if you really want to.  Perl has interfaces to many 
    of these.

Perl Related News Groups

comp.lang.perl.misc

Go here for serious Perl discussions. It's a hoppin' place and you'll learn a lot. There are a lot of helpful people in this group who will answer your questions as long as you follow the one rule: READ THE FAQ ! Read it twice. If you don't I am not responsible for the consequences.

comp.lang.perl.announce

One of the best reasons to use Perl is all the available libraries contributed for free by Perl programmers. New libraries are called modules and are announced here for all to see. Take that C++!

comp.infosystems.www.authoring.cgi

Perl and the web were made for each other. This groups gets a lot of Perl related traffic.