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.
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 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?
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.
Do you know why Apple pioneered Command (nee control) Z, X, C, and V for Undo, Cut, Copy, and Paste? Take a look at a QWERTY keyboard: they're the easiest keys to hit with only the left hand. Same for Command-W for close, Q for Quit, and A for select all: one handed operation, leaving the right hand free to drive the mouse.
I grant you, left-handers and non-QWERTY keyboarders are left out in the cold, but at least there was a method to the madness.
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?"
Don't write it.
/I kid because I love.
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.
O.K. so you are not using new lines and threw in a regular expression to make things look difficult. What is your point? I can gen up an equally obtuse statement in C and C++.
Oh come on, troll? The python guy is already up to +5 funny!
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
(BE) ON A HIDING TO NOTHING -- "Face annililation. Or, less dramatically, 'face insuperable odds,' 'be without a prayer,' i.e., with no hope of success. 'Hiding,' in this expression, is synonymous with 'thrashing,' and a 'hiding to nothing' means 'a thrashing to bits.'" From "British English: A to Zed" by Norman W. Schur (Harper Perennial, New York, 1987).
So what would a language above knocking look like? Would it force you to use exactly the sort of syntax that the author thought "looked" the best, right down to the indentation/bracketing style?
I've seen beautiful but bloated Perl, and efficient but ugly Perl, and all shades in between. It's just a matter of compromise, and I for one like being able to choose where in the spectrum I want my code to fit.
Skype is too convoluted... Now I'm reverse-engineering the Kyoto Protocol.
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
there is one rule of coding style: you should have one.
# 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.
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
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?
Yeah, fuck c
Pain lasts, kid. Its how you know you're alive. Sometimes I think this growing up thing is just pain management-TheMaxx
That a joke? I don't think there's any language that can be fully understood after a 2-semester course.
Sometimes you NEED glorified shell scripts, cause otherwise the shell becomes bloated with features that most people don't need.
excitingthingstodo.blogspot.com
I don't hold that against the language, but I'm sure not going to hire anyone who writes code like that. Anyone can write obfuscated code in any language if they are so inclined.
Regular expressions are a good example of something that is incredibly useful and powerful, but total gibberish to people who don't understand them. I'd hate to not have them just because some people think they're ugly.
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
Amazing how the importance of typing one-handed has never evaded software engineers.
Since no one else asked, what does he mean by "cuddling" else statements?
That doesn't make what you have said more funny.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
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.
Perl didn't decrease in popularity, the others increased as people found out they can do "professional" websites in php, etc.
RoR would be nice but it lacks the granularity of perl.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
Assuming that is the case, then Perl is not being used as often for new development projects. And such a lack of new Perl-based systems will eventually lead to the minimalization of Perl. That in itself could be considered a decrease in the popularity of Perl.
Cyric Zndovzny at your service.
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;
Actually, there are 4 (5 if you count the empty regex after the first split):
//
/ ^$P/ix
/^[ P.]/
/^r/
/\S/
I agree with the grandparent, I don't get how this code example means Perl is bad. You can do something similar with any language that doesn't require newlines between statements, and which allows regular expressions.
Ironically, the word ironically is often used incorrectly.
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?
Well, since the Perl 5 interpreter is written in C, this isn't such a change. Perl just isn't meant for systems programming.
You need to read the book. Besides the bad variable names, you need whitespace and blocking. Comments and using better delimiters would help too.
I've seen similarly unintelligeble C, and it has the same basic problems: Bad variable names, bad whitespacing, bad blocking.
'Sensible' is a curse word.
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. :(
That really proves his point, doesn't it?
IIANM slashdot is over 6 years old and fink is at least 4.
I'm sure there are better ways to become clinically depressed than maintaining a nontrivial perl codebase, but none comes to mind atm.
000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. HELLOWORLD.
000300
000400*
000500 ENVIRONMENT DIVISION.
000600 CONFIGURATION SECTION.
000700 SOURCE-COMPUTER. RM-COBOL.
000800 OBJECT-COMPUTER. RM-COBOL.
000900
001000 DATA DIVISION.
001100 FILE SECTION.
001200
100000 PROCEDURE DIVISION.
100100
100200 MAIN-LOGIC SECTION.
100300 BEGIN.
100400 DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
100500 DISPLAY "Hello world!" LINE 15 POSITION 10.
100600 STOP RUN.
100700 MAIN-LOGIC-EXIT.
100800 EXIT.
Luckily, Python knocks bad whitespacing and bad blocking out by using syntactically significant whitespace. Bad variable names can't be helped, though...
Please, for the good of Humanity, vote Obama.
...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
Ok, sounds like I wouldn't like Python... (I'm having COBOL flashbacks here, needing a space on some line, just because...)
'Sensible' is a curse word.
Please feel free to identify which OS's used these keyboard combinations. I am curious (not baiting you), as I've used many in the past
Why is this marked as offtopic?
Both comments are clearly ontopic flamebait.
For readers outside of Australia - Melbourne and Sydney have a rivalry big enough to affected the placement of the capital (Canberra) - it was eventually placed halfway between Sydney and Melbourne.
Even the Australian Constitution had a clause that Canberra must be more then 100 miles from Sydney.
I like honestpuck - but that statement is a troll. Not a particularly funny one unfortunately - because not enough people will get the joke.
My pics.
Which, IMHO, is the best thing to happen to Perl. One of the main reasons why Perl got such a bad reputation is because it is very easy to pick up. The web was (and still is) littered with a huge amount of Perl snippets written by teenage script kiddies who think that Perl and CGI are synonyms (Matt's Script Archive comes to mind).
Personally, I have been using Perl professionally on an almost daily basis (and I'm NOT in IT or software) for over 7 years now, and have never written a single CGI program.
Just because you don't see any web scripts written in Perl doesn't mean Perl is finished. I would actually consider that a new beginning.
Is Amazon big-name enough for you?
http://www.masonhq.com/?AmazonDotCom
(Mason, btw, is a templating system written in Perl)
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.
Meanwhile there is emacs where C-b moves left, and C-f moves right, but the b key is to the right of the f key. Completely back-assward, and clearly designed by 2-fingered knobs who were neither typists nor power users (yes, RMS, I'm talking to you) but for whom "b for backward, f for forward" seemed eminently logical. (And I say that as a hardcore emacs user.)
No, but compared to his post, my post is more funny, and less trollish advocacy, and also more original, as it was posted sooner.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
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
Perl just isn't meant for systems programming.
Neither is Haskell. Hell, one year ago most would have argued that Haskell is a research language, not meant for anything at all.
Perl is about... all the little scripts.
Perl is only good for scripting as long as you don't know anything better. One nice option is Scheme (via scsh). I'd really rather put up with nested parens than with the multitude of unpronounceable special characters in Perl. And I really dislike Perl's design principle of The Maximum Astonishment, too.
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...
use English;
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?
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.
The trends have moved towards frameworks. Perl now has Catalyst, which is "heavily inspired by such frameworks as Ruby On Rails, Maypole, and Spring," but it's coming a little late(r) to the party.
Even Pugs, a Perl 6 compiler, is written in Haskell rather than Perl.
I once had to write an interpreter for a subset of the OCaml language in OCaml for a class.
"Yarrgh! I be just a paintin' of a head..."
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;
Perl may be a fun hobby-toy (which is faster than Python in string manipulation) used for quick scripts (which it is admittedly brilliant at). But I would still use Python for serious work.
Python forces you to structure your code in a certain way, which makes it readable and maintainable in large projects. However, Perl doesn't in any way prevent you from writing readable and maintainable code - Perl just doesn't force you to write in a particular way, so it's up to you to implement self-imposed rules.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
Go look up ESR's experiences with Python, they'll quench your fears--I'm too lazy to do so right now :P
Please, for the good of Humanity, vote Obama.
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.
CPAN? Though let me know if it's not exactly what you had in mind.
One of the reasons we're able to write quick throw-away scripts for virtually all purposes in Perl is that we have a massive Perl codebase to draw from. CPAN is often cited as one of Perl's greatest strengths, particularly against the likes of Ruby, Python, and even PHP. Not that their communities aren't moving in this direction, but the fact that each has projects whose mission statement is essentially "Be like CPAN for [insert language here]" should be an indicator of what remains desirable with Perl, and how we might characterize it as a big-name project.
And if there's one place where you'd want to maintain best practices...
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*
They have languages for that?! Oh man am I clueless.
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.
Helps an awful lot against gibberish like @{$a[0]} to get the first row of a matrix.
Tell me again, how do i get the first element of the first array contained in the array of (references to) arrays? Was it ${$a[0]}[0] or probably @{$a[0]}}->[0] or a different permutation or another diacritical mark somewhere in there? Remind me, how do i pass a filehandle to a function? Something about \ or * or both and somehow I wouldn't pass a filehandle at all, but rather a "symbol table entry".
Astonishing.
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.
Except that it's not see. Maypole is Perl, and Cataylst's daddy.
Were that I say, pancakes?
I've said this before many times, but perl is pecularly well suited to obfuscation. It is a lanugage that is harder to read than any other language that is frequently in use, at least than any other language I am aware of.
This comes back to the core of perl itself. TMTOWTDI. There shouldn't be. At most there should be two ways to do it. If there is more than one way to do it, you get people using each of the different ways, and the amount of variation makes the code harder to read which means harder to debug which means harder to code.
TMTOWTDI is a huge mistake.
I code some perl, but I force myself to use a small subset of the language.
meh
Pugs is a proof of concept for the "white papers",
but more so it's an excuse for the author to *learn* Haskell.
Were that I say, pancakes?
amazon.com
:)
ticketmaster.com
imdb.com
slashdot.org
Just a few of the sites that run Perl...
Pugs is more of a tool to aid in development of Perl 6, it is not the official "to be released" Perl 6.
Personally I find Perl to be very useful in large scale enterprise development. You can write bad code in any language ( yes any language ), that is the fault of the programmer not the language.
It's like trying to blame a poorly constructed house on the fact your dremel tool has 9,000 options to it!
If not for TIMTOWDI, you wouldn't be able to do so.
how to invest, a novice's guide
I've seen beautiful but bloated Perl, and efficient but ugly Perl, and all shades in between. It's just a matter of compromise, and I for one like being able to choose where in the spectrum I want my code to fit.
Maybe a language above knocking would be one that didn't force you to choose between unreadable code and efficient code.
Feel free to mod me "-1 - Angry Jerk".
Apple has been doing so on Macs since System 1 in 1984, AFAIK. They presumably debuted in MacWrite, and possibly in the Finder's Edit menu as well (for use when editing file names). Windows picked them up in 3.1, IIRC, but the numpad versions from DOS were still useable for quite a while.
Media that can be recorded and distributed can be recorded and distributed.
-kfg
No, if not for TIMTOWDI I woudn't have to force myself.
meh
You mean large-scale development of sites like Amazon.com or Slashdot.org?
Oh, and Pugs is written in another language because Perl6 is meant to be self-hosting, and hence needs to be bootstrapped.
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.
I use it for all sorts of programmable etraction and reporting type tasks.
Like I have a 83 line script that generates the dependency information for a set of supplied c source files recursively (ie checks the dependencies of all #include'd files [at least the #include "file.h" form) and outputs the results in makefile format.
I also wrote a quick one at work once that would parse the file which listed the EEPROM datastructure locations and sizes in seemingly random order and then give me a list of free locations (and overlaps...)...
Indeed, it does.
;-)
Right at the start on page 18:
Use 78-column lines.
Bet you didn't expect that
Astonishing isn't it!
Wow, that was even more astonishing! If you don't know anything about perl then quit bad mouthing it.
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
I'm sure they could find a way to fuck up Joy too... :P
Please, for the good of Humanity, vote Obama.
In other words, if all you know is the syntax, you don't know the language.
What if your way to do it didn't fit with the vision of whoever chose the one or two ways to do it?
If you're working on a multi-person project that's a mixture of many different styles and techniques, then the problem is with the development process, not the language. Until someone invents a language where there's one true formatting style, one true symbol naming style, one obviously right name for every symbol, one single API for every necessary library, and so on, you're going to have to trust other people to write maintainable code where the language doesn't help you. If that language ever comes about, you ought to hope that the choices the language designer made match the problems you have to solve -- if not, you may have some ugly, ugly workarounds. Hopefully the language supports those with sufficient encapsulation to keep the ugliness confined appropriately.
how to invest, a novice's guide
Which is one of the reasons I like Python. And one of the reasons I don't. Have you ever tried to email someone (or paste into am IM window) Python code? Be very careful of where you wrap.
Having said that, anyone who writes bad Perl does so on purpose. There's nothing stopping anyone from writing maintainable Perl code. I've been doing it for years. The best practices article is very good at helping self-impose good writing styles, BTW. You're spot on there.
And a side note: the person who modded my original post as a troll obviously never tried to use SOAPpy. I have. I'd love to use python for my SOAP stuff (not only because they strongly encourage it at work, and it would greatly simplify a few issues we have with non-Python code), but I can't since SOAPpy is very, very young, and riddled with bugs and unimplemented features. It's very nearly completely useable for what I need. And since I can't use Java, I get to use Perl. And it works well enough.
It just isn't as slashbot-compliant as it could be. :-)
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
What if your way to do it didn't fit with the vision of whoever chose the one or two ways to do it?
In that case there can be a later revison to the language. Or it would be a case for the person coding to write around the issue.
If you're working on a multi-person project that's a mixture of many different styles and techniques, then the problem is with the development process, not the language.
Every environment is a multi-person project. As someone else has quipped, there are always a minimum of two people working on any project: myself and myself in 6 months time.
Until someone invents a language where there's one true formatting style, one true symbol naming style...
You and I both know that this language does not exist and will never exist.
I realise that there is a conflict. On one hand, when designing the language you cannot envisage every situation in which that language will be used. But on the other hand if you create a multiplicity of means of doing the same thing, it quickly becomes close to unmaintainable. I also consider that there are different languages for a reason, use them in the siuations where they are most appropriate.
You will notice that I said at most *2* ways of doing things. I have no problem with having 2 ways to do things, it is just that perl takes this to extremes. It is also interesting that perl is pretty much the only major language that goes to these extremes. I think that in itself is pretty telling.
There are many other things relating to perl I could whinge about (classes for one), but at the core I take issue with the underlying philosophy.
meh
Just because things *can* be hard or ugly, doesn't mean they *need* to be.
To answer your question:
$a[0][0]
Also, you don't need @{$a[0]}; $a[0] is every bit as much the 'first row of the matrix', just expressed as a reference than a list; in practice, it's more likely that's what you want most of the time anyway.
As for filehandles, if you want to write code that is reusable or scale, you'll do something like this:
use IO::File;
my $fh = new IO::File('/etc/passwd');
or you will need to take special measures to avoid polluting the global namespace (just like in any other language that allows you to use globals for your own ends).
Many of the things you (and most people) complain about are things that are in Perl5 because they were in Perl4, and the Perl community has never been keen to break compatibility with a huge library of existing code, or require people to change their habits just because; however that doesn't mean you're smart to use them in projects of any scale.
John.
Yeah, I noticed that after I posted. I was hoping nobody else would.
Rails has gotten the most press, so it's naturally taken away some of the thunder. I haven't compared them extensively to claim one is better, because I don't care that much.
If we're talking languages, though, comparing Perl to Rails like comparing apples to apple pie. Perl vs. Ruby is a discussion (that I've had before).
"Yarrgh! I be just a paintin' of a head..."
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.
- Use an integer index and the [] operator.
- Integer index and cache the size().
- Integer index; start at size(), count down.
- Use an iterator.
- Use an iterator and cache end().
- Use std::for_each.
All of these were seriously advocated on comp.lang.c++.moderated.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...
Looking at those 4, I see each of those ways to iterate through a vector and I intuitively understand them. 4-5 and 6 might be a little more difficult to someone who is new to C++, however iterators are increasingly becoming part of other programming languages. std::for_each is also something that intuitively makes sense (syntax and operation), and equally this is common in other languages.
Looking at your list of options to return from a function, 3-5 of the variations relate to pointers (yes I do understand the nuances between the different options). 2 and 3 are also pretty close to identical. I'd agree this is one area (pointers) where things get complications, which leads to variation.
Perl does things its own way, which I have found generally less intuitive.
C++ shows TIMTOWTDI done right. Perl does it wrong. Don't believe me?
Off the top of my head (I don't write a whole lot of perl, so I don't have a whole stack more available immediately):
meh
Yeah, and what's with the vi people and their counter intuitive hjkl navigation? Jesus, did they pull right out of their ass? htns would make sense, but the keys hjkl are all over the place, and only one is one the home row.
Standards would be so much more fun if they revolved around me.
You got problems? Some zealot marked mine as flamebait!
Come on! It may be a sore point, but it's the truth.
Sure one *could* write maintainable perl code (I'd like to think I have), but in large projects no-one has the same style (namind, coding, indenting)... leading to a mess even with some forced guidelines and averagely good coders.
In python even novice programmers write best practice code.
Look, I love programming, and am a very good C/C++ programmer, but even I have to admit to flaws in what I like. And even though I love writing complex clear code, even I have to admit that some other language may be better suited.
Thus to come back to the point: It's sometimes good practice to choose another language.
erm ... using python might be really better in some cases, but you should be reminded that almost every unix box has perl and as maybe a shocking surprise to you, pretty many of them are missing python ... for example a minimal debian install has perl but lacks python. i put up most server like machines with pure debian at start, so i have no python until i fetch a program that needs it.
... this makes large python applications pretty manageable and turns large perl applications often into a mess. althrough the problem with both languages for me is that 3-rd party site packages likes wxwindows/tk/opengl bridge packages are often in broken dependancies and it really can make you swear a lot if you want to upgrade your box and because of 1 dependancy half of the python/perl gui programs wave you bye-bye. cant they really integrate some form of gui that would be python/perl native and work across platforms ? this way i would depend on 'john smith' to get some nice python/perl widget running ...
:(
:) (idea is good but current implementation does really cut it yet)
imho the power of python isnt the clear syntax, clear syntax can be written in perl too, some people are just too lazy to do it. python has really good threading and a nice oop model, perl's ithreads are still quite a mess and the variable & oop layer across it is even fuzzier and more difficult to bite through than the h4x0r'5 scripts
both languages are excellent for writing tiny helper tools for linux (tools that linux is missing a lot for dumb users), C and Java are both overkills for such simple tasks (a nice example of an overkill is a installer that is powered by a java gui, this is inhuman, uses twice the memory and need a bloating jvm to run). but without a really stable and "always being there" gui package these tools break a lot
i believe that perl is good in it's own key places, mostly being compact and very portable. in large and multithreaded applications ofcourse python rolls the house in the scripting world.
and for ruby fans, lets wait until the next version rolls out, then we may have a really good spot for that one too
use the right tool for the job and for the best practices use strict and warnings in perl, indent your code and avoid regexp hacks where you dont need them.
I'd tell you the chances of this story being a dupe, but you wouldn't like it.
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.
The first two allow the programmer to use an arbitrary character as delimiter. This avoids having to excessively escape the delimiter character when it occurs in the string. For example, when quoting an XML string in C, one often has many occurrences of \". These escapes both reduce clarity and prevent you from directly pasting the string to or from a testing context.
Since domain specific languages like Postscript, SQL, HTML and XML are often embedded in Perl code, it's useful to have these quoting operators that remove the burden of meticulously escaping special characters.
The qx (backticks) and m (//) operators follow the same logic. Without the ability to pick an arbitrary delimiter, regexes often fall victim to "leaning toothpick syndrome".
More broadly, why can you violate the encapsulation of an object? Because Perl is not a paranoid language. It assumes that programmers are basically sensible. It is, of course, possible to violate encapsulation in C++ (though perhaps not in Java, which lacks pointers). In several years of professional Perl programming, I have never seen a Perl programmer do this in production code.
Might as well ask why C++ lets you cast an object pointer to one of a different class.
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!
Just for the record, I was going for +5 Funny, not Flamebait, so I'll explain:
I generally use Java on large projects and PHP on smaller "toy" ones. I've used Perl enough to know how easy it is to write unreadable code, but that you can write elegant, clean code as well. This is probably true for almost any language.
I guess the point I was trying to make is that Perl gives you __more__ multiple ways of doing the same thing, and more syntactic shortcuts that don't make the underlying program any more expressive, only saving programmer's wrists. (all of the $_, $* commands, predicate conditionals, etc)
As an example, the "f() unless x;" statement is almost certainly translated into "if (!x) f();" within the interpreter/compiler somewhere. It's syntactic sugar, albeit nice when translating your thoughts into code.
I'm really not trying to knock Perl, but only suggest that perhaps the uber-expressiveness of it is both a crutch as well as a feature.
Wer mit Ungeheuern kämpft, mag zusehn, dass er nicht dabei zum Ungeheuer wird. --Nietzsche
And such a comment regarding to the language where there's "more than one way to do it"?
My last real contact dates a while back, but it was Perl5, definitely. I distinctly remember that I certainly wanted the array. In list context. If I need that, I need that. Definitely, not unlikely. And the unpronounceable @{$...} was really annoying.
$a[0][0]
Nice. Works for array-of-references-to-arrays, but not for reference-to-array-of-references-to-arrays. Didn't you tell me it was the latter which I was more likely to want anyway? And why did the other poster put an arrow between the brackets? Just for fun or does it do something sometimes?
That's exactly the point! WTF do I need special measures?! What globals?! I hate global state, that's why I want to pass the filehandle to a function. If it works with a goddamn hash table, it has to work with a friggin filehandle as well!
Really, I have no prejudices against perl. I worked with it, together with coworkers who allegedly knew much, much more about it than I did. The application was unreliable. Everytime it broke, it broke in subtle, unpredictable ways, including algorithms that worked only "most of the time", HTML code visible to the user, because someone put a backslash too much somewhere, gross memory leaks and even segfaults due to an overeager garbage collector.
It was a horrifying experience. This agony should not be foisted on anyone, really.
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.
Yeah and look at what they do now: cmd+opt+[left|right] for tab switching. And you can't change it to strg+tab in the system settings.
b4n
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...
This I know. The Grandparent suggested that there are other operating systems that provided this feature before the Macintosh. I've asked him to identify one, as I can't think of any.
And I've used my fair share of OS's...
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...
That is really interesting! Now the original Windows clipboard keys make sense as well (Shift-Delete, Ctrl-Insert, and Shift-Insert for Cut, Copy, Paste respectively).
If you like Python, you must love COBOL.
Trying to think of a scripting language I like less than Python? AREXX? Nope; Perl? Nope; Ruby? Nope; TCL? Nope; BASH? Nope; KSH? Nope; AWK? Maybe, but that's just because the docs suck.
Learning the basics of Perl is easy, just start with perldoc perl. But mastering perl is a different matter.
Personally I like Perl, features like not having to use escaped strings for regualar expressions kick make coding the language a joy.
If someone is passing you on the right, you are an asshole for driving in the wrong lane.
Well, you can't have your cake and eat it too; I told you what to do with @a, which is what you used in your example; for my alternative, you'd use
:)
$a->[0][0]
instead; (almost) any reference can be dereferenced in this way.
FE:
my $x = sub {
return shift;
}
my $a = $x->(1);
Unless you do something to localize it, a variable is global; if you don't specify a scope then there are few options. This is true of almost all languages that don't rely on explicit declarations. If you aren't familiar with the concept, then I'm guessing you've done a fair bit more PHP or VB than Perl (and haven't read many of the Perl manpages).
Using a glob reference doesn't solve this problem - just disguises it by creating a reference to a symbol table slot; unless you've done something to ensure that the reference is to a localized variable, it's a poor practice that would be non-portable in any context; like using hard-coded file descriptor numbers would be in a C library function (to which this practice is broadly equivalent).
Your comment 'If it works with a goddamn hash table, it should work with a frigging filehandle as well!' is just wrong; hash tables are purely internal constructs, whereas file handles are connected to the Real World and must conform to the requirements of the underlying system calls; in Perl4, each filehandle maps onto a file descriptor number that is global to the application - nothing you or I can do about that, although we're free to shuffle around how they're hooked up internally. Perl4 passes this model up to your code, and maps each descriptor to a symbol name (some pre-defined, some created as you open & close file handles); Perl5 provides an abstraction layer that hides these details, but they're still there underneath. If you don't want the hassle of dealing with the nuts-and-bolts (and you strike me as the kind of person who doesn't), use the abstraction layer and this particular poblem will largely go away.
Perl 5 provides a clean, almost infinitely flexible OO environment you can use to build clean, scalable, protable code; if you don't use them, then I can't see it as Perl's fault if your code isn't clean, portable or scalable.
The corollary is that Perl5 provides almost complete compatible with Perl4, and if you take advantage of that then you shouldn't be surprised if your Perl5 code looks like Perl4, and is relatively unportable and unscalable.
As for your application issues, I'll pass more or less silently over issues like blaming the language because coder's can't type, and handing apparently untested code onto users; but some of the things you mentioned would prompt me to say 'Check the scope of your variables'; as for segfaults from an over-eager garbage collector - excuse me?? The only issues I've ever had with the garbage collector in Perl is that it's sometimes so cautious to avoid breaking circular references that it needs explicit help (which,m along with uncontrolled use of globas, may explain the 'memory leaks' you saw).
And if you're paying, feel free to foist some of that horror my way
John.
Forgot one of your questions:
...why did the other poster put an arrow between the brackets?
>
'->' is the dereferencing operator; it's a postfix operator that translates as 'the thing this is a reference to', but also turns up in the OO syntax as a way to reference an object's methods.
I omitted it because I can, and I'm lazy; the '[0]' is something that's only available for arrays, and as a convenience Perl5 allows me to omit the dereference in contexts like this where there's no ambiguity; for instance if I say
my $a = [ { squared => 0, cubed => 0 },
{ squared => 1, cubed => 1 },
{ squared => 4, cubed => 8 }
];
then I can use
$a->[2]{squared}
Unless you do something to localize it, a variable is global;
Oh, I know what "my" and "local" do, and I do use them. I don't know where globals got into your... uhm... scope, but what I meant is this: An argument to a function can be anything, scalar or list, but no file handle. This works:
The same doesn't work with a file handle:
(There may be a comma too much in there.) To make it work, I would have to pass a reference to the symbol table entry containing the handle, of all things. Come on, even if you know about that, it is surprising and anything but orthogonal! And there's no intrinsic difficulty, even C can pass file descriptors around.
Perl 5 provides a clean, almost infinitely flexible OO environment
No, it doesn't. There's support for doing what is usually termed OOP (though nobody has an exact definition), and it certainly is flexible, too flexible for some peoples tastes, but it most definitely is not clean. Years after using this I feel the need for a shower just thinking of it.
segfaults from an over-eager garbage collector - excuse me??
We were using CORBA from Perl. The two don't go together very well, or maybe the implementation sucked. Whatever, Perl routinely threw my servants away while they were still needed. The next incoming request sent the application down with a segfault. I "fixed" it by giving each servant a reference to itself, effectively playing another bug in the GC against the first. Actually, Perl5 has no garbage collector, just reference counting (or something very close to that).
As for the memory leak... well, my variables were local. The problem was Parse::RecDescent, which leaves junk in the global symbol table each time it runs (it evals lots of subs). The GC cannot clean symbols, so this memory leaks. Granted, using a recdescent parser for ini-files was a stupid design anyway, but beyond my control.
When I finally had it with the crashing server, I wrote a wrapper in C(!) that checked if the CORBA servants where still alive and then restarted the server. Most people would write a Perl wrapper when they don't trust their C code... You see, I'm not that stupid and have been programming for years in various languages, but Perl was the only one I positively hated afterwards.
And if you're paying, feel free to foist some of that horror my way :)
I don't think so. I have found my panacea in Haskell (you know, that strange language Pugs6 is implemented in). It's far more regular, is easier on the eye and - believe it or not - it is more concise.
If you really want to 'pass a filehandle' and don't want the convenience of modern methods or passing a reference to its symbol table, you can always pass the underlying file descriptor number, but I can't see the appeal myself; the methods you despise arose when Perl was very young and file handles were first added as 'first and a half class citizens', and Perl5 gives you a more convenient, modern alternative; it's not Perl5's fault if you won't use them when you want portable, scalable code.
.ini file, it's wasting time parsing the same file twice.
The CORBA issues you have are almost certainly the fault of your CORBA interface; in the glue that ties Perl to C, it's much harder to get the memory management right - the interface has to ensure that C and Perl agree not only on the size and structure of items, but who's responsible for managing them; it's possible that (e.g.) the C Corba routines were being passed memory allocated by Perl and then passing it to free() or realloc(), or just hanging on to it until after Perl had GC'd it. Or something silly like passing an int when you need a long, or allocating a buffer of 32 bytes for a string of no more than 32 characters, etc.
I can't comment on Parse::RecDescent, never having actually used it; however the changelog for version 1.24 references a bugfix that sounds like it may be your issue.
Personally, when writing code that may have to read multiple ini files multiple times (sadly, a common requirement), I'd normally use a global hash to cache the parsed files - if there's one thing worse than attempting to extract allegedly useful information from a knock-kneed, illegitimate format like an
And Haskell looks really neat - as a one-time fan of declarative languages I think most people take far too narrow a view on what a language should look like and how it should 'work', and I'm more than happy to give a cheer for functional languages.
John.
What a load of stupidity. You must learn multiple different external progams instead of a single, organized program.
My job involves Perl programming all the time.
Yes, I COULD do everything with those things, but Perl is FAR more effecient for the kind of heavy text manipulation that I need to do, involving tons of special characters, and combining multiple lines with changes made to line 1 dependent on what was originally in line 2.
Perl is 1,000 times more efficient when you have to convert something like:
DP04200000096 Production Number
DT 397823
Text of Document 001-001: Jo Japui .
Into: &DT-397823&|&\001-001: Jo Japui .\&|&DP04200000096&
Which is fairly typical in my job
What you are is someone that is prejudiced against Pearl simply cause the particular jobs YOU PERSONALLY DO are not easy to do with it.
excitingthingstodo.blogspot.com
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...