What is PERL?

Perl is an acronym for Practical Extraction and Report Language (although it has also been called a Pathologically Eclectic Garbage Lister).  And Perl's creator, Larry Wall, endorses both defintions!

One thing that I've noticed about Perl is that there's probably not a more spirited group of people involved with a programming language anywhere in the world. 

When learning a new language, it is often helpful to learn the history, motivations, and origins of that language.  In natural languages such as English, this helps us understand the culture and heritage of the language.  Such understanding leads to insight into the minds of those who speak the language.  This newly found insight, obtained through learning culture and heritage, assists us in learning the new language.

This philosophy of language instruction can often be applied to programming languages as well.  Although programming languages grow from a logical or mathematical basis, they are rarely purely mathematical.  Often, the people who design, implement and use the language influence the language, based on their own backgrounds.  Because of the influence the community has upon programming languages, it is useful, before learning a programming language, to understand its history, motivations, and culture. 

Here's part of Larry's introduction to the first in a series of some twenty volumes devoted to the Perl programming language published by O'Reilly & Associates, Learning Perl (pages xii-xiii):

 

I was rolling [a string of beads] around in my fingers one day and pondering the hopelessness (and haplessness) of my existence, when it occurred to me that it might be interesting to melt down some of those mystical beads and see what would happen to their Magic if I made a single, slightly larger bead out of them.  So, I fired up the old Bunsen burner, picked out some of my favorite beads, and let them melt together however they would.  And lo! the new Magic was more powerful than the sum of its parts and parcels.

That's odd, thought I.  Why should it be that the Sedulous Bead of Regular Expressions, when bonded together with the Shellacious Bead of Gnostic Interpolation, and the Awkward Bead of Simple Data Typology, should produce more Magic, pound for pound, than they do when strung out on strings?  I said to myself, could it be that the beads exchange power with each other because they no longer have to commune with each other through that skinny little string?  Could the pipeline be holding back the flow of information, much as wine doth resist flowing through the neck of Doctor von Neumann's famous bottle?

This demanded (of me) more scrutiny (of it).

So, I melted that larger bead together with a few more of my favorite beads, and the same thing happened, only more so.  It was practically a combinatorial explosion of potential incantations:  the Basic Bead of Output Formats and the Lispery Bead of Dynamic Scoping bonded themselves with the C-rationalized Bead of Operators Galore, and together they put forth a brilliant pulse of power that spread to thousands of machines throughout the entire civilized world.  That message cost the Net hundreds if not thousands of dollars to send everywhere.  Obviously I was either onto something or on something.

I then gathered my courage about me and showed my new magical bead to some of you, and you then began to give me your favorite beads to add in as well.  The Magic grew yet more powerful, as yet more synergy was imbued in the silly thing.  It was as if the Computational Elementals summoned by each bead were cooperating on your behalf to solve your problems for you.  Why the sudden peace on earth and good will toward mentality?  Perhaps it was because the beads were your favorite beads?  Perhaps it was because I'm just a good bead picker?

Perhaps I just got lucky.

You have to understand that Larry's background is in linguistics!  He continues (ibidem):

. . . this [book] isn't so much about Perl as it is about you!  This shouldn't be too surprising, because Perl is itself about you - at least in the abstract.  Perl was created for someone like you, by someone like you, with the collaboration of many other someones like you.  The Magic of Perl was sewn together, stitch by stitch and swatch by swatch, around the rather peculiar shape of your psyche.  If you think Perl is a bit odd, perhaps that's why.

And, finally, from the summary of his introduction (pages xiii-xiv):

What you'll need most is courage.  It is not an easy path that you've set your foot upon.  You're learning a new language:  a language full of strange runes and ancient chants, some easy and some difficult, many of which sound familiar, and some of which don't.  You may be tempted to become discouraged and quit.  But think you upon this:  consider how long it took you to learn your own native tongue.  Was it worth it?  I think so.  And have you finished learning it?  I think not.  Then do not expect to learn all of the mysteries of Perl in a moment, as though you were consuming a mere peanut, or an olive.  Rather, think of it as though you were consuming, say, a banana.  Consider how this works.  You do not wait to enjoy the banana until after you have eaten the whole thing.  No, of course not.  You enjoy each bite as you take it.  And each bite motivates you to take the next bite, and the next. . . .  May you Learn Perl.  May you do Good Magic with Perl.  And above all, may you have Lots of Fun with Perl.  So be it! 

So do it!
 

Perl as a Natural Language

Natural languages, languages (such as English) that people use on a daily basis to communicate with each other, are rich and complete.  Most natural languages allow the speaker to express themselves succinctly and clearly.  However, most natural languages are also full of arcane constructs that carry over from the language's past.  In addition, for a given natural language, it is impossible to fully master the vocabulary and grammar because they are very large, extremely complex, and always changing.

You may wonder what these facts about natural languages have to do with a programming language like Perl.  Surprising to most newcomers to Perl, the parallels between Perl and a natural language like English are striking.  Larry Wall, the father of Perl, has extensive scholastic training as a linguist.  Larry applied his linguistic knowledge to the creation of Perl, and thus, to the new student of Perl, a digression into these language parallels will give the student insight into the fundamentals of Perl.

Natural languages have the magnificent ability to provide a clear communication system for people of all skill levels and backgrounds.  The same natural language can allow a linguistic neophyte (like a three-year-old child) to communicate herself nearly completely to others, while having only a minimal vocabulary.  The same language also provides enough flexibility and clarity for the greatest of philosophers to write their works.

