Slashdot Mirror
Perl Best Practices
honestpuck (Tony Williams) writes "I have to admit that I can bristle at books that try to preach, so Perl Best Practices was on a hiding to nothing when I came to review it. I also have to admit to being torn about the author -- after all, he is one of those poor fools who insist on living in cold, unenlightened Melbourne, while I live in vastly superior Sydney. On the other hand, how can I dislike a man who manages to place a quote that involves my favourite character, Lady Bracknell. from my favourite comic play, 'The Importance of Being Earnest,' in the first few pages of his book?" Read on for Williams' review.
Perl Best Practices
author
Damian Conway
pages
492
publisher
O'Reilly Media
rating
8
reviewer
Tony Williams
ISBN
0596001738
summary
Methods of coding to improve your Perl software
Many years ago I read a marvelous article that explained why so may early editors and word processors supported the keyboard commands of WordStar. When it's first born, a baby duck can be easily convinced that almost anything is its mother. The small bird imprints, and it takes a lot to shift its focus. "Baby Duck Syndrome" affects programmers in a number of ways, not just their choice of editor, and Conway is walking right into the middle and arguing with your imprinting on almost every page. A brave man; fortunately he has the street cred to make you at least listen.
So I carefully placed my bias and bigotry in the bottom drawer and prepared myself. I discovered a well-written, informed and engaging book that covers a number of methods (hey, 256 rules, come on Derrick, 2 ^ 8 rules can't be a coincidence!) for improving your Perl software when working in a team. That means all of us when you remember an adage a guru once told me: "Every piece of computer software, no matter how small, involves at least a team of two -- me, and me six months from now when I have to fix it." Conway puts it differently "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."
The first chapter outlines the why and where of the book. The why is to improve your code with three goals; robustness, efficiency and maintainability. The chapter finishes with a short exhortation to us to "rehabit." Don't like the word much but I applaud the aim.
Conway is far from timid. He jumps right in to the deep end of the wars, with formatting the appearance of your code. I thought the chapter was brilliantly written until he told me I shouldn't "cuddle else statements," at which point I realized what an ill-informed idiot he was. Oh, hang on. Hey, that almost makes sense. OK, that's a cogent argument for your point of view, Conway. I also have to admit that earlier you did say that your rules for this bit weren't gospel, that if you wanted a variation that was OK, just have a standard and make sure you can support it with a code prettier. Perhaps not a total idiot after all.
After successfully negotiating those shark infested waters, Conway -- obviously a man who knows no fear -- wades into naming conventions. Once again he gives coherent arguments, pointed examples and counterexamples. It all makes sense.
The book's page at O'Reilly has an example chapter and a good description, but no table of contents so here's a quick list of the headings:
The book is also well-written and well-edited. The order of topics covered is a sensible one, and the book is appropriately structured. It reads and feels as if you are being given the wisdom from many a hard-won battle coding and maintaining Perl code.
My one complaint is that I found it dry: you are reading through pages of argument and examples without much relief. Perhaps this book might be best digested in a number of chunks, making the effort to use the ideas from each chunk for a while before moving on to the next.
Every so often I read a book from O'Reilly that makes me fear that they are slipping, then along comes a book like Perl Best Practices, and I'm reminded that when it comes to Perl, O'Reilly authors wrote the book. Once you've rushed through Larry's book and learnt the finer points with Schwartz and Phoenix's 'Learning' titles, you may well find that this is the perfect volume to complete your Perl education. If you believe your Perl education is complete, then buy this volume and I'm sure you'll find a lesson or two for yourself.
This book is not really aimed at the occasional Perl programmer (though many of us would probably benefit from its wisdom), but at the person who is professionally programming in Perl and wants to produce better quality, more easily maintained code. For this person Perl Best Practices is a 9/10. For the rest of us, the 'rehabiting' process might be a little too arduous; personally, I'm going to pick a few of the chapters and work on those for a while, maybe naming conventions and variables. For me I'll give it an 8.
You can purchase Perl Best Practices from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Many years ago I read a marvelous article that explained why so may early editors and word processors supported the keyboard commands of WordStar. When it's first born, a baby duck can be easily convinced that almost anything is its mother. The small bird imprints, and it takes a lot to shift its focus. "Baby Duck Syndrome" affects programmers in a number of ways, not just their choice of editor, and Conway is walking right into the middle and arguing with your imprinting on almost every page. A brave man; fortunately he has the street cred to make you at least listen.
So I carefully placed my bias and bigotry in the bottom drawer and prepared myself. I discovered a well-written, informed and engaging book that covers a number of methods (hey, 256 rules, come on Derrick, 2 ^ 8 rules can't be a coincidence!) for improving your Perl software when working in a team. That means all of us when you remember an adage a guru once told me: "Every piece of computer software, no matter how small, involves at least a team of two -- me, and me six months from now when I have to fix it." Conway puts it differently "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."
The first chapter outlines the why and where of the book. The why is to improve your code with three goals; robustness, efficiency and maintainability. The chapter finishes with a short exhortation to us to "rehabit." Don't like the word much but I applaud the aim.
Conway is far from timid. He jumps right in to the deep end of the wars, with formatting the appearance of your code. I thought the chapter was brilliantly written until he told me I shouldn't "cuddle else statements," at which point I realized what an ill-informed idiot he was. Oh, hang on. Hey, that almost makes sense. OK, that's a cogent argument for your point of view, Conway. I also have to admit that earlier you did say that your rules for this bit weren't gospel, that if you wanted a variation that was OK, just have a standard and make sure you can support it with a code prettier. Perhaps not a total idiot after all.
After successfully negotiating those shark infested waters, Conway -- obviously a man who knows no fear -- wades into naming conventions. Once again he gives coherent arguments, pointed examples and counterexamples. It all makes sense.
The book's page at O'Reilly has an example chapter and a good description, but no table of contents so here's a quick list of the headings:
- Best Practices
- Code Layout
- Naming Conventions
- Values and Expressions
- Variables
- Control Structures
- Documentation
- Built-in Functions
- Subroutines
- I/O
- References
- Regular Expressions
- Error Handling
- Command-Line Processing
- Objects
- Class Hierarchies
- Modules
- Testing and Debugging
- Miscellanea
The book is also well-written and well-edited. The order of topics covered is a sensible one, and the book is appropriately structured. It reads and feels as if you are being given the wisdom from many a hard-won battle coding and maintaining Perl code.
My one complaint is that I found it dry: you are reading through pages of argument and examples without much relief. Perhaps this book might be best digested in a number of chunks, making the effort to use the ideas from each chunk for a while before moving on to the next.
Every so often I read a book from O'Reilly that makes me fear that they are slipping, then along comes a book like Perl Best Practices, and I'm reminded that when it comes to Perl, O'Reilly authors wrote the book. Once you've rushed through Larry's book and learnt the finer points with Schwartz and Phoenix's 'Learning' titles, you may well find that this is the perfect volume to complete your Perl education. If you believe your Perl education is complete, then buy this volume and I'm sure you'll find a lesson or two for yourself.
This book is not really aimed at the occasional Perl programmer (though many of us would probably benefit from its wisdom), but at the person who is professionally programming in Perl and wants to produce better quality, more easily maintained code. For this person Perl Best Practices is a 9/10. For the rest of us, the 'rehabiting' process might be a little too arduous; personally, I'm going to pick a few of the chapters and work on those for a while, maybe naming conventions and variables. For me I'll give it an 8.
You can purchase Perl Best Practices from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
...after all, he is one of those poor fools who insist on living in cold, unenlightened Melbourne, while I live in vastly superior Sydney.
Ok, jackass.
If it looks like an emoticon, your Perl is probably syntactically correct. ;)
Skype is too convoluted... Now I'm reverse-engineering the Kyoto Protocol.
Perl Best Practices: don't
"I have to admit that I can bristle at books that try to preach, so Perl Best Practices was on a hiding to nothing when I came to review it."
me fail english? unpossible!
use Python!
I'm too young to have used wordstar, but I can tell you one thing: is a lot easier to use wordstar keys for clipboard operation then it is to do the weird ctrl+c/ctrl+v thingy
I'll do the stupid thing first and then you shy people follow...
Perl programmers always say they can do anything in one line of code. Does this book finally set a limit on how many characters can be in that one line?
Use a better fucking language!
Perl Best Practices, page 1.
Use Python.
Ba-dump-bump! Thanks, I'll be here all week. Be sure to tip your waitresses.
Weaselmancer
rediculous.
hahahahhahahah!
I feel like I'm taking CRAZY pills!
That review is so long. winded and obtuse. It makes me want. To write. Sentence fragments. Just to take a breath.
Don't use perl.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
Ofcourse if you're using Perl4 and below, you're out of luck...
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
What's the point of using Perl if your code suddenly becomes intelligible? After all, there is more than one way to obfuscate it.
In Soviet Russia, Jesus asks: "What Would You Do?"
because it's shinier.
That's easy - use Python! /ducks!
Use python instead.
Don't write it.
/I kid because I love.
NT ;)
Computers are useless. They can only give you answers.
-- Pablo Picasso
Following best-practices while coding in Perl is like following standards of hygiene when torturing someone to death.
) +=$f=!fork;map{$P=$P[$f^ord[ P.]/&&
I code in Perl sometimes, so therefore I have the right to knock it. And any programming language that allows garbage like this deserves to be knocked.
@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^
close$_}%p;wait until$?;map{/^r/&&}%p;$_=$d[$q];sleep rand(2)if/\S/;print
Wer mit Ungeheuern kämpft, mag zusehn, dass er nicht dabei zum Ungeheuer wird. --Nietzsche
Perl is getting to the point where you need a 2-semester college course on the subject before you can fully understand all aspects of the language.
People love C and Perl 5.x for their simplicity. Heed the advice of the bearded, coke-bottle-thick eyeglass wearing UNIX programmers. "Keep it simple, stupid."
after all, he is one of those poor fools who insist on living in cold, unenlightened Melbourne, while I live in vastly superior Sydney. On the other hand, how can I dislike a man who manages to place a quote that involves my favourite character, Lady Bracknell. from my favourite comic play, 'The Importance of Being Earnest,' in the first few pages of his book?"
Oh, you do slay me, mate.
Is this like http://slashdot.co.au/ or something?
Your hybrid is not saving the environment. Its purpose is to make you feel good about buying something.
My Data Structures professor once said: "Perl is a write-only language" :)
All your Sybase are belong to us.
Only Perl best practice is to not use this bloody awful language.
switch to Python.
Use something better and more maintainable, like Python or Ruby. There's no reason anymore to stick to Perl, whatever problems it used to solve can now be solved more clearly and more efficiently with other programming languages.
Please stop writing glorified shell scripts.
cheers
Non-qwerty keyboarder's aren't left out in the cold provided the key mappings are changed to the same physical keys, in which case they have just the same performance.
Pity it's so much effort to change the bindings in most word processors.
Exercise your right not to vote. thinkoutside.org
..with the folks here who are saying "use something else".
Seriously.
Perl is just too "clever". It forces you to stop and marvel (or scorn , more likely) it's design at every turn. I felt this just today while trying to write an exception handler. I wanted to write a function that took another function as an argument, ran the function, and made sure resources were cleaned up. Pretty typical idiom (think about Lisp macros that use unwind-protect, or Ruby blocks with "finally" clauses) Think about that, I had to *write* an exception handler. And deal with strings, objects, or other scalars being thrown. Having to decide if I should overload my objects to used "ne" or "==" for equality (or both?). Why should have to think about all this stuff? In Ruby it would be just a couple lines of code. And it would be easy to read (no dollar signs and arrows all over the place).
Not trying to troll here. I've written and maintained several large high-performance mod_perl apps. I think I know what I'm doing. But Perl just gets in my face way too much. I think it's because I've worked in so many other languages, I "see" Perl differently than others do.
Looking at Perl 6, they've cleaned stuff up, there are some nice things there, but made it even MORE complicated in the process.
So, I'm working on weaning myself off Perl completely, and I suggest to others, if you think you really need a book like this, take a moment and reflect and consider if maybe it's time to switch to another language completely.
there is one rule of coding style: you should have one.
Save yourself $13.58 by buying the book here: Perl Best Practices. And if you use the "secret" A9.com discount, you can save an extra 1.57%!
# perl -cW foo.pl
and use strict
But really, if you want fancy error-catching technology you'll have to wait until Perl 6.
[an error occurred while processing this directive]
In a similar vein there was a recent article by the same author printed on perl.com:
I picked up this book probably a month ago, and for a seasoned perl dev who plans on exposing his code to the world, it's definately worth picking up.
One nice feature I found was the chapter on formatting included vim and emacs config snippets to achieve the same effect, as well as the config file to use perltidy to do the same thing.
I agree it is dry, and it's very "bam bam bam" with the examples. Not something you can read start to finish. you'll want to try implementing things right away. I suggest taking the book a chapter at a time and implementing the changes in your code then.
There were some bits I agreed with, and some I didn't agree with; however the parts that I didn't agree with they explained in a reasoned and rational manner, and made me rethink my own thoughts on the subject.
I've recently fallen into the position where I'll be leading possibly two other developers- this book will become a standardization format for our company.
again, I highly recommend this book.
-morgajel
Looking for Book Reviews? Check out Literary Escapism.
cameo wood http://www.kiad.net/ is my source for all things perl
In all seriousness, every perl script should begin with the first three lines:
#!/usr/bin/perl -w
use strict;
use diagnostics;
"War is God's way of teaching Americans geography." -- Ambrose Bierce
The best thing a perl user can do is run this script ...
/usr/bin/perlc /releases/gcc-4.0.1/File: gcc-4.0.1.tar.bz2
./configure
rm
wget ftp://ftp.funet.fi/pub/mirrors/gcc.gnu.org/pub/gc
bunzip2 gcc-4.0.1.tar.bz2
tar xvf gcc-4.0.1.tar
cd gcc-4.0.1
make
make install
Jeezis, what a lame review. Three paragraphs about the reviewer, then a listing of the table of contents, then a few useless comments like "it's edited well", "it's dry". The author doesn't like uncuddled elses, and takes issue with "rehabit". Waa! How about mentioning some of the actual best practices?
Why are you suggesting that TripMaster Monkey is the GNAA operative based in Melbourne? As far as I can tell, TripMaster Monkey is nothing more than your typical American software developer, most likely unemployed because his job was outsourced to India or Thailand. His chronic unemployment explains why he can post so frequently here.
That a joke? I don't think there's any language that can be fully understood after a 2-semester course.
hthe lon6est or
Sometimes you NEED glorified shell scripts, cause otherwise the shell becomes bloated with features that most people don't need.
excitingthingstodo.blogspot.com
use Python ;-)
What big-name projects is Perl being used for today? While it was once very big for web scripting, that arena now seems to be dominated by PHP, Ruby-on-Rails, ASP, JSP, and so forth. Even Pugs, a Perl 6 compiler, is written in Haskell rather than Perl.
While I'm sure that many people find it very useful to small throw-away scripts, perhaps it has outlived its usefulness as a general-purpose language suitable for large-scale development. As such, perhaps "best practices" aren't really needed, especially if the script will be discarded after a few uses.
Cyric Zndovzny at your service.
Use pyth^H^H^H^Hrub^H^H^H...oh wait. NO. Cue the fucking jokes about using something else.
We are here reading this review because we want to use perl, so f*ck off, RoR, PHP, Python fanboys. Everything you can do in those languages i can do in perl, with style, so i NO don't want to hear about the hype of the year.
I couldn't live without perl one liners and i found the review helpful. Like many said before, perl doesn't force you to write readable code, but it doesn't mean noone can.
Best practice would be "use strict;use warnings;" and using indents properly.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
...in 1...2...3...
Since no one else asked, what does he mean by "cuddling" else statements?
in no other scripting language you get as many great libraries as in perl. and if you are at the level of writing own modules (yeah, that is not as easy as in python), this book is for you-and you are already one of us. strange guys who love perl...
what I wanna say: the standard perl script is quite short ( 200lines). then libs and their apis are more important than anything else.
Unless you need to do anything with SOAP, in which case Python is the by far the worst tool for the job...
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
Well, Python's better, isn't it?
Being a Python programmer, not a Perl programmer, I'm sure you won't be angry if I point out your syntax problem: you forgot the semi-colon. It's a common mistake though. The proper syntax is:
use Python;
As a perl programmer, I can assure you that:
1) There are reasons to use Perl. Nothing REQUIRING it, granted, but that's true of any language. Python and Ruby inhabit similar but not identical niches.
2) Line noise reputation aside, Perl can be _very_ readable. Concise done correctly means that it says what it does and does it, without unnecessary compiler syntax effort. Concise done wrong means it's not obvious what you are doing. Perl gives you enough rope to hang yourself...kind of like computers, and open source in general.
3) As far as the book goes, I was eager to get my hands on it and learn, but worried that I'd find it too limiting and restrictive. The tips ranged from the obvious (strict and warnings), the non-syntactical useful (use code and documentation template for new projects), to the small but fascinating (make your hash names end it words like "for" or "of", so that normal usage is self documenting: $name_of{$user} ). Very few of the tips did I disagree with, and even though the book talks about the importance of HAVING standard practices over what those practices are, I'm moving my dept to adopting the standards in the book because my preference is often habit over any calculated reason.
Perhaps 50% of the tips have nothing or little to do with Perl and everything to do with programming, programmers, or users.
This is not a life altering book. It is, however, a high quality book with some very good tips.
I, too, purchased the book about a month ago. I was hoping it would be sort of an "Effective C++" but for Perl.
It's nice to have, and it gives me things to think about for improving code, but it's by no means essential.
In some cases, the author's advice is inconsistent. For example, he sometimes suggests that a programmer avoid constructs that would force a reader to look something up. And some other times, he suggests using a construct (e.g., \A and \z instead of $ and ^, respectively, in regular expressions) BECAUSE it's unusual and many people will have to look it up.
--I'm so big, my sig has its own sig.
-- See?
Actually lefties have the advantage. By leaving the mouse on the right, as we are prone to do because moving it all the time sucks, it leaves our more dextrous hand to work the keyboard while our "less dominate" hand points and grunts at the screen.
I often wonder why more right handers dont put the mouse on the left and enjoy the same advantage.
Then again, I am a avid keyboard user.
Is it just me, or Perl has lost much of its old prestige ? Ruby, Python and other languages ( such as the most excellent io language have gained so much momentum and popularity, that Perl just doesn't seem to be getting much attention from the users nowadays.
Rightfully so, if I may say.
Technology ramblings : Simple is Beautiful
Sure there is. Brainf**k, for example, which has only eight instruction types. Or Malbolge, where you can peruse all existing programs in an afternoon.
I had the same problem, except in foo.pl. Maybe my retarded. :(
...and the poor guy didn't get a cent from that - so go out and buy this for all your devs, and buy Peopleware by Tom Demarco for all your managers while you're at it.
;-)
I get a copy for every new dev now. I'm not going to force them to use all of it, but it definitely makes them think when they start working on larger projects.
I'd also recommend MJD's Higher Order Perl if you want to go even deeper.
I always think it's funny when people argue heavily about hating to work to a "best practices" style. And then start agruments about how crap Perl is because it's unreadable. Anyway - I digress.
cLive
-- Trinity in high heels carrying a whip: The donimatrix - there is no spoonerism
Best Perl Practices - By: Roy Martin
Chapter 1
The End.Don't use it.
Hey look no pointless curley braces or semicolons... just like Python
Apart from still being an excellent "glue" and prototyping language, it's also used in its own right. Some rather large companies (and smaller ones too) use mod_perl with one of the many templating engines to power their websites. Biotech/genetic researchers use Perl's powerful text parsing capabilities. OpenBSD and Debian use it in whole or in part for their package system tools. There are also many network apps and even some with GUI's like this one (which uses Tk as the GUI library, but Perl also has Wx, Gtk, and other bindings as well):
http://butchersgrill.com/software/opentill.jpg
Doesn't look that HARD, just so mind-numbingly tedious as to make anyone who started out to give up out of sheer boredom as soon as they finished Hello World.
More to the point, you will write crap in any language if you don't understand the conventions, idioms, and best practices of the language.
Perl is a lot like Lisp. You need to think in terms of lists before you see anything but the sigils and you tend to write "C in Perl". Further, until you see *good* Perl code, it's hard to know any better. Before this book, the book I'd refer people to was "Effective Perl Programming" by Hall & Schwartz. The goal was to get beyond "baby talk" and use the language well.
I'm about 130 pages into "Best Practices" and I like the book a lot. It's definately on the required reading list for any Perl programmers that we hire.
I can't say I agree with Damian about *all* the conventions (I really *like* "unless") but I agree with most of them, and having met him once, I'll admit that he knows more about Perl than I'm ever going to know, and more about computing languages and PROGRAMMING best practices than most of the people that have responded to this topic.
If you code in Perl often enough that you wish your code was better, you should pick up this book.
Setting aside content, this is possibly the most poorly written piece of text I have ever had the misfortune to read. Buy some books on how to write.
Wrong. Shell scripts use external programs to do all the heavy lifting, by design. (cat, tee, grep, xargs, etc) Shell scripting is infinitely extensible.
I never saw the use for a language like Perl, except for those people who don't know shell scripting.
The code I have to deal with you'd never know.
Any of the LISP's are simple. Ruby tends to be simple too. Now, if you are including in that 2 semester course the libraries as well, then you might be correct, but there are plenty of examples of very simple, orthogonal languages.
...interesting if true.
In 5 years of studying computer science (BS, MS) I was never formally taught Perl in a class. I learned it as the side effect of a Relational Database class. Now, 6 years later, I use Perl, ASP, and Microsoft Access on a daily basis. Not exactly the path I envisioned when I was a bright eyed 21 year old open source zealot.
/(.*?)the/; /(.*)the/;
Anyway, last week my mom told me it was important for me to start giving back to society, so here is your Perl tip of the day. It took me a few months of writing awful, inefficient regular expressions to learn this doozy:
the ? is your friend. It forces regular expressions to search for the first match, instead of the last."
Example:
$test = "Perl regular expression tip of the day: the ? is your friend. It forces regular expressions to search for the first match, instead of the last.";
$test =~
print $1;
print "\n--\n";
$test =~
print $1;
C:\>perl test.pl
Perl regular expression tip of
--
Perl regular expression tip of the day: the ? is your friend. It forces regular expressions to search for the first match, instead of
Comment removed based on user account deletion
You've obviously never met Larry Wall. You, sir, are no Larry Wall.
People (well, some people) love C for its simplicity, and people (some people, maybe some overlap with the previous group, maybe not) love Perl 5... but I doubt for its simplicity. (Try to find an EBNF description of Perl 5. What's the construction count?)- Richard
... yours truly, slashdot? Yes, perl. And Amazon.com, perl too. Show me PHP websites of this magnitude...
and Haskell is being used to _implement_ the Perl 6 compiler for the same reason Python or Ruby interpreters are writter in C. Except, of course, Haskell is a lot higher level than C and more secure, meaning the current size of the project is just short of 4K lines. and no side-effects... ^_^
I don't feel like it...
I don't think there's any language that can be fully understood after a 2-semester course.
Scheme and Forth, maybe even Smalltalk don't count?
Yea, learning any language syntactically might be feasible in a 2 semester college course, but learning HOW to use a language properly takes longer, even LISP and HASKELL
I took a one semester course that taught syntax of both previously mentioned langs, but to really LEARN them would take MUCH longer.
(The course was a programming language theory course and was designed specifically to show that syntax isn't everything)
Perl is getting to the point where you need a 2-semester college course on the subject before you can fully understand all aspects of the language.
Perl's syntax is very complex; it has a lot of operators and provides many different ways to do the same thing. This makes reading other people's code very difficult.
Everyone starts by learning a subset of the language, then building upon that by learning more after they've mastered the basics. You can write a lot of perl code without knowing half the syntax. The problem is, since everyone learns a different subset, reading someone else's code is impossible for a beginner, and unfamiliar syntax isn't something you can easily look up in a reference. A language like PHP has a simpler syntax and far fewer operators, and makes up for it by having a large number of functions; once you've got the syntax down, you can just look up unfamiliar functions in the documentation and figure out what's going on. The result of this is that PHP looks easier to beginners while Perl looks daunting.
I'm completely ignoring Perl 6, and I'd advise others to do the same for at least a few more years.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
The very best practice for any Perl developer is to move to Python and save his sanity, if any is left.
I don't think there's any language that can be fully understood after a 2-semester course.
I disagree. Most people I know are able to completely master pig latin with just a couple of days of study and use.
Itym Damian
1. Don't
while (!asleep()) sheep++
I recall the "Baby Duck Syndrome", which I use conversationally on a semi-regular basis, appeared in a Doctor Dobbs Journal Issue. It even had a picture of a duckling on the cover. Must have been around 1983.
Slashdot: Where nerds gather to pool their ignorance
Having hacked with Perl for many years, I must say I find seeing "best practices" and "Perl" in the same title seems a bit oxymoronic.
*waterfowl*
"don't use it".
better click that anonymous thingy.
Sounds like a great book but from the sample pages, a bit hard reading. As a perl hack (forced by use of Interwoven's TeamSite product) I'm happy to have any resource... especially my Perl 5 Pocket Reference (O'Reilly). Rock on.
However, looking at a copy of the play online I discover :
"Three addresses always inspire confidence.
But certainly that pertains more to C than Perl.
If you're used to perl, you'll spend at least an hour figuring out what it doesn't want you to do... BUT, you'll save days of debug time later.
-- The act of censorship is always worse than whatever is being censored. Always.
Perl does allow line noise, yes. But regular expressions require line noise. A lot of my Perl reads fine until I hit a regexp.
That a joke? I don't think there's any language that can be fully understood after a 2-semester course.
How about Visual Basic.
The core language can be learned in a day or two. In order to do anything useful with it however invloves massive amounts of work to get around its shortcomings.
I had a theory about this, so I checked it out with this frequency table and Gnumeric.
In the Qwerty layout, more of the most commonly-used letters are located under the left hand. Taking the limit as T, G, B, you can hit about 57% of letters by frequency. If you include occasional jumps as far as U, J, N (within reach of my relatively small hand), it's nearly 73%. Thus, it's more useful to keep the left hand on the keyboard. You can of course argue that one could move the right hand across, but the left hand starts from an advantageous position for one-handed typing.
If your comment title says 'Re: Foo', I'm not likely to read it.
Indeed, it does.
;-)
Right at the start on page 18:
Use 78-column lines.
Bet you didn't expect that
I went to his talk on Dead Languages last night at Melbourne.PM - very funny. Especially when C++ made the dead list!
:)
My work purchased a copy of the book there, so I'll check it out when I'm in the office next (today is a work-from-home day
In other words, if all you know is the syntax, you don't know the language.
Show me PHP websites of this magnitude...
Let's see...there's Yahoo, for one. Then there's also MIT who seems to process 3 million hits on over 1.1 million documents a day, according to their reported stats.
Throwing a couple high-profile links out to websites using foo on the backend does not a good language make. Coders with style and best practices a good backend make.
I understand your sentiment, but I think that on balance Perl 6 will be an improvement. The changes are not the product of Larry's imagination, but have been hashed out thoroughly and publicly as RFCs. As time goes by, other languages are catching up to or passing Perl in its core strengths, while offering other strengths Perl doesn't have. Perl must adapt or die.
Damian was actually gracious enough to visit our LUG last month, and hand out a few copies of Best Practices. The guy is AMAZING in person, funny, engaging and a guru of Perl and programming in general. Ive been reading the Best Practices book for the last month, and i'd say this should be on every programmers shelf, whether they use Perl or not.
May your Rakudo never fail...
Want to learn some best practices? Buy the book, you cheap hippie!
Also: fuck uncuddled elses. And rehabit too. What a dumb fucking word.
Having actually been a student of Conway at Monash University (far superior to anything NSW can offer). I can honestly say that he was by far the best lecturer of any I studied under. The guy seemed to know everything about anything. Probably the most entertaining lectures we sat through were generally not about anything to do with computing. From my point of view the guy was a genius.
Programs looking like ascii art!
2. Don't do it yet
Everyone starts by learning a subset of the language
As someone who regularly downloads and fixes broken perl modules, I have to disagree.
Everyone tends to use the same subset at the start.
The big thing you see in a beginner's code are just control structures (especially foreach statements), and regular expressions (and then mostly only stuff you'll see in an awk expression).
Things like inventing a new inheritance structure (as is done by Class::DBI, OOTools, and PDF::Template), embedding a LALR parser (all the template engines), are a sign of a mature coder, and happen much less. These people are more likely to write code in a logically consistent, well designed manner such that it is easy to extend.
So far I've found one module that I tried to fix (and ended up not because it was too much work) that wasn't either simple or well designed (Class::DBI::FormBuilder).
Mod me down and I will become more powerful than you can possibly imagine!
to make things look difficult
(or like in another post :
it looks like perfectly normal code)
I don't think it does. I couldn't make sense out of it, even though I also cleaned it up first.
It doesn't run on Windows, and I've never used pipe in Unix, and very rarely used fork. So that's my excuse for not understanding it. But I suspect those who consider it as normal code don't quite understand it either. Or those who do must be quite great Perl hackers. On par with the author: Mark-Jason Dominus.
Anyway, the explanation is well worth reading.
Perl hackers may prefer to try to guess how it works from as little hints as possible:
Hint 1 | Hint 2 | Hint 3 | Hint 4 | Hint 5 | Hint 6 | Hint 7 | Hint 8 | Hint 9 | Hint 10 | Hint 11
Others will jump straight to the spoiler.
It's not a bug, it's a feature: it doesn't run on Windows. Works fine in Unix.
Links to the explanations are here, but it's not for novices.
Should be(looks alright in the preview. hopefully it stays like that in the post)
"clear syntax can be written in perl too"
yep, but let's not stretch that definition too much, ok? I'm a Perl fan myself, but i'll never claim
to be as clear and concise as
let's get real there. Of course, Perl6 will change that...
I don't feel like it...
I'm sorry, Python reminds me too much of old basics and lisp...shudder. If I really need threading that bad (I've never had a problem with Perl's OOP, you just have to remember that it's not enforced with any strength) I'll just use C++ and kill two birds with one stone.
As for the Perl, what's wrong with the following?
sub bar {
my $arg1 = shift;
my $arg2 = shift || 'default';
# XXX #
}
You still get a default value for $arg2 if no value is passed. I've never liked list processing for sub args. My perference is to just pass a hash ref and use named args for anything but simple subs.
BWP
"what's wrong with the following?"
it's even more verbose? there are many cases in which Perl can be really concise, mostly when doing IO, general file operations and, sure, the integrated regex. traditional functional constructs are not one of them.
actually, did you know even the simple lexical variable aliasing for the array parameters comes with a huge performance penalty? learned that in the language shootout benchmarks...
I don't feel like it...
1) It was not available seven years ago when I started using Perl in earnest.
2) In the tradition of The Camel and The Panther, it could end up being known as The Dog...