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

Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

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:

Prev | Up | Contents | Down | Next



Etc

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner. 

ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.  

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 quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard 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 DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting 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-MonthHow 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


Copyright © 1996-2016 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.

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.

Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info

Disclaimer:

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 author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: July 07, 2013