home " subscribe " advertise " customer service " back issues " " contacts

Sections
  Newbies
  Reviews
  How To
    Best Defense
    Guru Guidance
    On The Desktop
  Developer's Den
    Gearheads Only
    Compile Time
    Perl of Wisdom
  Who's Who
 
Indexes
  Issue Archive
  Author Index
 
Linux Magazine
  Subscribe
  Advertise
  Customer Service
  Back Issues
  
  Contacts
 
On Stands Now Click to view Table of Contents for Linux Magazine March 2000 Issue
 
Subscribe to Linux Magazine

Linux Magazine / October 1999 / FEATURES
Uncultured Perl
 
<< prev   page 01 02 03 04   next >>

PERL 3

The Child

Perl Larry Wall
Striking A Subversive Pose: Larry Wall.

I remember that when I was a child, I thought there was nothing I couldn't do if I tried hard enough.

Perl 3 was when Perl started trying harder. The early design goal of optimizing for the common case was okay as far as it went, but it didn't say anything about what to do for the uncommon case. One common solution is to say you're not going to do anything about it, and in fact, that's what I once said about binary data, based on the precedent of many Unix text processing tools that could not handle binary data. When Perl 2 was out, I said to myself, "Perl is just a text processing language. If I make Perl handle binary data, who knows where it will stop?"

Well, Perl now handles binary data, and who knows where it will stop? That's the rub -- people don't want Perl to quit just because the going gets tough. So the earlier design goal evolved into our current goal: "Easy things should be easy, and hard things should be possible." Sure, Perl is mostly a text processing language, but every time we add the ability to do something else, we make a way to solve gobs of problems that are 90 percent text processing and 10 percent something else.

Another way Perl 3 tried harder was by adopting the GNU General Public License, known as the GPL. (The copyright statement on the first two versions was woefully inadequate.) More on the GPL later...

I've been talking about the advances that marked major versions, but you should realize that most of the development of Perl was not at the version boundaries. Development was continuous between major versions, and the typical patch file would contain bug fixes mixed together with enhancements.

It's a sign of the robustness of the design of Perl that people didn't rebel at using a development version for all their work. In large part, this was because Perl has always had an extensive set of regression tests, and users could be confident that, even if they installed a new development version, at least the functionality tested by the regression tests was guaranteed not to break. And that was good enough for many, because most Perl scripts don't use the fancy stuff. I take it as a compliment that many people still use Perl 4, because that means I put a lot of the right stuff into Perl early.

PERL 4

The Preteen

It's an odd thing, but nothing much changed between Perl 3 and Perl 4. Or, I should say, between the end of Perl 3 and the beginning of Perl 4. Just as it's hard to say when a child becomes a preteen, the transition from Perl 3 to Perl 4 was rather arbitrary. What really happened was that we wrote the first edition of the Camel Book, and then changed the version number on Perl so that we could say that it documented version 4.

But there is actually a qualitative difference between how a child thinks and how a preteen thinks. There comes a time at about the age of ten when suddenly a child doesn't just think about things, but starts thinking about thinking about things. So I guess you could say that producing the Camel Book was our version of thinking about thinking about Perl. Certainly it helped a lot of people understand more about how I think about Perl. Or at least, about camels.

People keep asking me, "Why a camel?" And I have a standard litany of answers. (I'm allowed to give more than one answer, of course, because of the Perl Slogan: "There's More Than One Way To Do It!") But the fact is, there's no single left-brained answer. If I'd wanted a left-brained animal on my book, it would have been an oyster. But I wanted a right-brained animal, and the camel was it for various reasons:

A camel is ugly but useful; it may stink, and it may spit, but it'll get you where you're going.

A camel is self sufficient in a dry place. You don't need to take along food and water for your camel. You don't need a toolkit to keep your camel going. You don't need tracks or roadways, or pipes to other processes.

A camel is a horse designed by a committee. Or at least it looks like one. But appearances can be deceiving, and a camel is well adapted to its ecological niche. So is Perl. Despite the fact that it is designed by a committee.

Camels have vague Biblical associations with caravans and treasure, such as Pearls of Great Price, not to mention Pearls of Wisdom, and not to mention Pearls before Swine. Or the Pearly Gates.

Finally, no animal has a better attitude than a camel. Presuming you're looking for an animal with an attitude.

Frankly, I wanted a camel because it was countercultural. Camels aren't modern, therefore they have to be either premodern or post-modern. Maybe even both. Fortunately our postmodern culture is based on the happy contradiction that any decent culture must be countercultural. If you can't deconstruct your own program, you aren't really with the program.

Another way to look at the Camel Book is that it was a kind of bar mitzvah for Perl. Perl wasn't a real grown up language before it had a book. I remember being shocked the first time I was told that half the desks on Wall Street had a Perl book on them. I shouldn't have been. The book is what legitimized Perl in the eyes of many.

Another thing that helped legitimize Perl was the addition of the Artistic License to stand beside the GPL. Perl 3 used only the GPL, but I found that this didn't do quite what I wanted. I wanted Perl to be used, and the GPL was preventing people from using Perl. Not that I dislike the GPL myself -- it provides a set of assurances that many hackers find comforting. But business people needed a different set of assurances, and so I wrote the Artistic License to reassure them.

The really brilliant part was that I didn't require people to state which license they were distributing under, so nobody had to publicly commit to one or the other. In sociological terms, nobody had to lose face, or cause anyone else to lose face. Most everyone chose to read whichever license they preferred, and to ignore the other. That's how Perl used psychology to subvert the license wars which, as you may or may not be aware, are still going on. Ho hum.

Yet another thing that helped legitimize Perl was that there was a long period of stability for Perl 4, patch level 36. The primary cause of this was that I abandoned Perl 4 to work on Perl 5.


<< prev   page 01 02 03 04   next >>
 
Linux Magazine / October 1999 / FEATURES
Uncultured Perl

home " subscribe " advertise " customer service " back issues " " contacts