Perl Medic

Craig Maloney writes "Anyone who codes in Perl can relate to working on other people's code. Sometimes the code will thankfully include "use warnings" and be a joy to maintain. More likely, though, the code will have so many warnings that the useful output is long gone in the stratosphere of your scroll buffer. Even good code written for earlier versions of Perl can become aged and decrepit, requiring elderly modules that may or may not work with newer versions of Perl. Maintaining this code can be a hassle, but fortunately Perl Medic: Transforming Legacy Code (referred to for the duration of the review as Perl Medic) provides some very useful tips for getting through these migrations, and will help the next person maintaining your code." Read on for the rest of Maloney's review. 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.

Comments

Re:Nay

[Shin Chan]

PHP?! PHP?!?!

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 that starts to faint. Perl never does.

Oh and, rewriting a map{} and grep{} is left as an exercise to the reader ;)

The solution is simple

[Anonymous Coward]

if self.sanity_questionable?
raise "I'm waiting for Perl 6 you insensitive clod!"
end

scripts.select { |s| s.written_in? :perl }.each do |script|
rewriter = Rewriter.new(:perl, :ruby)
rewriter.transform script
end

assert scripts.all? { |s| s.language.clean_object_model? }
assert scripts.all? { |s| s.language.easy_on_the_eyes? }
assert scripts.all? { |s| s.concise? && s.readable? }
assert scripts.all? { |s| s.maintainable? }

self.productivity *= 2

fellow_programmers.each { |w| self.evangelize_language w => :ruby }

He speaketh the truth

[Anonymous Coward]

Actually I had a project that did exactly this at a major financial company. I had to convert their old Perl scripts into Unix scripts because the manager was sick of them breaking when new Perl versions came out.

Re:thanks for straightening me out.

[Camel Pilot]

You are the only one proposing the use of perl for everthing. Ever heard of a strawman, nice try but it is a weak attempt to prove whatever your point is.

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. Performance difference between C and Perl was 12%. Development time, even with the prototype was difference was more than double and with 4 times the code to maintain.

I have similar stats with C versus Matlab for numerical processing.

Re:Maintainability of Perl code?

[snorklewacker]

Not going to intersperse your points with mine, since I really hate that style, so I'll just go in order.

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 that I can have a subclass with a polymorphic constructor, which you can't really get with languages that hardwire the constructor. What the hell is a class factory? Don't need that idiom in perl.

4. It only becomes insane when you start dealing with prototypes and @foo is suddenly an array and not a list. Otherwise this is idiom that anyone can get used to. Frankly, I find it a nitpick -- you want really shitty data models, pick on the insane "scalar" thing, where the string "0" is false in an if statement.

5. This is actually just false. You use BEGIN for compile-time stuff and an import method for import-time semantics. Hard, eh?

Perl 5 is over 10 years old, and showing its age in various ways, but it can still take criticism and even a lot of kicking gracefully. It's the language everyone loves to hate, but when rubber meets the road, it's what you find people using anyway. It's an inelegant crock, it's shell, sed, and awk duck-taped together, but it's exactly what people asked for.

Spare me the bondage of enforced "elegance". If you want Java, you know where to find it.

Re:Use a real language.

[Anonymous Coward]

Use hashes. That alone will speed you Perl program exponentially.

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:

O(1) is constant time
O(lg n) is logarithmic time
O(n) is linear time
O(n lg n) is...I don't think there's a name for it, but it goes here in the sequence
O(n^2) is quadratic time
O(n^c) is polynomial time (for any constant c, including the "1" or "2" that'd make it linear or quadratic time, above)
O(2^n) is exponential time

and be able to find an upper bound on your algorithm. It might not be the best upper bound (I could say an O(1) algorithm is O(n^2) and be right but not terribly informative) but you should at least be able to find one.

You should also know that these same concepts can apply to the space your algorithm requires (in memory, on disk, whatever).

If you don't have something in your program that takes O(2^n) time (and you probably don't), your program can't get exponentially faster. It doesn't make sense.

Re:Use a real language.

[Shin Chan]

Let's see (just a real life thing I tested earlier today... so yes, before this article got published)

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 my app, 2 back to me).

CPU usage stayed below 5% all the time. . The script has been running for nearly 3 days now, too. I'm sure your C app can shave off an amazing 0.01 something seconds and minimize memory usage to maybe only half. Point remains, Perl isn't slow when well written :)