Weekly Edition
Return to the Press pageSponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
Book Review: Perl Best Practices (NewsForge)
NewsForge has a
review of Damian Conway's Perl Best Practices. "Perl
Best Practices is a good "browsing" book. Have five or 10 minutes to kill?
Flip to a random page and read a couple of Conway's guidelines. As Conway
mentions in the book, most people develop a style that feels right to
them. These habits will be hard to break, so there's not much point in
sitting down and trying to read the book straight through. Better to read a
few practices at a time and try to improve those habits (if necessary) and
move on."
(Log in to post comments)
My own take Posted Oct 10, 2005 21:12 UTC (Mon) by felixfix (subscriber, #242) [Link] I have a copy, and have almost finished reading it. Some of it strikes me as pure busy work, unworthy of being called Best Practices. For instance, he likes "{" on the end of the line introducing a block, "}" on a line by itself, indented to match the "{" line, and so far so good. But then he wants "else {" on a line by itself, indented to match the "}" line, on the basis that "else" is important and should be at the beginning of the line to be in a consistent position. But the construct "} else {" would also be in a consistent position, only differing by having two (consistent) characters in front of it. This seems like a strange best practice.
He also disparages using two double quotes ("") for the empty string, as double quotes are for interpolated strings with embedded variables. But don't use two single quotes (''), as that could be mistaken for a single double quote. Never mind that Perl is pretty good at detecting unterminated strings, and usually tells you where they started. What he wants is the horrible "q{}". Ditto for a single space.
He prefers "for (list) {}" rather than the C "for ($i = 0; $i < end; $i++) {}" because it is not obvious to novices. But he ignores what to do with humonguous lists with millions of entries; is it going to create a huge second copy or not?
There's a lot of nice stuff in this book. But there's enough trivial poorly rationalized stuff to make it less than sterling. I usually buy two copies of good books, one for the office and one for home. One copy of this is enough.
My own take Posted Oct 10, 2005 22:44 UTC (Mon) by Dom2 (guest, #458) [Link] With regards to people using C-Style for loops in Perl, that's usually a "red flag" in any code review of mine. There's no copy made of the list. You simply iterate through each value. Using C style for loops without a comment to say why is a sign that the person writing the code doesn't understand good, idiomatic Perl.
As to the stuff like brace style, I think he's made a good middle of the road choice and tried to explain his standards. He's obviously not going to please everybody, though. But he doesn't try to. He explains clearly that you have to pick your own style and use it *consistently*. To be honest, the style itself is less important than making sure it's used consistently. And that applies to any language, not just Perl.
I strongly recommend listening to the interview he did recently about the book:
http://www.perlcast.com/audio/Perlcast_Interview_003_Dami...
-Dom
My own take Posted Oct 10, 2005 23:04 UTC (Mon) by felixfix (subscriber, #242) [Link] Here is his rationale for putting "else {" on a line by itself:
A cuddled else [the "} else {" construct] is no longer in vertical alignment with its controlling if, nor with its own closing bracket.
This is just so much nonsense, a rationale made up after the fact because he likes the looks of it. "} else {" is no harder to spot, or line up, than "else {", and anyone who thinks "} else {" is harder to see than either "}" by itself or "else {" by itself is fooling themselves.
I don't pick on this just to be picky. The problem is there are many "best practices" in this book which seem just as trivial to me, as if he wanted to make the number of best practices come out to an even 256 and had to scrape the bottom of the barrel to get them.
My own take Posted Oct 11, 2005 12:45 UTC (Tue) by carcassonne (guest, #31569) [Link] I do not understand why you focus on 2 chapters out of 19 when describing this book.
What about Tabular Ternaries ?
Multi-Contextual Return Values ?
Smart Comments to automate progress indicators ?
Test Harnesses ?
Memoization ?
Etc, etc... (short of time here to list more)
There's a LOT more in this book than the use of curly brackets and single or double quotes for strings. Come on.
My own take Posted Oct 11, 2005 9:49 UTC (Tue) by NAR (subscriber, #1313) [Link] But the construct "} else {" would also be in a consistent position, only differing by having two (consistent) characters in front of it.My problem with the '} else {' construct is that it breaks the syntax folding of vim, it makes one fold for the whole 'if' instead of two separate folds for the 'if' and the 'else' part. This is a really practical reasoning :-) Never mind that Perl is pretty good at detecting unterminated strings, and usually tells you where they started. Not to mention that if there is syntax highlighting in the editor, the unterminated string will be quite clearly shown before the perl executable has anything to do with the source file.
Perl's Best Practice... Posted Oct 11, 2005 1:44 UTC (Tue) by Zarathustra (guest, #26443) [Link] ... is to use AWK
Perl's Best Practice... Posted Oct 11, 2005 8:38 UTC (Tue) by nix (subscriber, #2304) [Link] After all, you can write network servers in GNU Awk too!
(But where's awk's module system? I see a great need.)
Mostly Redundant for Python Posted Oct 11, 2005 2:42 UTC (Tue) by AnswerGuy (subscriber, #1256) [Link] I read this book with some fascination.
I find that many, perhaps even most of the practices he extols for Perl "best practices" are simply unnecessary for Python. Python's syntax, features, and general coding style already follow most of the "best" practices from Conway's book.
Python exemplifies the virtue of *reasonable* consistency. For most common things there is one obvious and preferred way to do it. This is not the foolish consistency that's a hobgoblin to small minds. It's a carefully concieved consistency that eschews the unnecessary and provides the mininal syntax and punctuation that will provide sufficient power to perform the task at hand.
You won't be able to concoct impressively obscure one-liner's in Python. You'll probably have to type a few more lines to get the job done. However, they won't be peppered with braces and semicolons and endless parsing subtleties that can occasionally bite even the immortals of Perldom. (I've read articles by the vaunted Randal Schwartz detailing how this or that aspect of "my" vs. "local" and scoping has cost him hours of debugging!)
I've also read several of Larry Wall's Apocalypses. I note that, in many regards, he's adopting syntax and semantics that are closer to Python and other modern languages. For example I seem to recall that he's planning to replace -> with the . (or accessing members and methods of objects) just as it's used in Python, Java, and C++ (and Lua?). He's going to change the nature of variables so they become references by default rather than requiring explicit \$ and similar syntax. I could go on, but it would belabor the point.
Considering all of this I am left with the conclusion that the best practice one can recommend for Perl programmers is to adopt Python.
JimD
Mostly Redundant for Python Posted Oct 11, 2005 9:56 UTC (Tue) by NAR (subscriber, #1313) [Link] However, they won't be peppered with braces and semicolons and endless parsing subtleties that can occasionally bite even the immortals of Perldom.No, they will be bitten by strange IdentationException errors during runtime. Usually the actual identation error is hundreds of lines away from the line number reported by the python interpreter. There's no free lunch...
Python Indentation Red Herring Posted Oct 11, 2005 15:38 UTC (Tue) by mkc (guest, #2047) [Link] I've been programming principally in Python for over five years, and I have never seen an IndentationException, nor seen any code (mine or anyone else's) that had a bug caused by ambiguous whitespace.
I do think that the Python spec should be changed to disallow tab characters as indentation in Python source. But given that there are multiple means to detect the problem, and that it is virtually non-existent in practice, it's a pretty academic issue.
If this seems like the thing most bothersome to you about Python, why not suspend this judgement for a while and give it a try? Speaking as a former Perl programmer, I don't regret doing so for a minute.
Python Indentation Red Herring Posted Oct 11, 2005 16:19 UTC (Tue) by carcassonne (guest, #31569) [Link] If this seems like the thing most bothersome to you about Python, why not "suspend this judgement for a while and give it a try? Speaking as a former Perl programmer, I don't regret doing so for a minute."
OK, sure. What's the Python equivalent to Memoization ?
Are there as much modules (or extensions or whatever) in Python that there is in Perl ?
The language is one thing. The libraries (or modules or extensions) provided with it are also very important. What would be Java without all the libraries ?
Memoization and Modules Posted Oct 12, 2005 20:56 UTC (Wed) by AnswerGuy (subscriber, #1256) [Link] Memoization is a programming technique (even an OO design pattern. The wikipedia article to which I've linked even shows a trivial Python implementation of a memoize function. A more complete recipe for the technique can be found at the ActiveState ASPN Python Cookbook repository. In response to the broader question about the availability of modules, extensions and code samples ... there are many. One could naively say that there aren't as many as for Perl. However I'm not sure that the comparison would be a wise one. In general Python includes more in its base distribution/package. There are over 300 modules included; and the developers and maintainers carefully consider adding more with each release. The question should not be: "Are there as much [sic] modules ...?" The sensible question is: can the corpus of freely available code allow me to do as much and as easily as with Perl. It's a qualitative rather than quantified issue. I won't render an opinion on the answer. That would be a endless debate. The best answer is for you to go to the Python web site, peruse the "Cheese Shop" (a.k.a. the Python Package Index, or PyPI) and perhaps pay particular attention to this wiki page to form your own opinion.
JimD
Memoization and Modules Posted Oct 13, 2005 1:39 UTC (Thu) by carcassonne (guest, #31569) [Link] "Memoization is a programming technique (even an OO design pattern."
Yes, but then it does not necessarily mean that it has to be written from scratch when needed. If needed and if available, why not use it instead of writing it ?
"The question should not be: "Are there as much [sic] modules ...?" The sensible question is: can the corpus of freely available code allow me to do as much and as easily as with Perl. It's a qualitative rather than quantified issue."
Well, even if 'corpus' is a singular word, it reflects in this context a quantity. And when there's quantity, there's choice.
About the quality aspect you mention in a way that seems to hint that on one side there's less but the quality is better, I dunno. I guess I stick with ample choice and amongst that choice, a whole bunch of tested modules.
Funny that on a thread about a new Perl book there are so many replies about Python and so many comments about where to place curly braces in Perl.
Anyhow, thanks for the URLs, I'll check them out.
Python Indentation Red Herring Posted Oct 11, 2005 16:48 UTC (Tue) by NAR (subscriber, #1313) [Link] If this seems like the thing most bothersome to you about Python, why not suspend this judgement for a while and give it a try?I happen to manage some thousand lines of Python code, how else should I have met with that exception? And it didn't had to do anything with tabs - the def statement of a method was indented to 3 characters instead of 4.
Mostly Redundant for Python Posted Oct 11, 2005 18:29 UTC (Tue) by piman (subscriber, #8957) [Link] > No, they will be bitten by strange IdentationException errors during runtime.
Actually, it's during compiletime. For most Python programs runtime immediately follows compiletime, but it's an important distinction because it means if the program actually starts running, there are no indentation syntax errors.
(There can be indentation semantic errors, but in my experience they're not worse or more common than the equivalent kinds of problems in C. Perl avoids this by forcing you to use {}s no matter the size of the block.)
price worth paying Posted Oct 12, 2005 9:59 UTC (Wed) by copsewood (subscriber, #199) [Link] Happened to me once or twice when I was getting competent at Python. Took about 15 to 20 minutes to find and fix bug maximum. Hardly ever occurs now I've written a few thousand lines in the language, and when it does the fix is now fast.
Yes this is a minor cost in changing from Perl to Python, but the benefits that came with this change were much, much greater in connection with my improved ability to code more complex requirements in much less time using Python while being able to think about the problem to be solved and the solution more and having to think about the language less.
The use of the tool should not get in the way of the problem solving, and Python's minimalist and straightforward approach helps greatly in this area.
Book Review: Perl Best Practices (NewsForge) Posted Oct 11, 2005 2:50 UTC (Tue) by dang (subscriber, #310) [Link] This is a really nice book. The discussion of Inside Out objects stands out ( just so that folks don't think that it is all about coding style given the comments here so far ) :)
Perl vs. Best Practice Posted Oct 11, 2005 5:30 UTC (Tue) by ncm (subscriber, #165) [Link] I haven't read the book, but I have no doubt it omits the single most useful bit of "best practices" scripting advice: use a language that is more maintainable than Perl.During the dot-com era there wasn't much else. Python, Ruby, Haskell and OCaml either didn't exist yet, or weren't mature. Nowadays, there can hardly be any excuse for starting a Perl project, unless you plan to delete the code immediately afterwards. Throwaway code was what the language was designed for, and that remains what it's best at. Code that hangs around will have to be read by somebody else (or, anyway, again). A language that doesn't just encourage, but practically forces cryptic, idiosyncratic usage may be fun, but don't confuse that with industrial good practice. (May heaven forfend anyone taking this as a recommendation to use Java.)
Perl vs. Best Practice Posted Oct 11, 2005 6:19 UTC (Tue) by Cato (subscriber, #7643) [Link] Perl makes it easy to write all sorts of code including maintainable code and spaghetti - that's why it demands a higher level of skill to write good code, but it is quite possible by following some simple rules (less complex than this book). You should take a look at CPAN - over 2,500 modules of distinctly non-throwaway code that stands as an eloquent refutation of your predictably biased position. If Perl is such an awful language, encouraging unmaintainable code, why on earth would people invest time in writing (and maintaining!) so many CPAN modules? Many of these modules have been around for a long time (think Net:*, LWP, DBD) so they are clearly quite maintainable.
Perl 6 will make it easier for people who can't hack Perl to call into the amazing CPAN codebase, getting the best of both worlds. As it happens, I quite like the performance of OCaml and have written Python, but Perl is much more flexible, particularly with regexes embedded in the language, it just feels more comfortable.
Perl vs. Best Practice Posted Oct 11, 2005 7:45 UTC (Tue) by job (subscriber, #670) [Link] Ridicolous. While it is possible to write unreadable code in Perl if you really want to, it is not harder to write readable code in it than any other language. It doesn't force cryptic syntax on anybody. It's not for theoretical purists, just like C. But it is high level and very productive. And it's got CPAN. I think the only drawback of Perl is that it's too broad, so for example there is no single framework for web programming that development can concentrate on.
Perl vs. Best Practice Posted Oct 13, 2005 23:43 UTC (Thu) by pynm0001 (subscriber, #18379) [Link] Thanks for calling my scripts throwaway, idiosyncratic code. :PI'll admit that Perl is harder to write clear, maintainable code in. But don't confuse that with code meant to be deleted. And although I would start new projects in Ruby nowadays, the fact remains that in many circumstances the choice right now is between Perl and Python, and I'd choose Perl in half a heartbeat over Python.
Perl vs. Best Practice Posted Oct 14, 2005 21:42 UTC (Fri) by sfink (subscriber, #6405) [Link] Ah, the maintainability myth, proven and disproven only by assertion.
I have both written and maintained large bodies of C, C++, Java, and Perl code. All of them can be awful, and all of them can be decent. Generally speaking, C is easier to maintain than C++, though of course that depends heavily on the feature set used by the C++ authors. Template specialization is a particularly nasty source of maintainability problems. I would rate C++ and Java as about the same, though for different reasons. Java always seems like it should be good, but it seems to require an awkward amount of bookkeeping and busywork that obscures the main point of the code.
Perl has the highest variance of all four; bad Perl is undeniably the hardest to deal with. Only large shell scripts have caused me more headaches. But I was surprised to find that good Perl is the easiest of all to maintain. I have come back to a Perl project over a year later, and found I could slip back into the mindset of what is going on. Similarly, modifying someone else's large Perl program is a breeze compared to any of the other languages.
I attribute it to two factors: first, 90% of properly written Perl code is about the exact task at hand. It has numerous ways of getting the language to do your bookkeeping for you. Second, and related, there is a fairly small set of Perl idioms that even intermediate Perl programmers all tend to learn, and the choice of idiom tells me much about the intent of a chunk of code. It's the dark side of orthogonality: you can use the same construct in any situation without it interfering with anything else, but that means that when you're looking at the construct in isolation, you can't tell what it might be used for. You end up having to hold a bunch more code in your head in order to figure out what's going on. It's a lot like listening to someone tell a story in a monotone.
Notice that I haven't mentioned Python or any other scripting language. I have used several others, but not enough to have a valid opinion. I would guess that they would be more similar to Perl than to the other languages. But my main point is that the myth of Perl's unmaintainability is based on solid evidence (bad Perl), but is nevertheless quite wrong when dealing with code worth maintaining (good Perl).
O'Reilly has turned into a pulp mill Posted Oct 11, 2005 19:10 UTC (Tue) by b7j0c (subscriber, #27559) [Link] The number of superfluous perl books they publish is now only exceeded by the amount of pulp they have generated over Java.
By the authority vested in me by the US Forestry Service, I do pronounce this wasteland henceforth known as "the forest that existed before O'Reilly".
Confusion over my post Posted Oct 11, 2005 20:23 UTC (Tue) by felixfix (subscriber, #242) [Link] I did not mean to start a Perl grammar war. I was merely trying to say that the book has a lot of fluff. When best practices include dictating an unusual format for an empty string or one char string for specious reasons, while arguing against other styles because they are unusual, then the book loses a lot of its moral authority.
There's a lot of good stuff in the book, but there's a lot of fluff included just to pad it out.
|
|||||||||||