Perl is very much the same.  Small Perl programs are easy to write and can perform many tasks easily.  Even the newest student of Perl can write useful Perl programs.  However, Perl is a rich language with many features.  This allows the creation of simple programs that use a "limited" Perl vocabulary, and the creation of large, complicated programs that seem to work magic.

When studying Perl, it is helpful to keep the "richness" of Perl in mind.  Newcomers find Perl frustrating because subtle changes in syntax can produce deep changes in semantics.  It can even be helpful to think of Perl as another natural language rather than another programming language.  Like in a natural language, you should feel comfortable writing Perl programs that use only the parts of Perl you know.  However, you should be prepared to have a reference manual in hand when you are reading code written by someone else.

The fact that one cannot read someone else's code without a manual handy and the general "natural language" nature of Perl have been frequently criticized.  These arguments are well taken, and Perl's rich syntax and semantics can be confusing to the newcomer.  However, once the initial "information overload" subsides, most programmers find Perl exciting and challenging.  Discovering new ways to get things done in Perl can be both fun and challenging!  Hopefully, you will find this to be the case as well.

The History of Perl

Larry Wall first posted Perl to the comp.sources Usenet newsgroup in late 1987.  Larry had created Perl as a text processing language for Unix-like operating systems.  Before Perl, almost all text processing on Unix-like systems was done with a conglomeration of tools that included AWK, sed, the various shell programming languages, and C programs.  Larry wanted to fill the void between "manipulexity" (the ability of languages like C to "get into the innards of things") and "whipuptitude" (the property of programming languages like AWK or sh that allows programmers to quickly write useful programs).

Perl filled a niche that no other tool before that date had.  For this reason, users flocked to Perl.

Over the next four years or so, Perl began to evolve.  By 1992, Perl version 4 had become very stable and was a "standard" Unix programming language.  However, Perl was beginning to show its limitations.  Various aspects of the language were confusing at best, and problematic at worst.  Perl worked well for writing small programs, but writing large software applications in Perl was unwieldy.

The designers of the Perl language, now a group, but still under Larry's guidance, took a look around at the other languages that people were using.  They seemed to ask themselves:  "Why are people choosing other languages over Perl?"  The outcome of this self-inspection was Perl, version 5.

The first release of version 5 came in late 1994.  Many believed that version 5 made Perl "complete".  Gone were the impediments and much of the confusion that were prevalent in version 4.  With version 5, Perl was truly a viable, general purpose programming language and no longer just a convenient tool for system administrators.

The Slogans

Clearly, Perl is a unique language. This uniqueness has brought forth a community and an ideology that is unprecedented with other languages. One does not have to be a member of this community or agree with this ideology to use Perl, but it helps to at least understand the ideology to get the most out of Perl.

The common Perl slogans have become somewhat famous. These slogans make up the "Perl ethic" - the concepts that guide the way Perl itself is built, and the way most Perl programs are written.

"There's more than one way to do it". This slogan, often abbreviated TMTOWTDI (pronounced TIM-toady), is common among many programmers, but Perl takes this idea to its logical conclusion. Perl is rich with non-orthogonality and shortcuts. Most major syntactic constructs in Perl have two or three exact equivalents. This can be confusing to newcomers, but if you try to embrace this diversity rather than be frustrated by it, having "more than one way to do it" can be fun.

"The swiss-army chain-saw". This is the somewhat "less friendly" summary of the previous term. Sometimes, all these diverse, powerful features of Perl make it appear that there are too many tools that are too powerful to be useful all together on one "swiss-army knife". However, eventually, most Perl users find all these different "chain-saw"-style tools on one "swiss-army" knife are a help rather than a hindrance.

"Perl makes easy jobs easy, and the hard jobs possible." This is a newer phrase in the Perl community, but it is quite valid. Most easy tasks are very straight-forward in Perl. As the saying goes, most programmers find that there are very few jobs that Perl cannot handle well. However, despite what the saying might indicate, Perl is not a panacea; the programmer should always choose the right tool for the job, and that right tool may not always be Perl.

"Perl promotes laziness, impatience and hubris." These seem like strange qualities to be promoting, but upon further analysis, it becomes clear why they are important.

Lazy programmers do not like to write the same code more than once. Thus, a lazy programmer is much more likely to write code to be reusable and as applicable in as many situations as possible.

Laziness fits well with impatience. Impatient programmers do not like to do things that they know very well the computer could do for them. Thus, impatient programmers (who are also lazy) will write programs to do things that they do not want to have to do themselves. This makes these programs more usable for more tasks.

Finally, laziness and impatience are lacking without hubris. If programmers have hubris, they are much less likely to write unreadable code. A good bit of hubris is useful - it makes programmers want to write code that they can show off to friends. Thus, hubris, when practiced in the conjunction with laziness and impatience, causes programmers to write reusable, complete and readable code. In other words, it is possible to exploit these three "bad" traits to obtain a "good" outcome.

Let's do it!

Next week we'll begin our journey through Perl by starting a little stroll through the building of a fairly sophisticated Perl application.  See you then!!
































John Von Neuman's contribution to the organization of a very simple computer having processor P and memory system M

was that both programs and data were to be stored in the same memory system.  However, when this design is used for a fast computer it is often found that the fetching of instructions interferes with the fetching and storing of data because both of these operations must occur over the single data path which connects the processor and the memory system. The restriction of this data and instruction flow over the data path is sometimes called the Von Neuman Bottleneck.

Back to page from whence you came