Slashdot Mirror
Minimal Perl for Unix and Linux People
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.
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
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.
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.
Minimal Perl for Unix and Linux People? Is this the result of a perlgolf competition between perl-related books?
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
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.
Congratulations, AC, you've discovered that used books are cheaper than new ones.
(IANAL)
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.
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.
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!")
This message printed on 100% post-consumer recycled electrons.
Just use Python. It is a far superior language. Perl is for fags.
-- Larry Wall
That is all...
"None are more hopelessly enslaved than those who falsely believe they are free." -- Goethe
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.
Useful review.
I'm currently going through http://www.oreilly.com/catalog/sed2/, 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.
"You know you don't act like a scientist, you're more like a game show host." Dana Barret
gnucronyms are better:
= 30239&view=findpost&p=288814
Perl = Perl Extraction and Report Language
PHP = PHP Hyped Protocol
```
http://www.planetamd64.com/index.php?s=&showtopic
It's not considered one line if it has 3398EAFF23 characters.
#!/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
10 CurrentFile = Dir("*.pl") 20 Do while len(CurrentFile) > 0 30 Kill CurrentFile 40 CurrentFile = Dir() 50 Loop 60 End
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
Uhhh, yea you can purposefully make syntax cryptic in ANY language. Get back to me when you have a point.
Whoosh!
Really. Does C have $_ or any number of ridiculously implied $ nonsense in it?
Perl should have just stopped about 8 years ago.
#!/usr/bin/perl -w /home/me/file_to_be_removed");
##Oh boy I'm using an advanced scripting language!
system("/usr/local/bin/csh csh.script_1");
system("/bin/rm
system("/usr/local/bin/application & application_output ");
system("/usr/local/bin/csh csh.script_2");
#
system("/bin/cat "I know Perl" > resume.txt");
exit
You'd think Slashdot could get the quote right:
"All that is gold does not glitter, not all those who wander are lost."
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.
thegodmovie.com - watch it
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.
My bicyles
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.
www.wavefront-av.com
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!
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.
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.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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.
"You know you don't act like a scientist, you're more like a game show host." Dana Barret
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.
Writing a Perl script is fairly easy. Modifying another programmer's Perl script can be tough.
Er Galvão Abbott - IT Consultant and Developer
Nice list of languages nobody uses there.
How do you avoid using regular expressions? What do you replace them with? And how can they be confused with binary?
Stupidity is like nuclear power, it can be used for good or evil. And you don't want to get any on you.
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.
http://vil.nai.com/vil/content/v_130620.htm
I'd guess that it is one of the greatest languages in the same sense that McDonald's is one of the greatest restaurants.
-30-
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...
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.
My bicyles
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).
Cool. I'm going to go try python.
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 be considered a snackronym or a blackronym?
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
This: http://www.ebb.org/PickingUpPerl/pickingUpPerl.pdf 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 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:
w s/5.8/ActivePerl-5.8.8.820-MSWin32-x86-274739.msi
http://downloads.activestate.com/ActivePerl/Windo
http://www.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;
Perl could be the first language to bow out gracefully when it's day is done, but I'm not holding my breath...
"Not an actor, but he plays one on TV."
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..."
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...
Penny - plain text accounting
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.
--I'm so big, my sig has its own sig.
-- See?
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.
Mod me down and I will become more powerful than you can possibly imagine!
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?
In the free world the media isn't government run; the government is media run.
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
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.)
My bicyles
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...
I believe posters are recognized by their sig. So I made one.
His usage of "it's" is correct. It's = it is.
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 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.
Penny - plain text accounting
thanks for the links. downloading now. At my present job, there are no *nix boxes and I was getting homesick. Now I've got some shiny PERL for "Winders" to keep me warm.
I've been programming perl for 10 years. I've written enough XS modules to be sadly familiar with perlguts and perlapi. I've used perl for a huge array of applications, not excluding some pretty twisted apache hacks using mod_perl. I write perl code every day in my job.
Lately however, I've grown more and more frustrated with this language. Here's some reasons why:
muddled standard library While CPAN's depth has been a model for many programming languages to come after perl, it's anarchy kills me. The number of different CPAN modules to deal with time/date manipulation is silly. Newer languages have had the luxury of much more structured standard libraries that make much more sense as a whole. object oriented perl is a hack It may be possible that some very disciplined group of perl programmers have achieved that holy grail of pure OO perl in such a manner that the benefits of OO programming are available to them. In real life, most OO perl programmers are bombarded with example code, third party modules, and CPAN modules that are not OO. Because of this, most perl code falls back on it's procedural roots out of frustration. You can blame this on the programmers, but this doesn't happen nearly as much in Ruby or Python. lack of modern frameworks I'm still waiting for Rails or Django for perl. Catalyst is nice, but a bit disparate, and it just doesn't have the traction or the cohesion that the first-class frameworks do. It used to be that all the cool stuff was done in perl first (example: mod_perl). This isn't the case anymore. bindings for other languages are no longer hard to find It used to be that every cool project/library would only come with perl bindings. Stuff like mod_perl or perl-magick were all you got. These days, however, bindings for other languages are almost just as pervasive, and often better written. For example, the perl AGI bindings in Asterisk PBX aren't nearly as well done or supported as the bindings in other languages.I would argue that the majority of business people hiring programmers to work cannot tell the difference between a well designed solution and a horrible kludge. The horrible kludge will always take less time in the short term than the well designed solution. Business people have no long term memory and only acknowledge short term goals. A horrible kludge is a cost effective short term solution.
Therefore, one can reasonably conclude that in many environments, Perl is an ideal tool for the problem at hand. It can be used in ways that are not horribly short sighted, but it's flexible enough to still be useful in the situations that are.
Then again, my view of the world may be skewed by having spent too much time working for people who believe that russian roulette is the only viable way to make decisions. It's always worked in the past and the brain dead cannot be harmed by the game, so we don't do backups of our production databases. Our disaster recovery plan is to drive across town and get a job at a company that didn't have a disaster. I'm not kidding, we have senior VP level support (working in a bank) for this plan.
http://en.wikipedia.org/wiki/Minnie_Pearl
"Perl (Practical Extraction and Report Language) -- the language which was created by Larry Wall is arguably one of the greatest programming languages."
:)
Hmm, kinda like George W. Bush is arguably one of the greatest presidents.
Sorry, couldn't resist.
(yes I pre-ran them both multiple times to reduce cache affects)
:#]+/, $_); $c += $#t; } print "c == $#t\n";'
./ctok ../../tests/ctok.in.2 " :#"
[src] $ time perl -e '$tdata = "../../tests/ctok.in.2"; $sz = -s $tdata; print "sz == $sz\n"; open(FH, $tdata); while (<FH>) { @t=split(/[
sz == 96252007
c == 12301001
real 0m31.877s
user 0m31.662s
sys 0m0.148s
[src] $ file ctok
ctok: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, not stripped
[src] $ time
sz == 96252007
c == 12301001
real 0m2.417s
user 0m2.280s
sys 0m0.132s
And yet I still proudly use C. Let the prophets K&R reign supreme.
That's a pretty common way of implementing objects in perl, but it is, of course, not the only way... The current thinking seems to be we should all switch to using "Inside-Out Objects" (briefly: object data is moved to class data, and the object only needs to be a unique id to pick out the correct values from the class data -- so you bless a scalar ref, and get a lightweight object which stringifies to a unique id). The point being that if you do things this way, you really *have* to use the accessors, you can't cheat and treat the object as a hash reference any more. Unfortunately, last I looked there was some argument about what precisely was the right way to do this (there's some issue with thread support), though the best publicized way of doing it certainly the one recommended by Damien Conway in his newish book "Perl Best Practices".
If you're not interested in re-writing your entire code-base to conform to someone's notion of "Best Practices", myself I might suggest looking into "lock_keys" in the Hash::Util module. You could adopt the practice of doing a lock_keys on the hashref at the end of the object/creation initialization stage, and then if anyone accidentally tries to create a new hash field later, it will throw an error. A simple, effective trick, and I wish it were better publicized...
On occasion I wonder how hard it would be to write an automated test that would look for cases where someone has done a "$obj->{hash_field}"...
In general, coding standards are important, and where the language is really flexible, they arguably become even more important -- but I think a lot of that problem can be solved with some good automated testing. For example, there's a CPAN module called Perl::Critic that will do things for you like check to make sure your code matches a given set of coding standards (it defaults to Conway's "Best Practices", as I remember it).
I suspect this is due to your familiarity with the language. I find that this is true of C for me (though not C++). I have not stopped using Python since I first switched to it (from Perl) around two years ago, but I can't imagine I would have any trouble picking it up again immediately, should someone force me off it against my will.
My recent experience with having to pick up Perl again is that Perl programs I wrote only two or three years ago are extremely difficult to understand now - and I tend to comment heavily, and to use a C-like style to keep it familiar.
BTW it's not just Perl that I find hard to pick up after a break. Java's syntax I am fine with, but you always need the API open in a browser, and I find myself checking it even for basic things if I haven't done much Java in a while. Prolog is very hard to re-adjust to (probably the whole non-imperative thing), and all the intricacies of C++'s syntax and the STL seem to wind up with me spending at a lot of time with Google and various (cryptic) documentation.
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.You are right about the C of course, all programming languages have non-alphanumerics throughout them. I think what he meant though, is that Perl is kind of extreme in this regard. The requirement for prefixing every variable with $ or @ or %, which changes depending not only on the variable, but also what you are doing with it, and allowing multiple variables that differ only in this changeable symbol... it's just not great for consistency. The default operations on $_ and such can also be very hard to follow when you are not inside the original coders head. I think that Perl's regular expressions are very powerful, and are largely responsible for upgrades to the regular expression capabilities of other languages. However, I think the way they are such a core part of the syntax does hurt intelligibility of the code. I would prefer they were in an external module with decent object-oriented semantics, such as in Java or Python.
And I know it seems like I'm plugging Python, (there's no zealot like a convert) but the lack of this level of unpronounceable ascii art helps readability immensely. Python has been called executable pseudocode, and it isn't that far off sometimes.
If only Python didn't require the use of whitespace for defining blocks. It is indeed tragic that an otherwise fine language is so goddamn retarded in that one aspect.
== Jez ==
Do you miss Firefox? Try Pale Moon.
Another way to lock a set of keys that works at "compile" time rather than runtime (that is it works on the class and not the instance, is to use pseudohashes. This actually makes the code faster too. Effectively what it is doing is using an array rather than a hash and all the keys are like enums. But all that's hidden behind a layer of syntactic sugar so it looks just like a normal perl hash-based object.
Some drink at the fountain of knowledge. Others just gargle.
The problem I have with python (other than the lack of autovivication and CPAN) is that the whitespace can almost be thought of as non-portable metadata. The minute someone tries to paste a python code snippet into an online form, into an email, in a jabber session, etc. you start having problems. Have you ever had to unravel a few hundred lines of twice-quoted, emailed python? It can be a royal pain. Even if you have 20 people working out of the same SCC repository, you have to hope/require that they all use the same editor (or same editor settings). I've seen changes in wordwrapping and confusion over spaces/tabs cause problems.
Because there's nothing which lets you know where the logical blocks should be once the indenting has been fubar'ed, you have to enforce constraints on both use and handling. IMHO, those same use constraints applied to perl gives you a lot in terms of readability, and there are no real handling issues to deal with.
Having said that, I like python a lot. It's easy to learn, fun to program in, and the core gives you a lot of tools. Stuff like slicing strings like arrays is terribly handy as well. And the OO part is very clean and powerful and a joy to use compared to perl's (which I never really liked very much). Anyway, YMMW.
Disclaimer: I first started writing perl back in 1994, as my 3rd language (though it was the first I got paid to write). I write almost exclusively in python now.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
Not that I completely agree with the grand parent post, but who cares if they aren't main stream languages that are in extremely heavy use? PHP is a language lots of people use and it's a total piece of shit. Sure, Haskell, OCaml, Lisp etc. might not be used for writing the majority of simplistic CRUD web applications, but all of the languages the grand parent mentioned are seeing use in some of the more interesting areas of programming. For example, lots of the really interesting AI research right now is being done with Lisp. Personally, I'd rather be doing stuff like that instead of pumping out basic CRUD web applications with the "main stream" languages (Java, C#, PHP etc.) like the majority of programmers are currently doing.
P.S. I use Haskell at work daily and it's quite nice.
"A Lisp programmer knows the value of everything, but the cost of nothing." - Alan Perlis
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.
Yeah, pretty much the same story here, though I was never as professionaly invested in Perl. Loved it though, and still use it for one-off command line things. Pretty much any time I had to write or deal with someone else's Perl program that was more than 1000 lines, it simply became unmanageable too fast. I could leave a 100k line C program for a couple months, and at least be able to pick it back up quickly. A mere 10k Perl program was basically unreadable to me after a long weekend. Then finally I was given an opportunity to learn Python for a project at work, the purpose of which was to re-write an old Perl program that we wanted to add features to but nobody understood anymore. Hooray for getting paid to enhance my resume! But anyway...
I now love Python. It's great. Got some quirks, but generally makes sense, and I also like how easy it makes working with arrays, creating arrays on the fly, splicing arrays, and so on. Highly recommend it to anyone who has ever said "I like Perl, I just wish I could read it after a bender".
However there is one thing I don't like about Python. And it's the first thing anyone coming to Python first says "Whaaaaa?!" to. Which is: indentation defines blocks.
Now don't get me wrong, it's not so much the enforced importance of indentation. I always religiously indent my C code, and nothing is more obnoxious than finding half a dozen closing braces all at the same level of indentation. It's the absence of block-enclosing characters that I don't like. Block enclosing characters make it simple -- for humans and for machines -- to determine where a block begins and ends. With C, if I want to move a block of code I simply cut/paste it, hit my re-indent macro, and bam I'm done. With Python, I have to manually indent the block after I paste it, because for my macro to figure out what the new indention should be it also needs to know what the intended semantic meaning of the code is, because it would basically be deciding where the blocks begin and end. C explicitly encodes this information, so my macro doesn't have to figure anything out. Adding/removing a nested 'if' is a similarly annoying case.
Basically, all I want is Python with curly braces. You can even make the interpreter barf if my indentation doesn't match what my braces claim the blocks are.
Also I should say that this is a fairly minor issue, and shouldn't be a reason to avoid Python.
The enemies of Democracy are
Subject says it all - tcl has the best unicode support you'll find in a scripting language. Python? Sorry, nice try, tcl has it beat.
Tcl is also sophisticated enough to support numerous programming paradigms with ease, but its complete syntax is just eleven rules long. Add to that the astoundingly helpful wiki and a powerful cross-platform GUI toolkit and you won't often need to turn to other languages for your programming needs.
Luckily, everyone else has gotten over their obsession with curly braces. If only you could get over yours...
Where are the third-party tcl libs?
Thanks from me for the links too. No more Notepad for Perl scripts. I always suspected that there was a good editor out there (and some snappier doco). Downloading now...
"The greatest lesson in life is to know that even fools are right sometimes" - Winston Churchill
What's wrong with it? I have only written a few thousand lines of Python, but I quite like the indentation-based block structure. I thought it might be error-prone, but I've never experienced any trouble with it. What do you dislike about it?
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Indeed, this is the only thing I mind about indentation in Python: it makes it hard to cut-and-paste code. Fortunately, Emacs has rectangle mode which I find very helpful in indenting a bunch of lines together all at once (C-x t SPACE SPACE SPACE SPACE ENTER to move them all 4 spaces forward, for example).
It's also hard to take Python code from web forums, since the indentation often gets lost in HTML, and you have to View Source to get them.
But I agree that it's a minor issue too, and in all other circumstances I have grown to enjoy the lack of curly braces.
My bicyles
it's so easy to right totally unmaintainable, totally unreadable code.
Spoken like a true perl haXX0rz
what about the several thousands of lines of lisp code on my PC and on the PC of everybody who uses emacs?
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.
My bicyles
Fortunately, Emacs has rectangle mode which I find very helpful in indenting a bunch of lines together all at once (C-x t SPACE SPACE SPACE SPACE ENTER to move them all 4 spaces forward, for example).
Do you know the function name? It isn't mapped to C-x t in my emacs. If there was a way to de-indent (backspace instead?) that would probably solve most of my issues.
The enemies of Democracy are
If I'm well skilled in BASH plus sed and awk, what does perl buy me?
Ever done a `man` on `top` ?
Similarly, the C-x r k command will delete an entire rectangle of spaces. I use that frequently to de-indent whole regions of code. Hope that helps.
My bicyles
Hmm, that seems a round-about way to do things. I presume you never happened to run into some of the nice features in Emacs python-mode, specifically python-shift-left and python-shift-right which will move the selected region left or right one python indent (that is, as many spaces as you have set for your block indentation in python-mode). Usually these are bound to "C-c <" and "C-c >" which lets you easily select a region (such as a pasted block) and move it to the correct indent level very quickly.
Craft Beer Programming T-shirts
You know, it seems like *everyone* is put off by this aspect of Python at first. The first time I looked at it, it drove me nuts, and then I ignored Python for another two years.
But once I actually tried to write a program in Python, I found I didn't mind it one bit. Within a few hours my eyes didn't get confused by the lack of braces. I think it's actually easier on the eyes once you get used to it.
So I can't say, "don't knock it", because I've done that myself for sure. But do give Python another look, maybe play around with the tutorial for an hour or two.
My bicyles
Wow! That does the trick nicely. Thank you very much, that makes things even easier. And who says you'll never learn anything on slashdot?
My bicyles
It doesn't "delete" the entire rectangle, it cuts it to the rectangle kill ring. You can get it back with C-x r y. I love rectangle editing in Emacs!
Hope that helps.
Sure does! Thank you.
The enemies of Democracy are
My problem is some libraries I started getting into either didn't have python equivalents or the python equivalents were inconsistent. I'm trying to write software that will work with the greatest variety of distributions, and across the board the perl module variants are widely available and consistent. In python, some things aren't quite there, and some important modules have subtly different syntax between the distributions I need to support, all of which deviate from what you would download from upstream python world today. For 1 out of 5 lines of code in a particular python module I was writing, I was having to write the same thing three times in slightly different ways depending on the detecting version of the library. Didn't last long before I ditched that and ran to perl for this project despite my longstanding python experence.
I moved *to* perl from being an entirely python guy (started into perl and was 'ok' at it, but went to python for the same reasons a *lot* of people do). Python code is easy to write, but more importantly, *forces* writers to write code that is maintainable by others. Well, obfuscated python is possible, but with perl it's easy to casually fall into writing obfuscated code...
A lot of the perl culture doesn't help. If someone posts code to do something that is fairly reasonable, they may be mocked by another developer for not doing it in this hard to read/follow one liner they declare is 100% better because it fits on one line without a ; and uses no explicit variables...
I do have to acknowledge that perl doesn't *have* to look funky, most of the time you can make it fairly readable. Writing OO stuff is kinda weird as it feels like syntax that just happened to work really intended for cleanly packaging their version of include files. Variable referncing/dereferencing isn't all that different from C, but the function prototypes invite aggravation (values can be forced to be by reference without the caller realizing it, for example).
For my part, I try to write sane/legible perl. I try to be careful about indentions, I avoid almost entirely the likes of $_ and similarly invisible evocations of it which become hard to follow in all but the shortest loops, and when faced with anything but the simplest usage of it, I avoid using features of perl like map that tend to confuse people, and use more long-winded, but easier to follow conventions to get the job done.
XML is like violence. If it doesn't solve the problem, use more.
What do you dislike about it?
The two things that come to mind:
1) You can't put more than 1 statement on the same line as an 'if' or 'else'. "if (increment_them) {a++; b++;}" won't fly. Some people might think that's good, I think it's limiting.
2) Mixing spaces and tabs for indentation is a MAJOR no-no. If my text editor has tabsize 4, and somebody used 4 spaces to indent one block, if I try and indent the next block down with 2 tabs (8 spaces on my text editor), what does Python do? Someone else's text editor might display tabs as 2 spaces. Sure, you can try and mandate that everyone use tabs or spaces for indentation, but it's just a potential headache that wouldn't be there if Python weren't so stupid.
== Jez ==
Do you miss Firefox? Try Pale Moon.
Sure, C has a huge space of implied variables. You can read from any memory location, and cast it to any type. It's completely ridiculous, much worse than Perl.
How-DEEEE!
That's because it's just complex and hard to master, and not really all that great.
Edith Keeler Must Die
It's completely obvious what's going on just by reading the code.
If a programmer just randomly reads x memory location and casts it to y for apparently no reason whatsoever, then that's just stupid code and a bad example.
How do you avoid using regular expressions?
Well most languages have these things called functions, you can use them to do your own string functions. Other Languages have a bunch of well performing string functions so I don't need to program them myself. Other languages have different Datatypes like Lists which I can convert a string to and do a lot of calculations based on these data types. While they may not be as efficient as Regular Expressions they are better in readability for programmers in different skill sets.
Well Binary Information In languages such as C you use the \char for a lot of characters that are beyond the normal keyboard typing. so if you have a bunch of them they really do look similar to an other language asking for characters beyond normal typing. Now these characters are often handled in 8 bit ASCII so if you need to handle data in the binary level you may use these characters to handle the sequences. even if you are dealing with Hex information you still use a syntax similar to Regular Expressions. No this is not really binary in the sense that I am handling the 1 and 0 independently. But in technical terms we often data Binary Data for Data that is beyond your keyboard typing. As opposed to say Text Data which is data you can type on a normal keyboard.
If you were any type of professional level programmer you would know this. Yes I Can program Regular Expressions in my code, I don't like them because it makes code ugly. Guess what there are other ways of writing code and there are good reasons for writing code differently.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
My most sincere condolences to you and your fellows in your suffering.
Now, I agree entirely that being popular is nowhere near reason enough to be called great, and indeed PHP is a festering boil upon the internet, but I'd also argue that in order to be called "one of the greatest programming languages", a language really needs to be in actual use by a significant number of people.
Hope that helps.
XML causes global warming.
suffering? emacs is an awesome piece of software and LISP is a great language to program in. Where is the suffering?
Obviously a ridiculous position. Basically the only way I can make sense of your paragraph is to assume you're holding onto the hope that "everyone you've ever met including yourself" isn't a representative sample. Seriously, WTF.
The standard solution is to not use tabs, which I agree is a pain in the arse in some ways and at best a hacky way of solving the problem, but it seems to work just fine. It's even in the official python best practices that tabs are a no no.
How to use coral cache: http://slashdot.org.nyud.net:8090/~oscartheduck
That code really is indecipherable. Here is something a little more straightforward:
/,"m _".chr(72)." c 2". /,shift)){(K,L)=split(/=/,K .(30+M));print " "x2}}}a( ;W=J[C];H=I[C];X=int(A/2)-1
#!/usr/bin/perl
$_='A=15; B=30; select(stdin); $|=1; select(stdout);$|=1; system
"stty -echo -icanon eol \001"; for C(split(/\s/,"010.010.010.010
77.77 022.020.020 330.030.030 440.044.000 055.550.000 666.060.".
"000")){D=0;for E(split(/\./,C)){F=0;for G(split("",E)){C[P][F++
][D]=G} D++}J[P]=F; I[P++] =D}%L=split(/
chr(74)." a _m");sub a{for K(split(/
);K=L{K};K=~s/_/L/; printf "%c[K",27}}sub u{a("a=40");for D(0..B
-1){for F(0..A-1){M=G[F][D];if(R[F][D]!=M) {R[F][D]=M;a("m"."=".
(5+D).";".(F*2+5)); a("a=".(40+M).";"
"m=0;0 a=37;40")}sub r{(N)=@_;while(N--) {Q=W;W=O=H;H=Q;for F( 0
..Q-1){for D(0..O-1) {Q[F][D]=K[F][D]}}for F(0..O-1){for D(0..Q-
1){K[F][D]= Q[Q-D-1][F]}}}}sub l{for F(0..W-1){for D(0..H-1){(K[
F][D]&& ((G[X+F][Y+D])|| (X+F<0)||(X+F>=A)|| (Y+D>=B)))&& return
0}}1}sub p{for F(0..W-1){for D(0..H-1){(K[F][D]>0)&&(G[X+F][Y+D]
=K[F][D]) }}1}sub o{for F(0..W-1){for D(0..H-1){(K[F][D]>0)&&(G[
X+F][ Y+D]=0)}}}sub n{C=int(rand(P))
;Y=0;for F(0..W-1){for D(0..H-1){K[F][D]= C[C][F][D]}}r(int(rand
(4)));l&&p}sub c{d:for(D=B;D>=0;D--){for F(0..A-1){G[F][D]||next
d}for(D2=D;D2>=0; D2--){for F(0..A-1){G[F][D2]= (D2>1)?G[F][D2-1
]:0; }}u;}}a ("m=0;0 a=0;37;40 c");print "\n\n".4x" "." "x(A-4).
"perltris\n".(" "x4)."--"xA."\n".((" "x3)."|"." "x(A*2)."|\n")xB
.(" "x4). "--"xA."\n";n;for(;;) {u;R=chr(1); (S,T)=select(R,U,V,
0.01);if(S) {Z=getc;}else {if($e++>20){Z=" ";$e=0;}else{next;} }
if(Z eq "k"){o;r(1);l||r(3);p}; if(Z eq "j"){o;X--;l||X++;p}; if
(Z eq "l"){o;X++;l||X--;p};if(Z eq " "){o;Y++;(E=l)||Y--;p;E|| c
|c|c|c|c|n||goto g;};if(Z eq "q"){last;}}g: a("a=0 m=".(B+8).";0
" ); system "stty sane"; '; s/([A-Z])/\$$1/g; s/\%\$/\%/g; eval;
Amen! It's amazing to me the number of people who don't understand this. TIMTOWTDI is the worst aspect of Perl. Well, maybe not the very worst. I'd give that to the OO extensions (and I'm a long-time C++ fan).
TIMTOWTDI pretty much guarantees that no one else will be able to understand your code. It's great for being "clever" and for stroking your ego by impressing your friends with your one-liners, but that won't fly in software that has to be maintained.
Perl is fantastic for what it was originally intended to do: process text. Perl's use of regular expressions is right on. Perl was never meant to be used as a database, for large applications or anything beyond quick & dirty tools.
I use Perl a lot to process reports and create tables for spreadsheets and graphing programs. It works great for that kind of thing. But I would never use it in a large and complex project.
Yes, when writing python tabs are officially evil. However, if you are using a text editor that can't be taught to replace tabs with the correct number of spaces, then I would suggest that you look into using something other than notepad.exe to code in. Seriously, I can't think of a single software project of any size (in any language) that doesn't have coding standards designed to regulate the use of whitespace. With Python the language itself takes care of the biggest issue when it comes to code formatting. In return you simply have to give up the use of tabs. Fortunately, any modern Python editing environment can be taught to "do the right thing."
I recently inherited a project (written in Perl) where the person that wrote the original code didn't believe in indenting (I only wish I was kidding). As far as I am concerned white space is definitely significant.
Strange, because I only know of one way to supply named parameters to a call, an anonymous hash. OK, to be fair, there may be more, but none of them are reasonable, and as such, that's really the only employed method you see with CPAN^H^H^H^H those 10,000+ modules.
As for object syntax, your example of
sub new() {
my ($class) = @_;
my $self = {}
return bless $self, $class
}
is a little silly. Almost perfect (IMHO), but the first line makes it so (where's the my $class = shift;? By definition, the first argument to a call of Foo->new() is the class. Yes, it's Perl so there's More Than One Way To Do It(TM), but if someone can't write code that is reasonably congruent with the definitions set forth by said language, by all means, don't blame the language. Going back to the named parameter passing qualm you had, I'm sure I could certainly say the same thing about C by insisting that in my code, all parameters would be passed via a two-dimensional array, with a pointer to the parameter in the first dimension, and the value in the second; but that would just be silly, and everyone would laugh at the code (and not use it) when I posted it to CCAN ;-P
You also have to jump through hoops to just copy and paste the body of a function, or to copy a method of a class and paste it into the interpreter as a function. All the leading indentation screws it up. (yes I know about block select, but it isn't everywhere (like say the web, and no, I'm not going to load some crazy extension just for that)
--
WHO ATE MY BREAKFAST PANTS?
> What do you dislike about it?
My biggest issue is that i can take a perfectly working piece of code and open and save in my text editor, and depending on if my editor handles tab/hard tab differently than yours does, break working code. From the many people at my work who use python and love it, this seems more theoretical than actually encountered in practice, but is a real risk.
I think it's irrelevant. I do that sometimes, but I've never seen a situation where I felt it was crucial for clarity. It provides a bit of vertical whitespace compresssion, that's all.
2) Mixing spaces and tabs for indentation is a MAJOR no-no. If my text editor has tabsize 4, and somebody used 4 spaces to indent one block, if I try and indent the next block down with 2 tabs (8 spaces on my text editor), what does Python do? Someone else's text editor might display tabs as 2 spaces. Sure, you can try and mandate that everyone use tabs or spaces for indentation, but it's just a potential headache that wouldn't be there if Python weren't so stupid.In theory, that's a problem. In practice, it doesn't seem to cause any trouble. Perhaps that's because most people use Python-aware editors that either don't mix tabs and spaces, or do it consistently so that there is no possibility for ambiguity? I'm not sure why it isn't a problem, but it doesn't seem to be a real issue. What I do know is that this complaint is common among programmers who haven't written much Python, but those who have actually used the language a significant amount shrug it off as not a real issue.
I think it's similar to the people who insist that C/C++/Java conditional or looping statements that have a single-statement block should always have open/close braces, even though they're unnecessary. They argue that it's obvious that without the braces some programmer will come along later and add statements to the "block" without adding the needed braces.
In practice, I've been writing single-statement "blocks" without braces for nearly 20 years now, and always allowed my teams to do the same, and I've only seen the problem a bare handful of times -- far too few to be worth the effort of all those extra braces.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
I suspect the reason it doesn't happen much is because people use Python-aware text editors that keep the tab/space mix sane (which usually means "don't mix them"). Whatever the reason, it does seem to be a theoretical risk rather than one that actually causes problems. That being the case, is it really a reason to avoid Python?
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
I seem to recall that CGI.pm uses argument lists where positional and named parameters can be arbitrarily mixed, but the positional params always start with a dash. It's nice... but it's naturally Slightly Different From Every Other Way To Do It.
My bicyles
Really? Care to apply that concept to this or this?
Read better. I qualified the point where perl is useful. I'll elaborate anyway.
Unlike heroin and a defective lighter, perl is useful to me and to other developers for throw away code (i.e. stuff you're only going to use once), for small projects, and for heavily QAed coding.
Any of these approaches do a good job of guaranteeing that you won't have any problems with sloppiness.
I would go so far as to saying that in the first two cases - small projects and throw away code are both very good places to use perl. You get your results much faster than if you have to fit things into another language.
Perl makes a very good shell language. It's also good as a configuration language and a text transformation language, specifically because all of these jobs are small and often throw-away.
These are just a few things that I can think of off of the top of my head.
Mod me down and I will become more powerful than you can possibly imagine!
>>> if True: a = 0; b = 1; c = 2; print a, b, c
0 1 2
>>>
Opportunity knocks. Karma hunts you down.
Yes - because everyone normally writes production C code as an obfuscation contest?
Lame example. If anything perl heads much more in that direction with less effort than C does.
You did not restrict that claim to production code.
How does the obviousness of production code differ between C and Perl?
>In perl, you can change the nature of the language itself. *Everything* can be changed.
This means, that existing condition can not satisfy. But we all waiting for that changes: Parrot with Perl 6. While it is in "hard progress", we use Python.
> Perl's "TMTWWTDI" actually DOES keep it simple.
:-)
Oh well...
I'd like to see how "simple" you will work with a structures, kind
of "hash of hashes of arrays of arrays of hashes" and then compare
two or more structures for differences. I also want to see the code
and perfomance how it works.
In Python I do simply: if a == b: (it's that simple, huh?) and it *is*
comparable as it is, but what to do in Perl?..
If I need very complex structures, I just simply build a class,
define __cmp__ method and it is. For example:
>>> class A:
... x = None
... def __cmp__(self, i):
... return self.x == i
...
>>> a = A()
>>> b = A()
>>> a == b
True
>>> a.x = 1
>>> b.x = 2
>>> a == b
False
Any examples to make this in Perl as simple as it is?
* * *
BTW, how to catch exceptions in Perl? How to catch custom exceptions?
I don't need "to die" in my script, but just skip an error, spitting on STDERR
the result of an exception.
Any help from Perl guru?
P.S. To make Perl source code smaller: use gzip. Readability will not suffer...
You're strawmaning this into stupidity territory now.
It is implied that it's production code not toy obfuscated code. There's no reason to play stupid about that.
Now reanalyze your last statement and consider it's circularity.
Count me in with the people who tossed the Python book out of the window as soon as I read that line.
Years ago, there was an old-chestnut "funny" doing the rounds about how Thompson & Richie made up the UNIX operating system as a joke - one of the bits of "evidence" there was that makefiles used whitespaces to deliniate blocks. Hmm.
Trouble is, anybody who has used the broad C/Java genre of languages (of which even Perl is a peripheral member) - or HTML/XML for that matter - is used to mentally "collapsing" any combination of spaces, newlines and tabs. Heck, using spaces for indentation is even bad practice in a wordprocessor.
I can see that a nicely indented Python program would be perfectly readable provided you always edited it in the same text editor, preferably a nice language-aware IDE, with the same tab and indentation settings. Then you change IDEs, or make a quick "in the field" patch in a different editor, set to use hard tabs or with the "indent" setting different from the "tab" setting and you've suddenly broken the code. I'm sure many people have wasted ages faffing about with indentation styles to pretty up their code - now imagine you had to do that to get the program to run!
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
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?
Escher was the first MC and Giger invented the HR department.
Indeed. I wrote an article about some of the issues with perl. link
meh
Let perl rest in peace. We've had more modern evolutionary solutions for years now. Go to http://www.ruby-lang.org/ for more information
You can't blame the language for giving you that freedom, though.
Rubbish. Perl is completely to blame for giving you the freedom. The programmers are to blame for what you do with that freedom, but perl is to blame for creating the freedom. Perl is bears significant responsibility for a lot of hideous code.
meh
I can't comment on how mature Ruby is, but I do remember it having some of the same Perl-like attributes that made me search for a Perl replacement in the first place.
*sigh* back to work...
... is Perl 4. Object Oriented structures did not go easily into the language.
People who disagree with you are not automatically evil, greedy, or stupid.
GP asked if Perl was more confusing that other languages. Parent gave a concrete example and was modded troll. WTF? He was even nice about it!
It sounds like you're talking about Lisp, not the Perl I know, with all that changing everything talk. I still haven't seen how to programmatically modify Perl code, extend Perl's syntax, etc., but to a Lisper, that's all daily routine. Molding the language to fit your purpose is very good Lisp advice.
"Perl is fantastic for what it was originally intended to do: process text. Perl's use of regular expressions is right on. Perl was never meant to be used as a database, for large applications or anything beyond quick & dirty tools.
I use Perl a lot to process reports and create tables for spreadsheets and graphing programs. It works great for that kind of thing. But I would never use it in a large and complex project."
Right... *sigh*
I keep on hearing about people who would never use it for large and complex projects - that's probably because they've never worked on large and complex projects in any language.
Large and complex projects incurr complexity by their nature, that means regardless of the language you need to :
* carefully model the problem domain
* ensure that the code communicates what it is doing (IME Perl is far easier to read than C#, C, C++ and Java, and certainly as easy to read if you know Perl, as Python is if you know Python)
* ensure that API's are consistent and clear
* ensure that the software is composed in a way that allows unit and regression testing
* ensure that developer and user documentation matches behaviour and the tests.
* scales vertically and horizontally
* manage version control, requirement changes, etc
That's a lot of work, but I don't see how Perl makes any of that hard - in fact, Perl's standards of packaging, inline documentation, and unit testing helps a great deal, as does the abundance of high quality CPAN modules and reference material (both online and dead trees), and Perl's very experienced community, that provides proven and scalable software solutions like memcached and mod_perl, as well as battle-proven advice and wisdom.
Aaron Trevena
And that's nice, but Perl has 10,000+ available modules to do everything from screen-scrape Google news to access Oracle databases
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.
Python has more modules than perl? I use perl for the same reason I use debian. No matter what I want to do there's already a package to do it. It's the availablity of apps that makes an OS, and it's the availability of modules that makes a programming language. I have nothing against python, but until I can reasonably expect that there is a python module available for any given task I'll stick with perl.
Give me Classic Slashdot or give me death!
Yay! Let's reinvent the wheel by writing 10, 20, or more lines of code for something regular expressions would be able to handle in one. Furthermore, let's claim this is done for the sake of keeping the code 'pretty,' because it's far too embarrassing to admit that we don't really understand how to use regular expressions!
Hmm, like string functions that allow the use of regular expressions to make your string manipulation quick, efficient, and useful?
Yes, regex can be an odd concept to deal with at first, as they tend to be quite a bit more succinct than the languages you're more familiar with. Are you aware, however, that regular expressions can contain comments and extra whitespace?
Maybe you're paid by the line of code, or am attempting to squeeze in every extraneous hour of programming to inflate your consultant fee. If that's the case, I would certainly recommend avoiding regular expressions; they save far too much time and work entirely too well.
LegendMUD
I'm learning Ruby now, after programming in Perl for a majority of my time in the last 10 years or so. Ruby is very Perl-ish at times, but the OO stuff is a lot cleaner and easier to learn. I'm enjoying it. It's the first OO language I've felt comfortable in.
Ruby is the next perl. It is now what Perl 6 cannot be.
Soon, it will be just as fast.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
It amuses me that any criticism of Perl in this story gets buried to -1 by the mods. Yay discussion.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
I didn't say that! Perl definitely has more modules, CPAN is *huge*. Though Python includes more functionately, in a more polished and coherent form, in its standard library (everything from regular expressions to a complete standards-compliant subclass-able HTTP server with CGI support).
I don't disagree... if I need to do something obscure, there are better chances of finding a Perl module than a Python module. But frankly, I haven't run into more than one or two such cases in nearly a year of using Python heavily now. I've found that when there *are* comparable modules, the Python one is typically easier to build and use (for example the Perl GPIB module vs PyVISA was a recent one, where Perl GPIB was a serious nightmare to get installed on Cygwin, while PyVISA Just Worked).
The only thing I can think of where I couldn't find a python module, was when I needed to read Intel HEX files (a fairly trivial file format). It only took me a few minutes to write such a thing in Python.
My bicyles
I'm currently working on a project that uses Gene Ontology data. As far as I know go-perl is the only module available for any language that handles this. Not that that means anything, it's just another example.
Give me Classic Slashdot or give me death!
Sorry , but Tcl is a joke language , always has been. If it hadn't been for Tk it would have disappeared into the Where Are They Now? catagory of forgotten programming languages ages ago. Its syntax is unclear, inflexible and kludgy, the interpreters frequently had memory leaks and were unstable and its slow to boot.
Tcl is a useful scripting language if you want to knock up a quick GUI app that doesn't really have to do very much very quickly - its useless for anything else.
Try Ruby.
Python fans say that the obnoxious whitespace handling of Python is a minor thing to have to put up with, but with Ruby around I don't have to put up with it. Or the ugly __underscores.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Wow! That does the trick nicely. Thank you very much, that makes things even easier. And who says you'll never learn anything on slashdot?
:)
Heh, which was exactly why I brought the issue up. I was hoping someone would reply "You fuckin retard [cus this is the internet -ed], all you have to do is use this emacs lisp file blah-blah-blah" and fix it for me.
The enemies of Democracy are
I learned Perl back before Ruby was usable.
I wouldn't bother to learn Perl now.
I've been watching Ruby for a number of years, and I like it alot. But the current version of the runtime is just too slow for large data processing jobs. Perl is pretty darn fast for what it is.
The 2.0 line of Ruby looks like it will be usable for these tasks, so I eagerly await it. I think running perl5, perl6, and ruby (hey, python too) on the same runtime will be even better since I can share modules.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
The problem with it is not readability, it's peripheral things like the way it interacts poorly with merge/source control tools (many of which are designed to ignore whitespace), and with poorly configured editors (which will sometimes insert hard tabs instead of whitespace and cause an error). I mean, it's not a big deal either way but it does cause a few problems sometimes.
Python fans say that the obnoxious whitespace handling of Python is a minor thing to have to put up with, but with Ruby around I don't have to put up with it. Or the ugly __underscores.
;)
If I can get my employer to let me learn Ruby on company time, I'd absolutely love to. Maybe next time a scripting project comes up, I can convince my boss that Python is old and tired, and Ruby is the new hotness.
What do you mean __ugly __underscores__? Personally I like it, because it's an easy visual clue that the code is dinking with the internal magic of python objects.
The enemies of Democracy are
Slashcode ate the spaceship operator! I'll try again with HTML entities:
my @sorted_people = sort { $a{age} <=> $b{age} } @people;
To understand this you need to know two things: the sort operator takes an optional function, which defines $a and $b as the two objects to compare and that perl has a special operator <=> (the SpaceShip operator) which is a trinary result operator that meshes really nicely with sort.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
I meant double underscores on things which *aren't* messing with the magic of internal Python objects. Like __new__ and __init__ and __private_variables.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
I always love this comment. Are you saying you want to be free to code with no indentation if you wish? Go right ahead, but don't do it in Python. At least when I look at a Python program I don't have to worry that I'm being deceived by indentation that makes it LOOK like the code does one thing, and braces that CAUSE it to do something else.
Haven't you ever heard of the problems of double-dimensioning? In the case of braced, loosely-indented language, the indentation is a pathetic surrogate of the true control operators -- the braces themselves. When these two things get out of sync with each other, the problems can be severe. Similar problems arise when somebody changes a piece of code, but fails to update the comment which explains that code. Somebody looking at this code in the future now has to guess: is the comment wrong, or is the code wrong?
Python, on the other hand, forces the indentation to match the intended control structure of the program. It removes the conceptual double-dimensioning and makes code much easier to read.
So really it must come down to laziness on your part. You don't WANT to get the indentation right. This is a ridiculous gripe in a world with a zillion programming editors which will handle the indentation for you.
Maybe if you are forced to indent properly you'll find yourself spending less time lost in your own control flows.
- Tim Maher, TeachMePerl.com & MinimalPerl.com
Agree.
Lua and javascript rules!
I use vertical whitespace to delineate more than just blocks. Unfortunately, Python offers no visual way to distinguish between my various uses of vertical whitespace.
how to invest, a novice's guide
Okay, I haven't used private variables enough to care, but the __init__ stuff falls into the same category for me as 'internal magic'. __init__ is a special function that gets called automatically. Writing your own __init__ or __new__ or __str__ has meaning in other contexts that you need to be aware of. The underscores, well, underscore this special behavior.
Double leading and trailing underscores is a bit excessive though.
The enemies of Democracy are
"But Perl 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"
Mmm, the bad Perl reputation is not especially among novices: at my beginning in Perl, I thought that it was a better, more powerful shell, and then I discovered Perl's maintenance hell and the more I used Perl, the more I disliked it.
Thank God for Ruby, it's funny it occupies exactly the same niche than Perl, but it's so different.. Ruby's creator has a 'really good aesthetic sense' and now that (at last) RoR is helping the Ruby language to spread, it has a chance to be used more often.
This is utterly juvenile...
:-P
But the biggest thing that turns me off from Ruby is the fact that the "print string" command is called "puts". It's also a Yiddish slang term for "penis", "idiot", or "fooling around".
Somehow I just can't take Ruby code seriously
My bicyles
Writing initialization and allocation methods is a standard part of OO programming. It's not special internal magic.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
if (increment_them) {a++; b++;}
anything that prevent such abominations is a good thing.
IANAL but write like a drunk one.
Because perl is not UNIX.
UNIX came first, perl was added later.
As an experienced System Administrator I still have to find a task that *requires* perl.
IANAL but write like a drunk one.
Perl is bent on been unreadable.
You want to do a quick and dirty script to solve some small problem, perl will do, but then revisit the same script some time later and I am telling you, you will not know what you were thinking or why did you use a certain perl idiom that may have seen brilliant while coding in a hurry.
Perl has its place. Somewhere. I don't know where, but somewhere.
But in scripting there are many options that keep things simpler. Very often using the traditional UNIX pipes clarifies immensily a problem (because you have to digest the different parts of it) while perl my cloudy it in an unmantainable brilliant code snippet.
IANAL but write like a drunk one.
Not exactly, but they -are- functions that are handled specially, rather than functions that are only called directly at the programmer's behest (or through a function reference explicitly initialized by the programmer). Constructors and allocators have special syntax in the C++ and Java; having them be identified as 'different' in python makes sense as well. You rarely explicitly call someobject.__init__() because it is called automatically. Ergo special syntax. It's consistant and it works and I like it.
The enemies of Democracy are
My first experience with Python was being asked to debug someone else's code and finding a dangling if. I thought "How could such a recent language allow this?" It took me way to look to find the answer via Google. Not a big deal, but gave me a bad first impression.
You obviously do not know what you are talking about. Tcl is one of the most flexible languages out there. The incorrect facts you are spewing tell me that you haven't even looked at it in years. The 8.X series is fast and stable. The code for Tcl itself gets praises from anyone who has ever looked at it. Tcl 8.5 is going to have an OO core so that the current OO frameworks (Snit, XOTcl, etc.) have even better access to the Tcl internals. Tk itself is going through a revision that will add native look and feel to Tk anywhere Tk runs. i18n? Tcl has it and has it right. Threads? Tcl has had them and has them right. You can use Tcl for *anything* that you use the other dynamic languages for period. Does Tcl have its own warts? Yes, but so do all the others. I have to say also that the Tcl community is the most friendly of ALL the major ones I have watched and/or been involved with.
You are in the same league as those who spew the same crap against Perl thinking Perl is still in its 4.X days.
So please, pull your head out of the past.
Perl has the DBI...it is awesome. Perl has the CPAN...it is awesome. Perl has great web frameworks at all levels. When I need to get stuff done I fall back to Perl because Python and Ruby just don't have it. Want to pull data out of a DB and put it into an Excel spreadsheet? Spreadsheet::WriteExcel + DBI + DB rocks! The other languages languish on stuff like this but CPAN is monstrously useful. If you are arguing Perl is hard to read it is because of the PROGRAMMER and not the language and most people are only arguing over what they remember about Perl 4.X which is YEARS old. Perl 5.6+ is awesome. The only thing I don't like about Perl is its OO system. That is crap but workable.
Yes, and his code picks out the first argument. WTF is wrong with that?
Well, constructors and allocators don't have special syntax in Ruby, and I haven't heard anyone suggest that it's a problem...
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
"putz" not "puts" you "schmuck".
Who said anything about problems? It's just consistant and i don't mind consistancy. But do you mean that in Ruby constructors aren't called automagically and are handled explicitly by the programmer? That'd be a difference. Otherwise, C++ doesn't have particularly special syntax for constructors and it isn't a "problem", but neither would it be a problem if they did.
The enemies of Democracy are
No, I mean that in Ruby, constructors don't have special syntax and aren't covered in underscores or other ugly punctuation.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak