Perl Medic 194
Perl Medic | |
author | Peter J. Scott |
pages | 312 |
publisher | Addison Wesley |
rating | 8 |
reviewer | Craig Maloney |
ISBN | 0201795264 |
summary | A great collection of Perl wisdom and tips for experts and other patient Perl acolytes. |
One of the goals of Perl Medic is to transform code from stylistically poor and unmaintainable into stylistically sound, maintainable and testable code. The format of Perl Medic is very similar to books like The Pragmatic Programmer or The Practice of Programming. Perl Medic shows the reader best practices by example. Some of the chapters are checklists of practices that will help improve your ability to manage and wrangle the code, while others are lists of patterns and practices you should avoid, and should replace with the examples provided. This format very readable, and provides an excellent forum for gleaning what ways to improve the code.
Perl Medic is designed with experienced coders in mind. Topics are presented as if the reader may be using these ideas already in their code, whether good or not. While the advice is good, the presentation may be confusing for beginner and intermediate programmers who aren't intimately familiar with the concepts. I found myself re-reading several topics to try and grasp what the author was trying to convey. After several readings of the section on test harnesses, I still needed help, and ran to the Perl documentation to better understand what the author was saying. Certain advice is also presented, only to have it countered in the next section. Most Perl programmers are familiar with the '-w' switch, which turns on warnings in a Perl program. The pragma 'use warnings' is introduced as a way to turn on warnings for just the code being worked on without displaying the warnings of the modules included in the program. In the next section, the author points out that it might be a good idea to put '-w' in there to see if there are any issues in the modules you may be including. While this advice may be intuitive for experienced Perl coders, the beginner may be confused. "Should I use '-w', or should I use 'use warnings'" she may ask herself.
The book also suffers from a case of being too brief in some sections. In section 2.3.1 (Gobbledygook) the reader is directed for help on how to turn a partially obfuscated program into more intelligible code; a very useful skill indeed. The author redirects the reader to section 4.5 where the utility perltidy is discussed with further detail, but before ending the section, the author also introduces the module 'B::Deobfuscate' along with a URL. No mention of how to use it is provided. In section 6.4 (Debugging Strategies) the author gives advice on how to debug a program. His advice: "Divide and Conquer". While there is debugging advice throughout the book, it's a little frustrating to see a section specifically designated "Debugging", with only one subheading under it. The organization of some of the topics feels artificial, and perhaps should be reorganized in future editions.
Underneath these faults, though, Perl Medic is a great book. Chapter 11 (A Case Study) should be required reading for coders inheriting Perl projects. This chapter is a blow-by-blow account of the author's work in transforming a simple LDAP application from Perl 4 into a robust Perl 5.8 application. The author is very candid about what decisions were made in the code transformation, and why certain elements were addressed in the way they were addressed. One particular element is an elderly module used for the LDAP lookups themselves. The author details the process used to determine a better module to replace this module, and guides the reader through each of the steps required to change the code to use this new module. The decisions the author uses to make this code work under the new environment are enlightening for anyone planning a migration of Perl code into a newer environment. Chapter 7 contains the versions of Perl from Perl 4 up until 5.8.3, and elaborates on what changed between the versions (very helpful for those who are planning an upgrade from 5.003 to a more recent version of Perl). Chapter 9 (Analysis) has very useful tips for not only debugging you program, but for using the Perl Debugger and getting the most out of your debugging session.
Perl Medic is recommended for anyone who is tasked with maintaining or writing Perl Code. While the examples are written with experienced coders in mind, beginners will do well to use this book for areas to focus on while they learn the language. Inheriting code can be a daunting task, but with a book like Perl Medic, you'll have the tools at hand to help ease the work ahead into a more manageable task. And you'll make it easier for "the next guy".
You can purchase Perl Medic: Transforming Legacy Code from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
The thing about Perl... (Score:3, Insightful)
Preventative and maintainance coding is difficult enough when a language has a particular idiom you can follow. Perl gives you an unparallelled freedom of expression and with it several confusingly different ways to achieve the same task.
I used to be a believer, but now it seems Python is ready to take the yoke, at least with those of us who wonder how can you build a complex yet maintainable script without static typing.
Re:The thing about Perl... (Score:2)
Some kind of optional static typing is a recent Python design teapot-tempest [artima.com], but Python is most definitely not statically checked as of this writing.
Of course, how you edit [slashdot.org] really matters most...
Comments to come: blah, Perl hard to read/maintain (Score:4, Funny)
You can inherit shit in any language.
Re:Comments to come: blah, Perl hard to read/maint (Score:5, Insightful)
do { thirty(); things(); in(); a(); list(); unformatted(); } if($foo);
Doesn't mean that you should.
One of the brilliant aspects of perl is that it allows you to write code like you think about code. Well doesn't that presuppose that other people are going to think about code the same way you do? Ooops.
Books and books have been written on the need for code formatting, syntax, and variable naming conventions in languages that are twice as rigorous and disciplined as perl. In perl, the need is double.
So I guess what I'm saying is that although shitty code is shitty code in any language, perl provides the possibility for a certain depth and richness of shit that just isn't accomodated in other languages. Kudos to the authors for addressing what is a real problem with a powerful and widely used programming language.
Yep. Strictly typed languages help (Score:1)
It forces the compiler to treat code without explicit declarations of types to be treated as errors. It also prevents undeclared variables from being used due to spelling errors.
For example in C++ you have to do
int test1 =0 or
int test1
before you can use it in code. Earlier versions of C did not do this and created alot of hassles.
Also many gnu C++ programs were not that well written b
Re:Yep. Strictly typed languages help (Score:2)
It forces the compiler to treat code without explicit declarations of types to be treated as errors. It also prevents undeclared variables from being used due to spelling errors.
Re:Yep. Strictly typed languages help (Score:2)
If I recall correctly (and as you would expect) the book discusses using strict.
Re:Yep. Strictly typed languages help (Score:2)
"strict refs" sometimes bites me in old code that I've inherited and don't have time or permission to rewrite, though.
Re:Comments to come: blah, Perl hard to read/maint (Score:2)
Totally right! No need for ():es when you have a suffix 'if'. You should end it .. if $foo;
Only joking.
Seriously, I second your position; Perl breaks all the rules but works anyway, given some discipline. It is both powerful and fun.
If I get a choice, I use it for everything.
Re:Comments to come: blah, Perl hard to read/maint (Score:2)
While that point of view does have some merit, it also points out the worst failure of Perl. Far to many people do almost no thinking about their code and then get to live with just what they bargained for. Sadly, any later maintainers didn't bargain at all but still have to survive the mess created in the mean time. In se, this "why would I need to think" attitude is not a problem of Perl, but Perl does i
Re:Comments to come: blah, Perl hard to read/maint (Score:4, Insightful)
You can inherit shit in any language.
That is true, but perl does provide easy ways to write sloppy or unmaintainable code. That's not necessarily a bad thing, because it is exactly that looseness that makes perl a very fast language to develop quick scripts in - there aren't anywhere near as many hoops to jump through and TIMTOWTDI makes it very easy to just write whatever you're thinking. For the niche of a language that lets you knock together something to do the job quickly perl is fine.
If you want anything maintainable you need to forget all of that and make use strict and use warnings mandatory, and enforce some coding style standards. That can be done, and if you do that it is easy enough to write maintainable perl - it's just that you can't expect the language to help you with it much: you have to enforce and police the standards yourself.
Jedidiah.
not just for legacy code (Score:5, Informative)
Re:not just for legacy code (Score:4, Informative)
(Normally I'm a grammar/spelling nazi for myself... but I've been coding in PHP all day and I've lost the will to fight for correctness.)
Using a new language is usually not an option (Score:5, Insightful)
In many corporate cases, you don't have the luxury of writing in any language you please and, even if you do, in most cases you'll have an uphill challenge convincing a PHB that rewriting from scratch in a new language is the better proposition.
Re:Using a new language is usually not an option (Score:2)
Re:Using a new language is usually not an option (Score:2)
You can become the saviour. Just for gods sake don't tell anyone you're using lisp, or else you'll never get it done.
No problem. (Score:5, Funny)
When this happens, just write a Perl script to sort out the parts you need to know and print out a nice little summary.
Maintainability of Perl code? (Score:4, Insightful)
Cue the flood of 'Perl is hard to maintain/read' and counterflood of 'You can write hard to maintain/read code in any language' posts.
I think it can be generally agreed that due to the TMTOWTDI philosophy behind Perl, there can be complications involved when inheriting code from others who use a different style and different approach. (Obviously due to the many ways any given task can be approached).
One (common?) approach to dealing with this seems to be to use different languages such as Python or Ruby. Arguably, however, if more coders stuck to code style guidelines and used best practices instead of quick hacks, the problem would be minimal, or at least no worse than other scripting languages.
Re:Maintainability of Perl code? (Score:1, Insightful)
1) too much punctuation
2) too much "magic"
3) too much scaffolding to do object-oriented programming
4) just a shitty data model
5) shitty object model. Do you want to do some setup to yo
Re:Maintainability of Perl code? (Score:2)
Really I have tried writing clear Perl code, but it's always "not quite there"...
And you blame the language for that? How convenient.
Re:Maintainability of Perl code? (Score:3, Interesting)
1. No one will argue against perl having too much punctuation. It's a hell of a noisy language, and you can really play some perl golf with sigils if you try. Sometimes you even have to, but rarely.
2. The "magic" also makes things easier to read. "open $file or die" anyone? Sure beats checking whether it returns nonzero, don't it?
3. Then use one of the Class:: modules. Personally, I rather LIKE t
Re:Maintainability of Perl code? (Score:1, Funny)
That's being a true Perl programmer. Never make it easy for someone to read your stuff.
Re:Maintainability of Perl code? (Score:2)
Sorry you had so much trouble with the comprehension.
Re:Maintainability of Perl code? (Score:2)
IF the only magic I had do deal with was 'open or die' I would be jumping with joy. There is plenty of other magic, for example the whole context changes meaning of operators significantly.
I value consistency in a language... Larry's whole 'postmodern' thing aside.
Re:Maintainability of Perl code? (Score:3, Insightful)
Re:Maintainability of Perl code? (Score:1, Troll)
That is so incredibly lame, I can't even find the words.
Re:Maintainability of Perl code? (Score:2)
That doesn't spell "Don't do what I say, do what Larry thinks I mean"
Re:Maintainability of Perl code? (Score:1)
Tell me, between those two programs (that do exactly the same thing), which is easier to read ?
(I had a mycat.c file to show too, but it didn't pass the filters
/**** MyCat.java ****/
package net.beuarh.lasher;
import java.io.BufferedReader;
import java.io.File;
import java.io.IOException;
import java.io.FileNotFoundException;
import java.io.FileReader;
public class MyCat {
public static void main(String[] args) {
if (args.length != 1) {
System.err.println("Usage : " + MyCat.class + " <file_
Re:Maintainability of Perl code? (Score:2)
These features are really, really, nice to have, when you're hacking, or writing up quick little scripts to do some administrative task. It's nice to have the option of brevity when you have a high level of comfort with the language. But these options ARE a detriment to maintaining stylistic conformity.
The
Re:Maintainability of Perl code? (Score:2)
nice perl is possible (Score:5, Insightful)
Re:nice perl is possible (Score:1, Funny)
Re:nice perl is possible (Score:1)
Perl has always been a write only language that is only readable by the author. I've lost track of the number of modules on cpan.org that are stuck at version y.xx and have not been updated in a long time and only work with versions of Perl *OLDER* than 5.3 because no one is able to correct the module to work with perl v5.3+
Re:nice perl is possible (Score:5, Insightful)
Funny. I'm supporting an app initially written about 8 years ago entirely in perl. It is about 80K lines. Outputs PDF by writing postscript directly (don't ask, but there are reasons for this). I came in about 3 years ago on it. None of the original developers (nor the original company) are around. Somehow, we still maintain an improve it. Maybe it isn't such a write-only language.
I've lost track of the number of modules on cpan.org that are stuck at version y.xx and have not been updated in a long time and only work with versions of Perl *OLDER* than 5.3 because no one is able to correct the module to work with perl v5.3+
I assume you've also lost count of all the C, Fortran, PHP, Pascal and Java projects that don't work in modern environments, too.
Bottom line: If you can write good code in any language, you can write quality perl. Bad perl is easier to write than some languages, and I think that is a sign of utility. And don't get me started on some of the _bloody fucking awful_ Java I'm also supporting...
Re:nice perl is possible (Score:1, Insightful)
I have just inherited code that resembles just that: function calls with no arguments. They don't use strict, so all variables are global. The subroutines are little more than macros, and you have to refresh yourself on what variables are affected each time you see a function call.
I think Perl's major flaws stem from not having "use strict" on by default. If it doesn't need strict, it can probably work just fine in shell script!
Maintainability (Score:5, Insightful)
Baloney. The advantage of Perl is that you have the option to write maintainably if you want to!
If I just need a quick solution to a problem, I can very quickly write gibberish that does the job and then forget about it.
If I'm writing a big app which someone will inherit from me, I can avoid confusing constructs for something easier to follow. I can pass variables in Perl style, C-style, I can use objects if I want. Whatever I think will be most maintainable for somebody else.
Just because you can write gibberish in Perl doesn't mean you can't write good stuff too.
Re:Maintainability (Score:1, Insightful)
Maintainability vs. Extensibility (Score:1)
As explained above, many perl programs are no longer maintainable because of the extensibility of the language. As some perl modules rise in popularity, some fall - an example is the old LDAP library mentioned above that is no longer usable on new perl versions.
For quick hacks, if it can be done with awk, I will do so. If it requires date processing, I will use gawk. I am not above shelling out to ldapsearch from awk because I will have to maintain fewer complex package installations.
I will only fall ba
no perl scripts should forget... (Score:2)
#!perl -w
use strict
Those are the two guidelines required by our methodology.
Re:no perl scripts should forget... (Score:1, Insightful)
Re:no perl scripts should forget... (Score:2)
Re:no perl scripts should forget... (Score:2)
After all, you can't use them without $_.
And defaulting regex to $_ is a very natural thing to do.
I think a rule like this is like saying "Don't shift the car out of first gear! Higher gears kill!". That's not responsible. The responsible thing to do is to create guidelines for clarity. Banishing $_ is not one of them in any sane Perl shop.
Re:no perl scripts should forget... (Score:1)
my @results = map { }
map { }
map { } @a_very_big_array;
(which can be hard to deciper as well as inefficient speed wise when compared to other loops)
Also, if you have a series of regexes, it's nice to have some clue what you are searching through once the assignment to $_ is off the page.
As I said here [slashdot.org], I think for serious projects, you have to really strict with guidelines when usin
Perl is a write-only language (Score:2)
For other languages there is -Wall -Werror. On a better OS use ${BDECFLAGS} instead of -Wall :-)
Re:Perl is a write-only language (Score:2)
For other languages there is -Wall -Werror.
We're talking about Perl here -- what has Wall got to do with it?
Re:Perl is a write-only language (Score:2)
Perl has a Wall.
Larry Wall.
or you can do "perl -cw" for compile and warn... because you can compile perl [perl.org] if you really want to.
Re:Perl is a write-only language (Score:2)
Perl has a Wall.
Larry Wall.
Ah, you've heard of him. Good. I'd assume this means you got my joke. I'm glad it wasn't too subtle.
If you liked Peter's book, attend Peter's workshop (Score:3, Informative)
I agree, perl medic is a great book, influential in encouraging and developing good habits.
Peter will be speaking, though not on the same topic, at YAPC:2005, June 27, 28, 29 in Toronto. There's a whole day's worth of workshops on perl6, including PUGS, most of a day on testing, as well as threads on DBI, CGI, and lots of other workshops. Register now! [yapc.org] At $85US for registration, it's the best bargain you'll find this year.
If you are planning to attend, Book your hotel room soon. The host hotel is only guaranteeing room availability till next weekend. There's a huge conference coming to Toronto a few days after YAPC, so the hotel wants to start making rooms available for early arrivals. Not that all the rooms will disappear the first day, but you wouldn't want to be disappointed, would you?
I don't need a medic... (Score:2, Funny)
Perl is too clever (Score:1, Insightful)
While the TIMTOWTDI philos
Re:Dupe? (Score:1)
Re:Dupe? (Score:1)
Search first next time...
Re:What dupe? (Score:1)
Re:Chapter 1: Installing Python (Score:1)
Perl gives you enough rope to hang yourself. If you are disciplined, it is powerful enough to do anything cleanly, quickly, and efficiently.
Re:Nay (Score:3, Informative)
Re:Nay (Score:2)
Re:Nay (Score:2, Interesting)
Okay. Sure. PHP does give some advantages over Perl.. To lazy programmers that is. Really, PHP has over 3125 core functions, while Perl has "only" some 150. Include a module and whoop, some more functionallity, including only those things you need.
Really, how often do you have to look up a PHP function's working (or even name, hence PHP isn't very consistant, something2something, something_to_something, somethingtosomething... the list goes on)? When I haven't worked with PHP for a while th
Re:Nay (Score:1)
array_map is great, but requires an extra function. map{} can handle pretty much any perl code instantly, without any extra subs or other weird constructs. While it's not a "real" problem, I am annoyed at PHP for the fact that I have to write a whole function for every simple map I want to perform, whereas perl can do the
Re:Nay (Score:2)
Re:Nay (Score:2)
Perhaps PHP5 is more sane. PHP5 looks reasonable, though I suspect it still inherits all the silly 3000+ global functions of its parent, and still requires you to bracket even commandline scripts with <?php ?>
Re:Nay (Score:3, Funny)
Rrrrrrgh. People who suggest Python as Perl replacement are bonkers. People who suggest PHP instead of Perl or Python are clearly insane.
My honest opinion is Ruby beats either as a Perl replacement - Ruby retains a lot of Perl ideas while succeeding in providing a very clean syntax.
And people these days can't even do language trolls properly. Let me try. Ahem. hm. hm. hm. (climbs to mountaintop and shouts:) "We should rewrite the Perl programs in Common Lisp!" (dramatic echo) (gasping heard all over th
Re:Nay (Score:2)
The latest attempt at that is ruby. Ruby is great fun and a neat language but honestly it's just an attempt to rewrite smalltalk in a perl idiom.
Re:Nay (Score:1)
Re:Nay (Score:2)
Re:Nay (Score:2)
Re:Nay (Score:5, Insightful)
PHP was made by taking a cute language for embedding a broken imitation of Perl-esque syntax in-between HTML and extending it with bajillions of functions that badly needed to be namespaced. It never provided anything useful that Perl couldn't, except that it made newbies comfortable by making them feel like they're in "HTML land" instead of "Programming language land."
Not just the naming of functions (Score:1)
Re:Nay (Score:3)
I'll requote as I share the same opinion. In fact, I'd offer the argument that contrary to the "right tool for the job" advice that gets
Re:Nay (Score:1)
Re:Nay (Score:5, Insightful)
I hate the language for its utter lack of consistency. People talk about how great the php.net documentation is but I think they have the causality reversed: those docs have to be excellent or the language would be unnavigable. I have no desire to remember 3500 core language functions with similar (but inconsistent) naming systems and a randomized argument list. Seriously, what were they thinking?
I don't think PHP is inherently bad, but the current implementation certainly is.
Re:Nay (Score:2)
Why? cuz the Gnu people can't have a monopoly on weird names, damnit.
Re:Nay (Score:2)
Re:Nay (Score:2)
It stands for "Pre Hypertext Pages". It was supposed to be similiar to C/C++
Basically the creater wanted to make specific tags and code in his homepage that apache would read first and run before teh html is processed and sent, in order to see how many employer
Re:Nay (Score:1, Informative)
Actually, you're totally wrong.
"It stands for 'Pre Hypertext Pages'."
No, no, and no again. It never stood for that, not once, not ever. I'm not even going to dive into the rest of what you wrote, I'll just back myself up with real facts, unlike yours.
I quote: [php.net]
"PHP/FI was created by Rasmus Lerdorf in 1995, initially as a simple set of Perl scripts for tracking accesses to his online resume. He named this set of scripts 'Personal Home Page Tools'.
Re:Nay (Score:2)
Php/FI is not PHP in its current form. But I did assume it was. The scripts were read in on apache but I do nto know if it were originally a set of cgi scripts or were they actual apache mods like modern incarnations are.
Re:Nay (Score:2)
Re:Nay (Score:2)
Re:Perl != maintainable (Score:1)
Re:Perl != maintainable (Score:2, Funny)
Than coding in what? Perl?!?
Re:Perl != maintainable (Score:2)
Re:Perl != maintainable (Score:3, Funny)
I've switched to Ruby (Score:2)
Re:Perl != maintainable (Score:2)
Re:Perl != maintainable (Score:1)
Re:Perl != maintainable (Score:1)
Re:Use a real language. (Score:5, Insightful)
Perl 1.0 cpu time 11 lines of code.
gcc 0.3 cpu time 182 lines of code.
So i can distort reality also and say while C can sometimes be as fast as 3 times faster it will take 1700% more lines of code.
Re:Use a real language. (Score:1)
Re:Use a real language. (Score:1)
print scalar split
Re:Use a real language. (Score:1)
I got bored, so I came up with a couple more ways to do it, but this was the only one-liner I came up with before I lost interest. Compressed, just to make it interesting.
Re:thanks for straightening me out. (Score:3, Interesting)
Are compiled languages faster than script style languges? Yes, typically. Are compiled languages always the best approach. No.
Lets take a real world example. Recently I need to take a stream of data that was interleaved two byte time series. I had to demultiplex it and reverse the endian. I prototyped in perl and wrote the service version in C. Performan
You're missing the point (Score:2)
For example, I recently put together a reporting system. It's all scripting and Java. Could it run faster if it was all in C? Undoubtedly. However, it's only going to run once a month, so whether it takes 20 minutes or 22 minutes to crunch the data is utterly unimportant. Writing it in C would simply be premature optimization.
Re:Doubles development time. (Score:2)
Re:Use a real language. (Score:2)
Since Rex-Exp is pattern matching from the benchmark link provided for test called Reg-Exp
Perl 2.56 Cpu Lines of Code 24
C Gcc 2.98 Cpu Lince of code 98
gasp Perl is faster.
Re:Use a real language. (Score:2)
Also, for true speed increases in Perl, don't use the RegEx engine. Use hashes. That alone will speed you Perl program exponentially.
Re:Use a real language. (Score:1, Interesting)
On behalf of those of us who understand what this word means, I ask you to stop using it until you join us. (Hint: it doesn't mean "a lot".)
Study some Big-Oh notation, or more generally asymptotic notation. You should at least know that:
Re:Use a real language. (Score:2)
Re:Use a real language. (Score:2, Insightful)
Sometimes the developer's time is more important that the computer's time.
Re:Use a real language. (Score:2, Interesting)
Running a "BOT" on the MSN Messenger network. Sending a 300 meg ISO to it, memory only "shot up" by an "amazing" 100KB. Average speed on sending, 150KB/s (as good as it get's on my connection).
Now we hook up another conversation. Response time is excellent, transfer is not suffering nor are other connections. Ping time is 0.0788 seconds (that is, me server perl app, so it has to pass 4 "pipes", 2 to m
He speaketh the truth (Score:1, Interesting)
Re:New language versions break code? Unforgivable! (Score:2)
Back in the early to mid-1990s, Perl made programming accessible to people who would have struggled with systems programming languages like C or C++. The alternative, shell programming constructs, did not provide the rich set of features provided by Perl. Unfortunately, Perl's use by novices and the "101 ways to do the same thing" approach has left a legacy of spaghetti code written in dozens of weird idioms.
Amongst the Slashdot readership, there are a lot of these novice programmers (although some of are