Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-) Softpanorama Search

Introduction to Perl for Unix System Administrators

(Perl without excessive complexity)

by Dr Nikolai Bezroukov

Prev | Up | Contents | Down | Next

1.4. Perl Hype

To end this introduction on a skeptic note let's discuss Perl hype.

First of all, in no way Perl is closer to natural languages than, say, Korn shell or Java. Sometimes (believe me Larry Wall is more complex than this simplistic attitude than he periodically proclaim in his Perl evangelist hat) Larry Wall like to hype this idea. For example in Perl the challenges ahead you can read: 

Wall: Yeah, but I actually designed the syntax to work more like natural language, initial impressions notwithstanding. I'm sort of half a linguist and half a computer scientist, and the linguist part of me is not going to apologize for what I think is good human engineering.

Note that he is pretty cautious. He claims only "to work more like". But with all proper respect for Larry Wall I do not believe that Perl is closer to natural languages than Unix shell ;-).

The truth is that Perl has nothing to do with natural languages. It is just a non-orthogonal and pretty complex PL/1-style algorithmic language.  And the fact that Larry is a linguist (and preacher) by training does not change this fact no matter how many time this artificial association with natural languages is mentioned.

Second point is that Perl actually is designed so that there are many ways of doing the same thing. It's not completely true. In reality Perl provides shortcuts to some popular combinations, but often freedom of doing the same thing in many different ways is present only to the extent it is present in PL/1.

Third point is about expressiveness. Perl is not as expressive as I would like or like Perl fanatics claim. It has many sometimes very annoying limitations like mandatory use of different equality operation signs in numeric and character comparisons. Clumsy statement syntax, ridiculously complex rules concerting expressions and statements and rules about what each function return. Just one example:

substr($text, 0,1); # is not a valid statement -- syntax error

splice(@text, 0,1); # legitimate statement

The idea of second example is actually very sound, at least for me, if expression is used as statement the target variable should the assumed on the left hand side. So both statements should be interpreted as:

$text=substr($text, 0,1);

@text=splice(@text, 0,1);

But this is not the case and here we can see that even a limited PL/1 philosophy -- "if a particular combination of symbols have a particular semantic sense -- this semantic should be implemented in the language" is not very consistently implemented in Perl, although the authors are trying.

Another example. Try to use array as a first argument of the split function. It does makes a perfect semantic sense in Perl. First time the first element of the array is interpreted as a regular expression, than second and so on in round-robin fashion.  But here Perl behave differently as you can prove yourself ;-)

