Minimal Perl for Unix and Linux People 332
Ravi writes "Perl (Practical Extraction and Report Language) — the language which was created by Larry Wall is arguably one of the greatest programming languages. But it has a reputation for taking an excessive cryptic nature which gives it an image especially among Perl novices as a language which is complex and hard to master. Minimal Perl: for Unix and Linux people, authored by Tim Maher and published by Manning Publications addresses the obstacles presented by Perl's complexity. This book which is divided into two parts comprising of a total of 12 chapters takes a unique methodology to explain the Perl syntax and its use. The author emphasizes on Perl's grep, awk and sed like features and relys on concepts such as inputs, filters and arguments to allow Unix users to directly apply their existing knowledge to the task of learning Perl." Read on for the rest of Ravi's review.
What I found while reading this book is that the "Minimal Perl" is a specially crafted subset of Perl language designed to be easily grasped by people who have a Unix background and who wish to use Perl to write their scripts. Its aim is to filter out the complex way of writing programs using Perl and whenever possible to accomplish tasks using just one or two lines of Perl. In the first part of the book, the author explains how Perl can be used to do the same tasks as accomplished by common Unix tools such as grep, awk, sed and find. He goes one step further by explaining how one can accomplish much more and in a much simpler way by using Perl techniques.
| Minimal Perl for Unix and Linux People | |
| author | Tim Maher |
| pages | 464 |
| publisher | Manning Publications |
| rating | 8 |
| reviewer | Ravi |
| ISBN | 1932394508 |
| summary | Provides a slice of Perl which when mastered can accomplish most of the jobs which require Perl |
Throughout the book, the author makes sure that the learning curve in acquiring Perl skills remain gentle. Perl is a language whose syntax has a multitude of options, this book is peppered with numerous tables which provide excellent information at a glance. For example, in the third chapter titled "Perl as a (Better) grep command", the author lists and compares the fundamental capabilities of Perl and the different grep commands such as grep, egrep and fgrep which clearly shows the advantages that Perl has over grep. In another table, you get a birds eye view of the essential syntax of Perl's regular expressions and their meaning. This chapter alone has around 12 tables. This is a really nice feature because it doubles as a Perl reference where you can flip to the respective page and get the information you need.
The main strength and drawback of a language such as Perl is its dependence on regular expressions for accomplishing complex tasks. Once you master the regular expressions, the sky is the limit for ordering and segregating data using this language. In Perl, there is more than one way of doing the same thing. What is unique about this book is that the author specializes in explaining the easiest way of doing a particular task.
In many places, the author demonstrates complex tasks using just a few lines of Perl code. Many of the examples covered in this book are practical examples which give an idea of how the commands relate to the final outcome. For instance, while elaborating on the one line grep like commands in Perl, the author illustrates a web oriented application of pattern matching where he shows how to extract and list, the outline of slashdot.org site's front page. The surprising thing is this is accomplished using just a single line of Perl code. This book has lots of such one line examples which teache how to use Perl intelligently using minimal effort.
If part I of this book focuses on ways in which simple Perl programs can provide superior alternatives to standard Unix commands, the second part throws light on the other aspects of Perl concentrating on the syntax of the language and various built-in functions and modules available which do away with a lot of re-invention of the wheel, so to speak, and helps churn out code which is portable.
Chapter 7 titled "Built-in functions" introduces an eclectic mix of functions available in Perl. You have functions which are used to extract a list of fields from a string, functions to access the current date and time, generating random numbers, sorting lists, transforming lists, managing files with functions and so on. These functions are broadly classified into those which generate and process scalars and those that process lists.
In chapter 8 of this book, the author involves the reader on the numerous scripting techniques that can be used to write better Perl programs.
It was quite surprising that the author has chosen to discuss the variables, more specifically the list variables comprising of arrays and hashes, as well as the looping constructs only in the 9th and 10th chapters, when they should be somewhere up front. In hind sight, I feel it is a good decision. Once you execute the one liner Perl programs in the initial chapters, you will be fairly confident in using Perl by the time you reach the 9th chapter.
The last two chapters deal with creating sub-routines and modules. Over the years various Perl programmers have created modules which are used for diverse purposes. With an aim to share these modules, they are collected and stored at one central place known as CPAN, which is an acronym for Comprehensive Perl Archive Network. The final chapter, apart from teaching how to create modules in Perl and manage them, also introduces the CPAN and ways in which one can find the right module by searching on CPAN.
The special variables cheat-sheet and the guidelines for parenthesizing code provided in the two appendices are really useful as a quick reference while writing Perl programs.
This is not a comprehensive book on Perl, rather the author provides a slice of Perl which when mastered can accomplish most of the jobs which require Perl. You won't find object oriented concepts of Perl being mentioned in this book. In many ways the author has moved beyond explaining a subset of Perl by providing a section titled "Directions for further study" at the end of each chapter, where the author lists further material which can be used to learn more about the topic that is covered.
I really enjoyed going through this book, especially because of its focus on the practical side of using Perl and taking a minimal approach.
Ravi Kumar maintains a blog titled "All about Linux" where he shares his thoughts and experiences in using Linux, Open Source and Free software.
You can purchase Minimal Perl for Unix and Linux People from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I {} Perl (Score:5, Interesting)
That is all...
the book looks very relevant (Score:2, Interesting)
Why not for Windows people? (Score:5, Interesting)
Just remembering by boss's jaw drop when he asked me if I could do a quick analysis of a couple thousand lines of logs and asked how long it would take. "10 minutes." And I delivered. He thought I'd have to fire up VS and write some C code.
He borrowed my Camel book during his next vacation.
Re:Should I read this or continue with sed/awk? (Score:2, Interesting)
Because Perl is a general purpose programming language, it can do a lot more than sed or awk. Learning all three is useful if you do a lot of Unix administration or command-line work, but you can get by with Perl alone if you only learn one.
It depends on the application. I appreciate perl2exe (though I've heard good things about PAR [cpan.org] and wxPython has better documentation than wxPerl, but Perl also has the CPAN. I've had no small success building large applications in Perl.
Re:Cryptic? Complex!? (Score:5, Interesting)
I used Perl for fun and profit (wrote many Perl scripts for a speech software company) for many years, hanging on past the point where others started using Python, PHP, and Ruby instead. I knew Perl and could practically think in it. But one of the main problems with Perl is it's so easy to right totally unmaintainable, totally unreadable code. I read a Perl program I wrote a few years ago and I can never figure it out. The object-oriented part of Perl is a ridiculous kludge with so many little details that I can't remember them all. There are about 100 subtly different ways to write a constructor for your object:
sub new() {
my ($class) = @_;
my $self = {}
return bless $self, $class
}
sub new() { return bless {} }
sub new() {
my ($class) = @_
my $self = {}
bless $self, (ref $class || $class)
}
All of these, of course, have subtly different behaviors. The second will break inheritance. The third will allow you to use the constructor as an instance method, not just a class method. There are no enforced function prototypes or standard way to get parameters... and if you do use the *optional* prototype mechanism, you will subtly change the precedence of calls to your function.
I thought that having 1000 ways to do something was great, but it turns out to be a nightmare for non-trivial programs. Every time I try to use a cute fancy shortcut in Perl, it bites me in the ass. As a result of the over-flexibility, people have tried to impose "standards" on Perl. There are "standard" techniques for named parameters, "standard" techniques for accessor functions, etc. And that's nice, but Perl has 10,000+ available modules to do everything from screen-scrape Google news to access Oracle databases (it's greatest strength!!!). And not all those modules use the standard techniques.
About a year ago I decided to give Python a try. And I haven't looked back. It can do everything Perl can do, and then some. Everything is clearer and having a "standard" way to do most things makes learning new modules immensely easier. Having slightly more verbose syntax and strict type-checking is slightly annoying at first, but keeps me sane in the long run.
Basically I don't use perl for anything other than one-liner regexp tricks anymore. Stuff like perl -i -pe 's/FOO/BAR/g' *, which will change the string FOO to BAR in all the files in the current directory.
Re:*sigh* (Score:4, Interesting)
Re:Should I read this or continue with sed/awk? (Score:3, Interesting)
I don't have much experience with sed and awk so I'm not sure what you plan on using perl for. The basic answer is you need to use the right tool for the job but I don't know what job you have so I can't directly answer your question.
Perl is pretty good with text manipulation due to it's built-in and extensive support of regular expressions. It's also got most programming language features so you can extend it and use it for larger tasks or even create real software all in perl. Perl also has a very large module repositor (cpan.org) where you can find all sorts of modules written by tons of authors to access databases, parse and generate http headers, access image manipulation libraries, and so on.
Perl can do a lot but there are downsides to that. Because there are so many different approaches and so many different tools and features in the language, you have to learn a lot in order to understand a lot and it can cause some unnecessary implementations that are either too complex, too hard to read (and maintain), or error prone. I've been using perl for quite sometime now (years) and I still see something new whenever I browse someone else's source. In addition, there are many features of the language that I still don't know how to use or I know how to use them but I refuse to use them because it makes the code harder to read. My basic advice here is if you do not have the self-discipline to keep your code clean, perl probably isn't for you because your code can easily get ugly if you're not careful.
Some people like that but there are significant trends even in the perl community for cleaner syntax and elegant solutions. For example, take a look at Moose in cpan and if you have any object oriented programming experience it is a pretty interesting read. Also, if you do choose to try perl, start with the 'use strict' pragma and other safety features like function prototyping to ensure correct parameter passing and 'my' variable declarations. The use of those things alone will dramatically make it easier to maintain and debug your code.
Re:Cryptic? Complex!? (Score:3, Interesting)
Re:Should I read this or continue with sed/awk? (Score:3, Interesting)
Perl's greatest strength is CPAN, which is a library of perl modules that handle just about any programming task that you can think of, and then some. Sometimes, it's uncanny how well certain modules fit your problem -- you can almost guess the names based on what you want. (need to find the size of an image? Try Image::Size.)
In my opinion, Perl's syntax is awful. Because it doesn't have a context-free grammar, and many lines are ambiguous unless you're actually running a Perl program, writing a syntax highlighter for Perl is all but impossible. Another annoyance is having to use the different symbols like @ and % to denote variable type, and the reference/dereference syntax looks like comic book swear words. So, it's not "typing friendly." That's its biggest weakness.
But really, the syntax of a language is such a small part of the overall picture that it's not worth worrying about too much. Finding a CPAN module that does exactly what you need more than makes up for any time you spend struggling to learn the syntax.
You can't beat Perl for web programming. I just wish it were half as well supported as PHP seems to be on the cheap web hosts.
Re:oh come on, you're not even trying now (Score:5, Interesting)
KISS is hard. Very hard. It's different in different places. Sometimes keeping it simple means writing less code. Sometimes it means creating a new sub-language that better describes your problem.
In perl, you can change the nature of the language itself. *Everything* can be changed. The idea is that if there is more than one way to do it, then you can do it the simplest way for whatever definition of simple is required.
Maintaining consistency is up to the developer himself. Obviously, those tempted to succumb to the lure of sloppiness (which, unfortunately, in my experience, is every perl programmer I've ever met including myself) shouldn't use perl for really big projects.
You can't blame the language for giving you that freedom, though.
Perl is where it is because you don't have to change the way that you think in order to program in it. Perl will change how it works to match how you think, which makes it more convenient than almost any other language.
That particular behavior is what makes it possible to have so many perl modules in existane, which in turn is responsible for the popularity. It's also why about half of those modules have bugs so horrible that they're unusable. It's certainly a tradeoff.
Re:Why not for Windows people? (Score:3, Interesting)
Re:Cryptic? Complex!? (Score:3, Interesting)
You've put your finger on it. Perl has many cool features, great strengths, and great depth. But it gives you almost no restrictions on how to combine them. Seductive, but not so good in the long run.
Re:*sigh* (Score:3, Interesting)
Re:Cryptic? Complex!? (Score:3, Interesting)
Python was one of my first programming languages, and the whitespace thing made sense to me from the beginning. In most C-style code, people use both braces and indentation to denote blocks; isn't that redundant? It seems braces are for the compiler and indentation is for human readers. Shouldn't higher level languages be designed for humans rather than machines?
Re:*sigh* (Score:3, Interesting)
Steve Wilhite also tells us that "GIF" should be pronounced like "JIF".
Which is exactly how everybody I know pronounces it.
Let me guess: when you say the word "laser," you pronounce the s with a "zzz" sound, right? Except the "S" in laser means "stimulated," not "ztimulated!" See, you're pronouncing laser wrong!
A more reasonable conclusion would be to say that the sound of a letter in the pronunciation of an acronym need not relate to the sound of that letter in the word from which it derives.