[ PerlRing ] [ PerlRing Next ]

Perl Resources and Reviews

Diving for Perl

What is Perl?

New to Perl? You're at the right place! From here you can get anywhere that matters in the Perl world. Even old Perl hands may appreciate the one stop shopping.

Camel & Llama images are trademarks of O'Reilly & Associates, Inc. Used with permission.

Table of Contents

Why Use Perl?

Call me Johny perl-seed. Wherever I go, and as a consultant I work at a lot of companies, when I see a job for Perl I try and plant the seeds of Perl so they'll root and grow even when I move on. Why do I do this you may ask?

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!

While not a sufficient reason to use a language it helps a lot if a language is fun to use.

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

Scripting languages make for fast development cycles. What they usually suck at is the ability to invoke OS specific system and library calls. The line between C and scripting languages was clear, C gave you complete access to the OS so you had to use C for a lot of work. Perl changed that by giving you almost total access to the OS. On Unix at least, any program you can write in C can be written in Perl as well.

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

Perl is in some ways anti-Unix. Unix's philosophy is the interaction of Unix tools is greater than the sum of its parts. Power comes from combining together a small group of small focussed tools. Novel situations are easily handled by the clever use of existing tools or by writing your own clever filters.

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 made its bones as a scripting language for sys admins. But burried in Perl are features main stream languages like C++ are just now getting. Perl has garbage collection, builtin security checks, inheritance, name spaces, closures, awesome regular expressions, unlimited length data structures, and much more. Perl allows you to have your cake and at least take a bite of it too.

Perl is Portable

Yes, Perl is portable. Perl programs built on one platform should work on other platforms without change. This is mostly true. Core features like regular expression handling and data structures will work without change from platform to platform, but more OS related features often break. Signals tend to be platform dependent. Perl's great Unix integration doesn't mean much on a Mac, VMS, or Windows. And often system calls aren't available because of broken include files.

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

Perl is Usually Fast Enough

Fast enough is defined by your requirements. Don't count out Perl save on the most demanding applications. Perl is usually fast enough.

Perl is Usually Robust Enough

Perl has garbage collection and takes pains to prevent memory corruption. Perl is tested by thousands of people every day. Perl is usually robust enough.

Perl has Tons of Free and Useful Code

Perl gives a good bang for your free buck. Tons of Perl code sits in archives waiting for you to reuse it.

Perl is Embeddable and Extensible

For those who need an embeddable scripting language Perl qualifies.

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

You are never alone when using Perl. New releases of Perl are made regularily. Perl's news groups are active and helpful.

Perl Makes the Web Come Alive

Perl and the web were made for each other. Most web functions center around formatting and parsing text and accessing files and databases. Because Perl does all of these with ease Perl has become the language of web.

Knowing Perl Can Get You a Job

Never thought I'd see the day but I see a lot of contracts now requiring Perl knowledge. Get a job doing something you enjoy. Not a bad deal.

The Big 3 Perl Sites

Once upon a time Perl information was spread throughout the land. Now explorers have tamed the Camel pulling all but its tail under the tent:
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

The Perl Journal is a new quarterly magazine devoted just to Perl. After receiving a couple copies I can say I like it. So far it has been well written and infomative. My only complaint is that it should come out more often!

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.
If you have any more top tips let me know and I'll add them.

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.
Any others? Let me know and I'll add them.

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

	Bad Moon
	Balduvian Barbarians
	Balduvian Bears

    And when I get some hits, I change them into filenames.  For 
	Bad Moon

    This is demo'd in 

3) Real DBM stuff.  If you're keeping something in DBM format, but
    have to grep the keys, you'll be slow.  Consider
    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

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
    is such.  You can look at the whole system here:

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:


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

Perl has two major news groups under the comp.lang news hierarchy. To be sure you'll find passionate Perl discussions in various computer language related groups and some practical talk in web related groups. Perl shows up in the darndest places.
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.

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++!

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

tmh@possibility.com / http://www.possibility.com/Tmh

[ PerlRing ] [ PerlRing Next ]

This site is part of the perl ring system.
[ Next Page | Skip Next | List Next 5 | Random Link ]
Want to join the ring? Click here for info

Look ma, i won an award...
PC Webopaedia Outstanding Page Award >