Nice summary of Perl hype can be found in www.perl.com - Ten Perl Myths. It contains some real counter myth information (like Perl is too slow, Perl is insecure, Perl is just for CGI, Perl is not commercial, so it can't be any good, Perl is just for Unix), but also a lot of hype/advocacy blah-blah-blah like attempts to prove that the following statements are false:

•Perl is hard
•Perl looks like line noise
•Perl is hard because it has regexps
•Perl is hard because it has references

Here is one sample of this overzealous Perl advocacy:

The first thing people will tell you is that Perl is hard: hard to learn, hard to use, hard to understand. Since Perl is so powerful, the logic goes, it must be difficult, right?

Wrong. For a start, Perl is built on a number of languages that will be familiar to almost every programmer these days. Know any C? Then you've got a head start with Perl. Know how to program the Unix shell? Or write an awk or sed program? If so, you'll immediately feel at home with some elements of Perl syntax.

And even if you don't know any of these languages, even if you're totally new to programming, I'd still say Perl was one of the easiest languages to begin programming with, for two good reasons.

Perl works the way you do. One of the Perl mottos is `There's more than one way to do it'. People approach tasks in very different ways, and sometimes come out with very different solutions to the same problem. Perl is accomodating - it doesn't force any particular style on you, (unless you ask it to) and it allows you to express your programming intentions in a way that reflects how you as a person think about programming. Here's an example: suppose we've got a file which consists of two columns of data, separated by a colon. What we have to do is to swap around the two. This came up in a discussion the other day, and here's how I thought about doing it: Read a line, swap what's on either side of the colon, then print the line.

        while (<>) {
                s/(.*):(.*)/$2:$1/;
                print;
        }

It's not a hard problem to understand, so it shouldn't be hard to solve. It only needs a few lines - in fact, if you use some command line options to perl, you can dispense with everything apart from the second line. But let's not get too technical when we can get by without it.

Now, for those of you who don't know that much Perl, that diamond on the first line means `read in a line', and the s on the second means `substitute'. The brackets mean `remember' and .* means `any amount of anything'

So, while we can read a line in, we do some kind of substitution, and then print it out again. What are we substituting? We take something which we remember, followed by a colon, then something else we remember. Then we replace all that with the second thing, a colon, and the first thing. That's one, fairly natural way to think about it.

Someone else, however, chose to do it another way:

 

        while (<>) {
                chomp;
                ($first, $second) = split /:/;
                print $second, ":", $first, "\n";
        }

Slightly longer, maybe a little easier to understand, (maybe not, I don't know) but the point is, that's how he thought about approaching the problem. It's how he visualised it, and it's how his mind works. Perl hasn't imposed any particular way of thinking about programming on us.

To go through it, quickly: chomp takes off the new-line. Then we split (using the reasonably obviously named split function) the incoming text into two variables, around a colon. Finally, we put it back together in reverse order, the second bit, the colon, the first bit, and last of all putting the new-line back on the end where it belongs.

The second thing which makes Perl easy is that you don't need to understand all of it to get the job done. Sure, we could have written the above program on the command line, like this:

        % perl -p -e 's/(.*):(.*)/$2:$1/'

(-p makes Perl loop over the incoming data and print it out once you've finished fiddling with it.)

But we didn't need to know that. You can do a lot with a little knowledge of Perl. Obviously, it's easier if you know more, but it's also easy to get started, and to use what you know to get the job done.

Let's take another example. We want to examine an /etc/passwd file and show some details about the users. Perl has some built-in functions to read entries from the password file, so we could use them. However, even if we didn't know about them, we could do the job with what we do know already: we know how to read in and split up a colon-delimited input file, which is all we need. There's more than one way to do it.

So, thanks to its similarity to other languages, the fact that it doesn't force you to think in any particular way, and the fact that a little Perl knowledge goes a long way, we can happily consign the idea that `Perl is hard' to mythology.

See also insightful commentary  to the paper by Martin Maney:

Perl is hard ... Perl is built on a number of languages that will be familiar...

Actually, this is one of the reasons that Perl is hard to learn. On the one hand, if you've never met any of the languages and traditions that Perl borrows from, then it is hard because there are so many weird new things and weirder notation; but if you are familiar with many of Perl's roots, say C, Bourne shell, AWK, sed, then you'll have the problem of learning a language that lifts notions and bits of syntax from all of these, then alters them and mixes them together. There's a proper jargon word for the problem of learning something new that's similar but annoyingly different to something already well known, and this was my principle reaction to Perl.

Perl looks like line noise

It does. Mostly. Including a lot of code in the books that Perl fans tell us are the good ones, not to mention the stuff found in the perl news groups. I'm sorry, Perl may be capable of being written so that it doesn't look like a cat was playing with a mouse on your keyboard, but this almost never happens in practice. As for there was an Obfuscated C Competition long before there was an Obfuscated Perl one, this hardly deserves an answer, but I can't resist pointing out that Obfuscated C was a tradition before there was a Perl to have any such competition in, so this point is no point at all.

Perl is hard because it has regexps

True if you think regexps are hard. I don't, but I started learning them several decades ago. I will allow as Perl's regexps are rather more complex and studded with options that of necessity make them more confusing than simpler regexps, so there's some basis for this feeling even among those who know grep and other traditional regexp-based tools.

Perl is hard because it has references

He actually spends his time here trying to show that Perl's references make up for its lack of any real data structuring mechanisms (aside from arrays and simple associations, which of course are sometimes all you need). They don't, although the weak methods sketched are better than nothing. A little bit, anyway.

For additional examples of Perl hype one can browse that following papers:

• IBM developerWorks: Running away with the plot -- The story of Perl (Jan 02, 2000)

• Perl Whirl 2000 (Apr 11, 1999)

• Perl, the first postmodern computer language (Mar 11, 1999)

• Feed: LARRY WALL: Divine Invention (Feb 11, 1999)

• O'Reilly: Larry Wall Wins Free Software Foundation Award (Oct 20, 1998)

• Salon Magazine: The joy of Perl (Oct 13, 1998)

Prev | Up | Contents | Down | Next