Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Minimal Perl for Unix and Linux People

samzenpus posted more than 7 years ago | from the easy-does-it dept.

Book Reviews 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.

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.

cancel ×

332 comments

Sorry! There are no comments related to the filter you selected.

Minimal Perl for Unix and Linux People (2, Funny)

mobby_6kl (668092) | more than 7 years ago | (#18100588)

Minimal Perl for Unix and Linux People? Is this the result of a perlgolf competition between perl-related books?

Very Minimal Perl for Unix People (2, Informative)

Phreakiture (547094) | more than 7 years ago | (#18101062)

Very useful if you need to use text files from DOS/Windows and DOX2UNIX is not installed:

perl -e "while(<>){s/\r//;print;}"

This strips carriage returns out of a file, and does it pretty quickly.

Re:Very Minimal Perl for Unix People (1)

torstenvl (769732) | more than 7 years ago | (#18101678)

mv text.txt text.dos && cat text.dos | tr -d "\r" > text.txt && rm text.dos

Re:Very Minimal Perl for Unix People (4, Informative)

Tet (2721) | more than 7 years ago | (#18101736)

This strips carriage returns out of a file, and does it pretty quickly.

No, it's horrendously slow. The traditional Unix way of doing it (tr -d '\015') is around twice as fast on files that are sufficiently large that startup costs are lost in the noise, and even faster on smaller files.

Re:Very Minimal Perl for Unix People (1)

imadoofus (233751) | more than 7 years ago | (#18101792)

Shouldn't that be

perl -en "s/\r//;print;"

*sigh* (4, Funny)

A beautiful mind (821714) | more than 7 years ago | (#18100606)

Perl (Practical Extraction and Report Language)
That's a backronym. By those standards you could also call PHP Pretty Hellish Performance.

Re:*sigh* (3, Insightful)

Timesprout (579035) | more than 7 years ago | (#18100836)

Na, theres nothing pretty about PHP

Re:*sigh* (2, Informative)

swordgeek (112599) | more than 7 years ago | (#18100870)

Honestly, it doesn't matter. The cart came before the horse in this case, but regardless of its acronymic meaning (or lack thereof) when it was created, Perl DOES now stand for Practical Extraction and Report Language. Just ask Larry Wall.
Remeber that a "Backronym" (hate that word!) is a subtype of acronym.

Re:*sigh* (3, Interesting)

croddy (659025) | more than 7 years ago | (#18101078)

Steve Wilhite also tells us that "GIF" should be pronounced like "JIF". Don't let these erroneous claims fool you just because they come from the authors.

I've got a question about subtypes of acronym (3, Funny)

spun (1352) | more than 7 years ago | (#18101532)

Remeber that a "Backronym" (hate that word!) is a subtype of acronym.

Would Muhammad Ali's GOAT (Greatest Of All Time) line of food products [bakeryandsnacks.com] be considered a snackronym or a blackronym?

Re:*sigh* (1)

NoOneInParticular (221808) | more than 7 years ago | (#18101734)

But, what happened to "Pathetically Eclectic Rubbish Lister"?

Re:*sigh* (1)

infaustus (936456) | more than 7 years ago | (#18101764)

He also gives equal support to the "pathologically eclectic rubbish lister" expansion.

Re:*sigh* (1)

Nefarious Wheel (628136) | more than 7 years ago | (#18101496)

I thought it was "Perl Hates Programmers"?

Cheaper at Amazon. (-1, Troll)

Anonymous Coward | more than 7 years ago | (#18100620)

Slashdot links to B & N here, but it seems that the book is quite cheaper at Amazon [amazon.com] . Just look at the "Used and new..." listings. (Note that that is a referral link, but it costs you no more than a direct link. Just don't click it if you object.)

Re:Cheaper at Amazon. (1, Troll)

Lockejaw (955650) | more than 7 years ago | (#18100652)

Congratulations, AC, you've discovered that used books are cheaper than new ones.

Re:Cheaper at Amazon. (0)

Anonymous Coward | more than 7 years ago | (#18100740)

Among the "Used and new..." listings there are just as many new books--sold by dealers affiliated with Amazon but able to offer a lower price than them--than used copies.

PERL backronym (0)

Anonymous Coward | more than 7 years ago | (#18100636)

Yeah...doesn't really mean what the summary says (the name itself)

[wikipedia]
The name is occasionally given as "PERL" (for Practical Extraction and Report Language). Although the expansion has prevailed in many of today's manuals, including the official Perl man page, it is merely a backronym. The name does not officially stand for anything. Spelling PERL in all caps is therefore considered a label of community outsiders. Several other expansions have been suggested, including Wall's own humorous Pathologically Eclectic Rubbish Lister.

Indeed, Wall claims that the name was intended to inspire many different expansions.

Re:PERL backronym (5, Funny)

morgan_greywolf (835522) | more than 7 years ago | (#18100808)

Nope.

Stands for Python'll Eventually Replace this Language.

or, optionally:

Perl Eats Ruby for Lunch :-D

So you like the book (1)

NaCh0 (6124) | more than 7 years ago | (#18100654)

But give it an 8/10. Care to explain why? The only thing I see in your review is a poor assumption that in hindsight you agree with.

Re:So you like the book (4, Funny)

realmolo (574068) | more than 7 years ago | (#18100864)

8/10 is a *good* review. You've been reading too many IGN game reviews.

IGN scoring works like this:

5/10 - The game runs

6/10 - The game is an FPS

7/10 - The game has team-based mulitplayer online play

8/10 - The game runs at 190 frames-per-second

9/10 - The game is made by a publisher that buys advertising on IGN

10/10 - The game is made by a publisher that buys A LOT of advertising on IGN
 

Re:So you like the book (1)

NaCh0 (6124) | more than 7 years ago | (#18100930)

No, I don't play video games at all.

I see the rating as 80% good, 20% bad.

I'd like to hear about the 20% bad side to balance the glowingly positive side he posted.

Re:So you like the book (1)

quintesse (654840) | more than 7 years ago | (#18101348)

That's silly, it would not give you any opportunity anymore to give higher notes. Imagine that you can't find any flaws in the book, according to you that means he would have to give it a 10. Then next week another book comes out that is way better in lots of aspects.... what to do now? Give it an 11?

Writing book reviews is not an exact science, you can hardly make some kind of formula and get a meaningful result, so maybe what he uses is something like this (just an example):

4 - book contains incorrect information and/or is generally badly written
5 - book is not bad but misses information in some key areas
6 - book is okay but nothing special either
7 - book is well written, does not contains any obvious mistakes, covers all key areas
8 - book is really well written, knows how to explain difficult subjects
9 - book is extremely well written, gives insight and makes complex subjects seem almost easy
10 - after reading this book you can call yourself an expert and won't need to read any more books on the subject

Re:So you like the book (-1, Troll)

Anonymous Coward | more than 7 years ago | (#18101390)

No. 8/10 is a *BAD* review.

Slashdot scoring works like this:

Less than 9: Terrible book. Avoid it like the plague.
Equal to 9: Average book. Read it only if you are particularly interested in the subject.
Greater than 9: Excellent book. Run, don't walk to the book store.

Cryptic? Complex!? (5, Funny)

setirw (854029) | more than 7 years ago | (#18100758)

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.


So wrong! Just look at the following example:

#!/usr/bin/perl -w

length q caller vec and print chr oct ord q qx eq and print chr ord q ref or and print chr ord q or no and print chr ord q else and print chr ord qq q q and print chr ord q tie gt and print chr ord qw q sin q and print chr ord q q eq and print chr ord qw q sin q and print chr ord q sin s and print chr ord q cmp lc and print chr ord q split s and print chr ord qw q lc q and print chr ord q ne sin and print chr hex length q q bless localtime ref q


Run that. Nothing cryptic or complex at all.

(BTW, it prints "Perl is simple!")

Re:Cryptic? Complex!? (0)

MindStalker (22827) | more than 7 years ago | (#18100874)

Uhhh, yea you can purposefully make syntax cryptic in ANY language. Get back to me when you have a point.

Re:Cryptic? Complex!? (0)

Anonymous Coward | more than 7 years ago | (#18100908)

Whoosh!

Re:Cryptic? Complex!? (0, Flamebait)

clayne (1006589) | more than 7 years ago | (#18100912)

Really. Does C have $_ or any number of ridiculously implied $ nonsense in it?

Perl should have just stopped about 8 years ago.

Re:Cryptic? Complex!? (0, Flamebait)

jellomizer (103300) | more than 7 years ago | (#18101098)

Perl being a simple programming langues causes Bad Programmers to make overly Criptic code. Unlike say Python which forces some good coding practices. Perl and other Languages gets Cryptic when Regular Expressions are used. I myself tend to avoid Regular Expressions when possible. I know they are powerful, fast and usful and such, but they make my code ugly and anyone who doesn't know them thinks I am writting in binary. In my line of work being able to change code quickly (Because of rapidly changing requirements) is far more important inital coding time, or even processing speed.

Re:Cryptic? Complex!? (2, Interesting)

Millenniumman (924859) | more than 7 years ago | (#18101298)

How do you avoid using regular expressions? What do you replace them with? And how can they be confused with binary?

Re:Cryptic? Complex!? (5, Interesting)

MoxFulder (159829) | more than 7 years ago | (#18101050)

Run that. Nothing cryptic or complex at all.
Indeed! I used to be a die-hard hard-core Perl hacker. When I discovered Perl in college around 2001, I thought it was the greatest thing since sliced bread. And Perl really was revolutionary: you could do almost everything you could do in C, but more concisely, since you could create complex data structures without manual memory management.

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:Cryptic? Complex!? (3, Funny)

Ikoma Andy (41693) | more than 7 years ago | (#18101440)

But one of the main problems with Perl is it's so easy to right totally unmaintainable...
Dude, I'm thinking it's not Perl that was your problem...

Re:Cryptic? Complex!? (1)

MoxFulder (159829) | more than 7 years ago | (#18101460)

Hehehe... ya got me! You know what's funny? I think that's the first time I've ever made that mistake. I'm a bit of a grammar Nazi normally. I'm off to do some self-flagellation now.

Re:Cryptic? Complex!? (1)

Ikoma Andy (41693) | more than 7 years ago | (#18101520)

Cool. I'm going to go try python.

Re:Cryptic? Complex!? (4, Insightful)

abigor (540274) | more than 7 years ago | (#18101752)

His usage of "it's" is correct. It's = it is.

Re:Cryptic? Complex!? (4, Informative)

massysett (910130) | more than 7 years ago | (#18101608)

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.

Sed will do that too:

sed -i 's/FOO/BAR/g' *

The review says that the book uses the reader's knowledge of sed, awk, and grep. I figure: why not just use sed, awk, and grep...however, one advantage for Perl here is that (I presume) that line works with any Perl; '-i' is a GNU sed extension and may not work on non-GNU seds...

Re:Cryptic? Complex!? (1)

MoxFulder (159829) | more than 7 years ago | (#18101718)

Sed will do that too:

sed -i 's/FOO/BAR/g' *

The review says that the book uses the reader's knowledge of sed, awk, and grep. I figure: why not just use sed, awk, and grep...however, one advantage for Perl here is that (I presume) that line works with any Perl; '-i' is a GNU sed extension and may not work on non-GNU seds...


Indeed, you're completely right! After 6+ years of using Perl, I no longer use it for anything that sed/awk/grep can't do :-P

As I've said, Perl was great while it lasted. It's just that there are now better tools for everything it ever did well: sed/awk for super quick and dirty text munging, and Python for everything else.

(Of course there's also Ruby. I haven't tried Ruby, but my *totally uninformed* impression is that it's a lot less mature than Python, a little more Perl-ish, and the coolest thing on the block right now.)

Re:Cryptic? Complex!? (3, Insightful)

Scarblac (122480) | more than 7 years ago | (#18101724)

I was a Python afficionado, although most of my professional experience was with Java. Then I joined a Perl project. I was open minded, any language can be good in the right hands. Now, two and a half years later, I'm pretty good at it.

As the team grows, we find ourselves relying more and more on standard techniques. They're not your standard techniques, they're just what we came up with as our standard way. They work well. We have a beautiful object oriented mod_perl/Template Toolkit system, unit tests, RoboDoc, the works. We know how to do this.

But, exactly as you say, we need coding standards. Lots. Just to make code more comprehensible, it needs to look pretty uniform. We can do that.

But then, note that objects are just hashes. Sometimes, you get odd data in them, due to some bug. Where did that happen? Of course you use grep, but there are so many ways to put something into a hash, that you run into problems. So you use getters and setters and make sure that all the code everywhere uses them.

But even things like renaming functions... different calling syntax can make it hard to grep for uses of a function, even. It's getting too ridiculous. Our book of coding standards is getting so thick that we could be coding fucking Java instead, and feel liberated. It's madness.

So, yes, you can do Perl for larger projects. It's possible. But you have to tie yourself down so badly, most of Perl's strengths as a language can't be used.

Now I want to get back to Python or Java...

It gets worse... (1)

mkcmkc (197982) | more than 7 years ago | (#18101574)

Even this

/$foo[bar]/
has no comprehensible meaning.

Perl could be the first language to bow out gracefully when it's day is done, but I'm not holding my breath...

Python (0, Flamebait)

Anonymous Coward | more than 7 years ago | (#18100776)

Just use Python. It is a far superior language. Perl is for fags.

-- Larry Wall

Re:Python (2, Funny)

licious (932923) | more than 7 years ago | (#18100886)

crap, I was wondering why Tom Cruise, John Travolta and R Kelly were with me in this smallish room filled with coat hangers and ties.

I {} Perl (4, Interesting)

Cally (10873) | more than 7 years ago | (#18100788)

perl has paid my rent and bought me more of the special, special tea from high in the Himalayas that enabled me to understand it so easily in the first place. I find myself speaking it in my sleep (and yes, you do speak Perl, just as you program in C.) It's a matter of some puzzlement to me that the loathesome homunculous that is PHP supplanted Perl as the preferred language for non-ASP web programming. (And ASP..? Don't get me started!!) I wrote my first code many years before discovering Perl, but it was Perl that turned me into a programmer. To me, you cannot claim to know Unix until you can read Perl (in both directions - in and out.)

That is all...

Re:I {} Perl (4, Funny)

timster (32400) | more than 7 years ago | (#18101006)

"Speak" Perl, right. Because what Unix really needed was a combination of the specificity of natural language and the friendly syntax of awk.

Re:I {} Perl (0)

Anonymous Coward | more than 7 years ago | (#18101232)

I'm glad you are able to pay your rent. However, Perl has nothing to do with UNIX. UNIX ran just fine before Perl and works fine without it now. There are many who know UNIX quite well. Even though they've never used or read Perl code.

Re:I {} Perl (1)

Phroggy (441) | more than 7 years ago | (#18101700)

It's a matter of some puzzlement to me that the loathesome homunculous that is PHP supplanted Perl as the preferred language for non-ASP web programming.
PHP is friendlier for beginners in two important ways: first, perl borrows heavily from existing C and UNIX syntax; anyone who already knows C and wants to calculate tomorrow's date will feel right at home with localtime(), but the newbie will find PHP's date functions far easier, for example. Also, perl's syntax is vastly more complex than PHP's, and language syntax isn't something you can just look up in a reference when you're not sure what something does. In PHP, once you learn the basics, anything you see that you don't understand, you can just look up the function name. In Perl, when you see something you don't understand, chances are you don't even know what you're looking at.

#!/usr/bin/perl
($n,$s)=('phroggy',join'', map{(sort split'','b_jl msepr$hyacn"otg.')
[$_]}map ord()-97=>split'' =>'shfmfrajitkpstguofniabcedlfqkdcodhpnb')
and print eval $s for(0..6);

the book looks very relevant (2, Interesting)

keshto (553762) | more than 7 years ago | (#18100816)

I use Python for most of my real scripting needs (i.e. any script that goes into a file and is over 10 lines long). I find Python to be a much easier language to think in and write. The biggest attraction of Perl for me is as a better awk and sed. Almost all of my Perl uses are of the sort "perl -pe 'xxxx'" . It seems the book is aimed at users like me.

Re:the book looks very relevant (1)

brunson (91995) | more than 7 years ago | (#18100980)

Perl is the vise-grips of programming languages, and as my Dad always told me, "There's a right tool for every job and it's almost never vise-grips".

Should I read this or continue with sed/awk? (2, Insightful)

RiotXIX (230569) | more than 7 years ago | (#18100840)

Useful review.

I'm currently going through http://www.oreilly.com/catalog/sed2/ [oreilly.com] , but I can see my using perl the more I do website programming. Would an experience scripter suggest that I switch to perl (for it seems it can perform similar text manipulation functions conveniently in a programming lanuage), or spend more time with sed/awk?

I'll probably do both incidentally, but opinions would be appreciated. It seems everyone rates perl.
I was going to switch to Python, but apparently Perl is better for smaller/one line regexp manipulation in scripts, and python for building large applications.

Re:Should I read this or continue with sed/awk? (3, Informative)

CRCulver (715279) | more than 7 years ago | (#18100978)

I don't want to put Perl down, but I think that its day is past except for those who, because they learnt it when it was the only thing around, are willing to tolerate its eccentricities. While switching from sed/awk to a general-purpose programming language with good text manipulation abilities can certain improve the possibilities of what you can accomplish with a single chuck of code and processor (as opposed to the old-time Unix way of piping), I'd recommend Python for that, getting started with a guide like Mertz's Text Processing in Python [amazon.com] (Addison-Wesley, 2003). Python is now as mature, if not more, in the realm of text processing as Perl was when its won its accolades a decade ago. (Heck, the treatment of Unicode is enormously forward-thinking compared to any other scripting language on the market.) And so you get the same power as you would with Perl, but much, much more readable.

I fear I'm starting a holy war by recommending Python in a Perl discussion. That's certainly not my intention. For those who already know and love Perl I say, great, keep on trucking. But I just can't see the point in steering newbies towards it.

That's fine (1)

RiotXIX (230569) | more than 7 years ago | (#18101168)

No that's brilliant - thanks for your opinion. A lot of people are pushing me for python, but I always figured it's reveared status for text processing/manipulation & wealth of existing scripts/implementations would mean perl would win hands down.

But if it's possible to do these things with python, then I'll go for that (soley for the reason that certain people with opinions I respect say it's the new way forward). I don't want to waste my time focusing on two languages (learning perl, and then moving to python later). Text processing in python is precisely the kind of reference I need.

Re:Should I read this or continue with sed/awk? (2, Interesting)

chromatic (9471) | more than 7 years ago | (#18101048)

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.

... apparently Perl is better for smaller/one line regexp manipulation in scripts, and python for building large applications.

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:Should I read this or continue with sed/awk? (3, Interesting)

tknd (979052) | more than 7 years ago | (#18101212)

Yes and no.

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:Should I read this or continue with sed/awk? (2, Interesting)

Bluesman (104513) | more than 7 years ago | (#18101306)

Like Java, the strength of Perl is in its libraries and its popularity. Unlike Java, Perl has support for a decent set of built in data structures, and the built in regular expression syntax is second to none.

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:Should I read this or continue with sed/awk? (1)

archen (447353) | more than 7 years ago | (#18101528)

As someone who has done quite a bit of perl (and still does) I'd say I'd have to agree that perl's sytnax needs work. I'm not very hip on the changes that will be comming in perl6 however so I decided to jump ship totally and switch to ruby.

Ruby can do most everything perl can do (including one liners), but once you've used perl, you will sorely miss CPAN. That and the ruby cgi library is junk, although good enough for simplistic cgi work.

Re:Should I read this or continue with sed/awk? (1)

Tet (2721) | more than 7 years ago | (#18101822)

Perl's greatest strength is CPAN

Perl's greatest weakness is CPAN, which makes deployment of perl code onto any halfway sane production server all but impossible.

Re:Should I read this or continue with sed/awk? (1)

_|()|\| (159991) | more than 7 years ago | (#18101450)

Would an experience scripter suggest that I switch to perl ... or spend more time with sed/awk?

There are two good reasons to learn sed and/or awk: portability and history. Although Perl may seem ubiquitous, you wouldn't use it in a cross-platform (i.e., Solaris, AIX, Tru64, HP-UX, etc.) install script. Since Perl is in some ways inspired by sed and awk, knowing them may help you to appreciate Perl. Otherwise, I wouldn't spend too much time on them.

Re:Should I read this or continue with sed/awk? (1)

halivar (535827) | more than 7 years ago | (#18101584)

you wouldn't use it in a cross-platform (i.e., Solaris, AIX, Tru64, HP-UX, etc.) install script

I've used it for just such a purpose, quite successfully. But I suppose it depends on the shop you're working with. In ours, we had the same version of Perl on all the Unix and Linux machines, so moving the scripts around was cake.

The shell scripts, on the other hand...

Re:Should I read this or continue with sed/awk? (1)

clem.dickey (102292) | more than 7 years ago | (#18101552)

I gave up sed and awk for perl because I grew tired of silly limitations: 2048 chars per line in sed, 300 chars per line and 300 fields in awk. Implementations could increase them, and probably have, but Perl avoids artificial limits as a matter of principal.

Nothing against Python though. I like the fact that the Python specification is about 80 pages, while the Perl specification is loosely spread throughout the 1000-page Camel book.

I wouldn't forget sed entirely. The Liinux Filesystem Hierarchy Standard requires sed and sh in /bin, but does not require perl or python.

Re:Should I read this or continue with sed/awk? (1)

clem.dickey (102292) | more than 7 years ago | (#18101680)

Should read *3000* characters per line in awk.

Re:Should I read this or continue with sed/awk? (1)

dramaley (20773) | more than 7 years ago | (#18101730)

I've been working with Perl in some fashion for close to a decade. I occasionally use sed or awk, but have not mastered them. So bear in mind that my differing level of experience with the different tools most certainly clouds my judgement.

I would recommend you move up to Perl. Whenever i have to use sed or awk i find them to be quite limiting. Regular expressions don't seem quite as powerful as those in Perl (and if you can master Perl's regular expressions you'll probably love the language). Some of the basic Unix utilities are also noticeably slower than Perl. A few weeks ago i was searching for some plain strings in a very large (multiple gigabytes) file, and naturally i used grep. But grep was taking a very long time. I switched to processing the file with a trivial "perl -ne 'print if /regex/'" and the search went several times faster. I'm not sure why grep has a slow regular expression parser. I have not tested performance of sed and awk against Perl, but i'd not be surprised if they do not fare well either.

That said, if Python is more your thing, go for it. I've wanted to learn Python, but i've gotten used to Perl's CPAN. The other thing that keeps me on Perl is its regular expression parser is so powerful. I've tried doing regex in other languages and it always seems painful by comparison.

I wouldn't say that Perl isn't suited for larger applications. I've written a few multi-thousand line applications that are still easy to maintain. Granted, depending on what you are doing, a few thousands lines might be small to you. For the programming i do (system administration stuff mostly), full applications like that are rather large.

Perl smells funny (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#18100858)

If I wanted to use a dead language I'd use QBasic.

Now I may be rude, and you may take that as trolling, but basically it's the truth.

Re:Perl smells funny (1)

halivar (535827) | more than 7 years ago | (#18101068)

Them's fightin' words! If I PEEK and POKE enough, I could probably hack your box and fry your monitor!

And I'll do it without line numbers! Fear me!

Re:Perl smells funny (1)

Chysn (898420) | more than 7 years ago | (#18101644)

Far from dead, of course. If you mean "dead as a web development language," then sure, almost. But it was never so great at that anyway.

I used to write web apps of moderate size in Perl. I don't any more, but I still use Perl almost every day as a part of my system administration duties. It's a great tool for little scripts that get data from a text file or a database, do something with it, and spit it back into a text file or database. As a language for extracting data and generating reports, it's quite practical.

That's cheating (1)

Daishiman (698845) | more than 7 years ago | (#18100866)

It's not considered one line if it has 3398EAFF23 characters.

Perl Script for the Dummy Like Me (1)

andy314159pi (787550) | more than 7 years ago | (#18100868)

#!/usr/bin/perl -w ##Oh boy I'm using an advanced scripting language! system("/usr/local/bin/csh csh.script_1"); system("/bin/rm /home/me/file_to_be_removed"); system("/usr/local/bin/application & application_output "); system("/usr/local/bin/csh csh.script_2"); # system("/bin/cat "I know Perl" > resume.txt"); exit

Perl Scripting for the Dummy Like Me (fixed) (2, Funny)

andy314159pi (787550) | more than 7 years ago | (#18100922)

#!/usr/bin/perl -w
##Oh boy I'm using an advanced scripting language!
system("/usr/local/bin/csh csh.script_1");
system("/bin/rm /home/me/file_to_be_removed");
system("/usr/local/bin/application & application_output ");
system("/usr/local/bin/csh csh.script_2");
#
system("/bin/cat "I know Perl" > resume.txt");
exit

Re:Perl Scripting for the Dummy Like Me (fixed) (0)

Anonymous Coward | more than 7 years ago | (#18101122)

Sadly for you, my friend, even THAT won't work.

Escape quote marks FTW!

That is all. :)

Re:Perl Script for the Dummy Like Me (2, Funny)

Phillup (317168) | more than 7 years ago | (#18101012)

You don't eat or drink or mow the lawn;
You just type on Slashdot all day long.
And then one day... you learn how to format and preview.

Re:Perl Script for the Dummy Like Me (1)

andy314159pi (787550) | more than 7 years ago | (#18101124)

yeah I was excited about my "comedy."

Re:Perl Script for the Dummy Like Me (1)

andy314159pi (787550) | more than 7 years ago | (#18101198)

If I was really serious about Perl scripting I would have used "Paula" [thedailywtf.com] as a variable.

Basic way to clean up your Perl code (1, Funny)

TheRealMindChild (743925) | more than 7 years ago | (#18100872)

10 CurrentFile = Dir("*.pl") 20 Do while len(CurrentFile) > 0 30 Kill CurrentFile 40 CurrentFile = Dir() 50 Loop 60 End

Footer Quote - Huh? (0)

Anonymous Coward | more than 7 years ago | (#18101030)

You'd think Slashdot could get the quote right:
"All that is gold does not glitter, not all those who wander are lost."

Why not for Windows people? (4, Interesting)

rrohbeck (944847) | more than 7 years ago | (#18101034)

I think Windows folks need "Minimal Perl" a lot more.

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:Why not for Windows people? (1)

SCHecklerX (229973) | more than 7 years ago | (#18101256)

Good point.

All of the windows boxes where I used to work had activestate installed on them, and if I ever have a job where I am administering windows systems again, that will be my first addition if it is not already there.

Here here! (0)

Anonymous Coward | more than 7 years ago | (#18101476)

I'll second that. Given how *ugh* painful scripting anything is in DOS, Perl is almost a necessity.

And I say this as someone who has written both nasty recursive DOS batch files because DOS makes it hard to do simple things like loops and subroutines cleanly, as well as someone who has written crazy multi-threaded network scripts in Perl (single threaded is way too slow, although fork() and shared memory under Windows can be kinda buggy).

Re:Why not for Windows people? (3, Informative)

Phroggy (441) | more than 7 years ago | (#18101782)

Have you tried Learning Perl on Win32 Systems [oreilly.com] ? Windows users wouldn't benefit from the Minimal Perl approach, because they don't have the background it builds on. This book starts at the beginning.

oh come on, you're not even trying now (-1, Flamebait)

Lord Ender (156273) | more than 7 years ago | (#18101052)

Perl ... is arguably one of the greatest[sic] programming languages.

It is obvious this entire article was posted just for all the ad revenue which will be generated by people refuting that wild claim. It's beneath me, but I can't resist doing just that. So here we go:

PERL is anything but a great language because it violates--nay, declares jihad against--the three fundamental principles of software engineering:
  • Keep It Simple, Stupid (vs PERL's TIMTWWTDI)
  • Maintain consistency (vs PERL's "hold-shift-and-mash-the-keyboard" syntax from Hell)
  • Never go in against a Sicilian when death is on the line! ... ok, forget that one. But suffice it to say I could continue this list for quite a while.

PERL is popular because it was in the right place at the right time, much like MS Windows. Other than that, it is just a fantastic collection of poor design decisions.

Re:oh come on, you're not even trying now (1)

SCHecklerX (229973) | more than 7 years ago | (#18101324)

Perl's "TMTWWTDI" actually DOES keep it simple. It allows you to adapt a specific style, and consistently use it.

Perl is the only language I have used that I can walk away from for a year, and then use it again WITHOUT having to touch a book or online manual.

What, exactly, does Perl's use of non-text characters have to do with consistency? BTW, ever try to write C code without (){}+=-*? Thought so.

Re:oh come on, you're not even trying now (1)

Fahrenheit 450 (765492) | more than 7 years ago | (#18101378)

I'd guess that it is one of the greatest languages in the same sense that McDonald's is one of the greatest restaurants.

Re:oh come on, you're not even trying now (4, Interesting)

fireboy1919 (257783) | more than 7 years ago | (#18101648)

You're not looking at it right.

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.

Cryptic? (3, Insightful)

locokamil (850008) | more than 7 years ago | (#18101072)

Perl newbie here.

Is it just me, or is it possible to create perfectly legible code in Perl if you use good technique, just like in any other language?

The cryptic/convoluted stuff only comes out when you try to be too cute. ..

Re:Cryptic? (3, Informative)

drinkypoo (153816) | more than 7 years ago | (#18101174)

Is it just me, or is it possible to create perfectly legible code in Perl if you use good technique, just like in any other language?

Of course. The thing that people complain about is that perl allows you to write code that only a fellow perl-head can understand. It's harder to accomplish that with C, for example. But perl doesn't automatically mean you won't understand it. It just makes it more likely :)

Re:Cryptic? (1)

abigor (540274) | more than 7 years ago | (#18101436)

Sadly, depending on people to behave well doesn't work, particularly in large projects. That's just life, I guess. Languages that enforce legibility (Python is great for that) lead to lower maintenance costs in the long run. And it's all about the bottom line.

Cryptic whitespace (3, Insightful)

myowntrueself (607117) | more than 7 years ago | (#18101652)

Languages that enforce legibility (Python is great for that)

A language which makes a semantic distinction between tabs and spaces may give the appearance of enforcing legibility but in fact does little useful to help legibility.

A programming language should not make a distinction on meaning based on whether tabs or spaces are used; all whitespace should be regarded equaly (except, understandably, end of line characters).

Otherwise, python seems ok. I just wish it had a whitespace-agnostic mode.

*I* cannot visualy tell the difference between tabs and spaces, why should the programming language?

Re:Cryptic whitespace (1, Flamebait)

abigor (540274) | more than 7 years ago | (#18101808)

No, the whitespace enforces legibility when you have a team of 20 people working on the same code. It makes reviews and maintainence go smoothly. The code looks the same. You might have a theoretical issue with it, but in practise it works well and gets working code out the door quickly, which is all that counts, period.

Re:Cryptic? (2, Insightful)

Prof.Phreak (584152) | more than 7 years ago | (#18101604)

Cryptic perl is a myth. It's only cryptic if you don't understand it (or if things aren't indented properly).

Whenever I come across code that just looks like `an explosion at an ascii factory', I first indent it (which usually fixes the readability). If that doesn't work, I try to figure out what it's trying to do (likely developer didn't know any better, and used some clunky code to do something trivial; usually code that can easily be `clarified' by replacing whole sections of it with a single regex).

Perl is surprisingly beautiful and easy to read language---you just have to know it well.

Re:Cryptic? (1)

qwijibo (101731) | more than 7 years ago | (#18101774)

I think the majority of problems people have with Perl is when they want to learn Perl but have no interest in regular expressions. A 30 line program with a few non-trivial regular expressions looks deceptively simple, but is performing the job of a program that would be several thousand lines of code without the regular expressions.

Based on my own experience, I think management frequently drives the impression that perl code is unmanageable. I have had several occurrences where proof of concept code (like used in the "so is this the kind of thing you're trying to do?" requirement development phase) is rolled out straight into production with known bugs, no documentation, and since the project is "done", there will never be any effort put into cleaning up the code, documenting anything, or letting anyone know what does and doesn't work. I'd like to work in an environment where projects are taken more than 10% towards completion and management delegates technical decisions to competant, technical people. However, in the really real world, things don't always work that way. And when some new manager saves several thousand dollars by firing the expensive programmer and replacing him with a college student who wrote "programer" on a resume, the student and everyone else gets the impression that the code is unmanageable because it was never left in a state where it was intended to be maintained. Of course, no one will point out the root cause of bad management, so blaming Perl sounds good, since everyone "knows" that perl code is cryptic and convoluted. =)

Arguably one of the greatest? (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#18101080)

One of the greatest? Please!

Smalltalk is a great language.
Haskell is a great language.
OCaml is a great language.

The best language (no arguments) is definitely Lisp and derivatives.

Where does PERL fit into this? It's for drudgery. To me, PERL is for boring jobs
that no one wants to do. The above languages are for *ACTUAL COMPUTING*. PERL is for
sysadmins and their ilk.

Re:Arguably one of the greatest? (1)

Goaway (82658) | more than 7 years ago | (#18101284)

Nice list of languages nobody uses there.

Awes0me fp (-1, Troll)

Anonymous Coward | more than 7 years ago | (#18101140)

NIGGER ASSOCIATION Chronic abuse of Are about 7000/5

Not hard to learn, very easy to remember (4, Insightful)

SCHecklerX (229973) | more than 7 years ago | (#18101170)

The only 'strange' thing with Perl is its use of symbols to denote things. That is not really that big of a deal, and in fact makes working with code a bit easier, IMO, since you know loosely what type a variable is just by looking at it and the context of the code that surrounds it.

The thing I've noticed, as a Perl programmer, is that it is the *only* language I've ever used (amongst bash, c, c++, java, rexx, fortran, basic) that I can take a break from for a year, come back, and be able to write a simple script without the need to refer to any books or online manuals. That is VERY useful for those of us who are more sysadmins than programmers. This power is partly due to the "more than one way to do it" philosophy, that lets you program in a style that works for you, hence allowing you to remember *how* to write in that language.

Then again, that's what most anti-Perl folks bitch about. Any language can be obfuscated. If you write hard to decipher code in Perl, you'll write it that way in any language.

Re:Not hard to learn, very easy to remember (1)

quintesse (654840) | more than 7 years ago | (#18101506)

"without the need to refer to any books or online manuals
That might be true for you, maybe you've got some kind of photographic memory but for me it's 100x times easier to come back to a language that just says Map things instead of trying to remember what kind of variable %things is exactly. (NB: Had to google for the % symbol, thought it was @ for maps actually, see?)

Not always cryptic (1)

ErGalvao (843384) | more than 7 years ago | (#18101188)

[...] it has a reputation for taking an excessive cryptic nature [...]
Actually this is a common mistake associated with Perl. The language can be as readable as PHP (believe me, Perl was my first language and I work with PHP since 2002), but it can become cryptic as well. It all depends on the coding style of the author.

Writing a Perl script is fairly easy. Modifying another programmer's Perl script can be tough.

Problem with perl is the users, not the language. (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#18101340)

Perl isn't cryptic or even difficult as a language itself. Borrowing from so many other unix
design patterns, it allows you to apply knowledge you've gained from one area of unix to other
areas. Furthermore, using perl will help you learn unix shell better.

This knowledge-bridge is what makes perl easy - you get to reapply the same skills between perl and the rest of unix. As Larry Wall is also a linguistics expert, I believe this was no
accident.

The two problems with perl are:

1.) The user base.

Perl people are the second most arrogant, anti-social people I've ever met. Ask someone a question and you'll likely get barked at, told what you are doing is stupid, degraded, etc..

The only crowd I've ever seen that can top perl in arrogance awards are the linux punks.

This is a serious problem. One that PHP doesn't have as much of. (and I dare say it's about
the only good thing going for PHP)

2.) Perl6

When Larry Wall announced perl6 at the convention (Yea, I was actually there) it was exciting, but lead to people feeling as though, perhaps, they had better not use perl anymore, better wait for perl6 to come out.

The language itself is easy. It's getting along with perl folks that can be difficult.

Rexx (1)

LeninZhiv (464864) | more than 7 years ago | (#18101452)

Perl was long my scripting language of choice until I discovered Rexx, which to me has a very similar feel and philosophy, but is much easier to retain the whole syntax of, and (the big winner) *much* easier to reread a month later.

Of course, Rexx is not an *it* language, but even Perl seems to be waning in favour of Python and Ruby, so I'll take the risk in bringing it up even if it isn't something we're 'supposed to be' excited about. As if a robust and mature scripting language were a bad thing...

Re:Rexx (1)

LMacG (118321) | more than 7 years ago | (#18101674)

Just out of curiousity, what environment are you using Rexx in? I wrote some pretty bitchin' REXX scripts on OS/2 back in the day.

Picking Up Perl (4, Informative)

nbritton (823086) | more than 7 years ago | (#18101550)

This: http://www.ebb.org/PickingUpPerl/pickingUpPerl.pdf [ebb.org] guide is awesome if you want to learn Perl. Concise and articulate, it manages to explain all the major topics of Perl in 66 pages. I recommend working through the entire guide as quick as possible, don't worry about remembering everything as you can always come back to it later. I also recommend having the O'Reilly camel books (Learning Perl, Programming Perl, Perl Cookbook) handy when going through the guide. You can read the books here: http://www.jimsannex.com/Studies/CD_perl/index.htm [jimsannex.com] but you better go out and buy the real thing, worth every penny!!! If your running Windows you'll need to download Perl and a good editor with syntax highlighting:

http://downloads.activestate.com/ActivePerl/Window s/5.8/ActivePerl-5.8.8.820-MSWin32-x86-274739.msi [activestate.com]
http://www.crimsoneditor.com/ [crimsoneditor.com]

After you install perl open a command prompt and run ppm, this is your simple GUI gateway to CPAN packages (make a mental note). After you get a handle on basic perl checkout Perl/Tk (GUI Toolkit for Perl). The Tk packages are included and installed with ActivePerl... Here's your first Perl/TK program:

use Tk;
my $top = new MainWindow;
$top->configure(-title=>"My First Perl GUI Program");
my $lab = $top->Label(-textvariable=>\$labelText);
my $b = $top->Button(-text=>'Click Me!', -command=>sub {$labelText="Congratulations! it worked!" });
$lab->grid(-row=>0, -column=>0);
$b->grid(-row=>1, -column=>0);
MainLoop;

Um... (0)

Anonymous Coward | more than 7 years ago | (#18101586)

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.

Isn't this line kind of contradictory? The "complex way of writing programs using Perl" is using "just one or two lines of Perl..."

Perl grepping is *slow* (1)

massysett (910130) | more than 7 years ago | (#18101766)

different grep commands such as grep, egrep and fgrep which clearly shows the advantages that Perl has over grep.

I wonder if the author listed a significant disadvantage of Perl: it is very slow [swtch.com] compared to awk and grep. For example: "Notice that Perl requires over sixty seconds to match a 29-character string. The other approach, [used by grep and awk], requires twenty microseconds to match the string. That's not a typo."

There's nothing like specialized Unix utilities, refined over thirty years with some GNU innovation thrown in, to deliver lightning fast speed.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>