Introduction to Perl 5.10 for Unix System Administrators

(Perl 5.10 without excessive complexity)

by Dr Nikolai Bezroukov

Contents : Foreword : Ch01 : Ch02 : Ch03 : Ch04 : Ch05 : Ch06 : Ch07 : Ch08 :

Chapter 1: History of Perl and Perl Programming Environment Overview

Note: This is unpublished copyrighted material  licensed under the Creative Commons Attribution-NoDerivs-NonCommercial License.

Prev | Up | Contents | Down | Next

1.3. Notes on Perl Hype

To end this introduction on a skeptic note let's discuss Perl hype.  My point is that it often tries to emphases non-relevant features of Perl while omitting those that really has tremendous value and remain valuable and innovative despite competition from new members of scripting languages family such as PHP, Python and Ruby. I would distinguish the following features that are missing in Perl PR campaign:

1. Great affinity to Unix. A set of documentation and books written by specialists in Unix and often people with Unix system administrator background.
2. Availability of pointers. Most language designers treat pointers as lower language feature which is necessary only for lower-level compiler and operating system implementation languages like C. This is an illusion. In reality pointers are a fundamental language construct and absence of pointers in some form in a particular language is a great deficiency. Here Perl really shines as it is the only one with explicit  pointers implementation.
3. Unique integration of regular expressions into the language that was essentially borrowed but never matched by all other languages. 
4. Perl set of control structures is an improvement over C and is one of the best of any algorithmic languages in existence.
5. Providing explicit access to some relatively low level features, such as namespaces and symbol table which provides tremendous flexibility.  The way OO features bolted-on Perl 5 structures is an interesting example of this flexibility.
6. Unlike some other languages Perl does not emphasize OO which in many areas where Perl is used (such as text processing) and not only useless but pretty harmful. 
7. It has a very good, simply excellent debugger. Which is actually the half of any programming language attractiveness.

Instead Perl PR campaign emphasize features that are irrelevant, or simply false.

1. First of all, in no way Perl is closer to natural languages than, say, Korn shell or Java. Sometimes Larry Wall like to hype this absurd idea. And believe me Larry Wall is more complex than this simplistic attitude. 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 complex non-orthogonal 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.
    

2. The second often raised about Perl point is that Perl actually is designed so that there are many ways of doing the same thing. It's not completely true. This is a side effect of choices made in the design and typical for any complex non-orthogonal language. In reality even Fortran provides several ways of doing the same thing. So you might well consider this as an intrinsic property of any algorithmic language. What we are talking about is that language facilities overlap, for example you can change string using index and substr build-in function and you can use regular expressions. This is a side effect of the way Perl is agglomeration and refinement of several languages (awk, shell and C) but to what extent this is an advantage is unclear. Non-orthogonality generally increases complexity of the language so any person of such language uses only a limited subset and often does not even suspect about different ways of doing the same thing available in the language. So this is more curse then a blessing.

3. Third point is about expressiveness. Perl is not as expressive as I would like or like Perl fanatics claim. It has many annoying and error prone limitations like mandatory use of different equality operation signs in numeric and character comparisons. Clumsy statement syntax, ridiculously complex rules concerting expressions and statements as well as rules about what each built-in function returns ;eave feeling of "perma-beta" well known feeling about Linux in general. 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 somewhat 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 accommodating - 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

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019