Slashdot Mirror
Perl Medic
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.
Cause you know the vast majority of old perl is better off re-written.
What now? Duplicate book reviews?
All true wisdom can be found in sigs.
Alternatively, just reverse engineer the system and write in a better language.
The Real Solution to Perl is...
PHP (or better yet, LAMP)
The dangers of knowledge trigger emotional distress in human beings.
...but I mean it: The best 'transform' you could make to your old legacy perl code is to port it to python or ruby.
Generally, bash is superior to python in those environments where python is not installed.
Who Is Pamela Jones?
By Maureen O'Gara
Friday May 6, 2005 - A few weeks ago I went looking for the elusive harridan who supposedly writes the Groklaw blog about the SCO v IBM suit.
The now-famous opinion-shaping open source leader Pamela Jones, aka PJ, doesn't give conventional face-to-face interviews. Never has, near as anyone knows. All communication is virtual. Only one person in the world has ever claimed to have met her - in the pressroom at LinuxWorld in Boston complete with a Pamela Jones badge - and described her as a fortyish reddish-blonde who giggled a lot.
Oh yeah? Wonder what cold crème she uses.
Pamela Jones is a 61-year-old Jehovah's Witness who lives in a shabby genteel garden apartment in desperate need of an interior decorator on a heavily trafficked commercial road at 304 North Central Avenue in Hartsdale, New York. Hartsdale is in Westchester and Westchester is IBM territory.
See, even though Groklaw treats cell phones like they were Kleenex and changes its unpublished numbers regularly, one number it left with a journalist led to this flat and - wouldn't you know it but - some calls from there had been placed to the courts in Utah and to the Canopy Group so obviously this just isn't any Pamela Jones.
Pamela has lived in apartment 1A for 10 years at least, according to the super, who says he's watched people move in, have children, and the children marry and move away.
Now, this isn't your usual anonymous New York apartment. It's practically a self-contained village where the super goes for the old ladies' groceries when there's snow on the ground and people know each other's business.
But the super didn't know much about Pamela except that she had a computer, worked at home (maybe sometimes) for a lawyer, was "paranoid" - his word - and "sensitive to smells."
He remembered how he was cleaning paintbrushes one day and she came running down the stairs screaming "Fire."
She was also missing and had been for weeks.
Nobody there knew where she was.
She had up and disappeared one day, and the super was worried about her. He said her son had dropped by and he didn't know where she was, and that some strange man that "nobody knew," as the super described him, had tried to get into her apartment while she was gone - the Medeco lock she had had installed on her door - something nobody else in the complex seemed to feel a need for - was more expensive than the door. But, as it happened, the super said, she had just sent in her rent in an envelope postmarked Connecticut.
Like an episode out of "Where in the World is Carmen San Diego," the trail led to 10 Bittersweet Trail in Norwalk, Connecticut, 24 miles away. Sure enough, parked in the driveway was Pamela's car, just as the super had described it, a dark gray '90s Japanese number with a bunch of Jehovah Witness pamphlets tossed on the backseat.
The woman at the house, Barbara Sharnik, told a disjointed story. She didn't know Pamela, Pamela hated her, Pamela wasn't there, Pamela left her car there because it got bumped, Pamela left her car there because she left town, and so on.
Afterwards Barbara called the cops, and then the cops called the number we left with her and the cops said that she was Pamela's mother and that Pamela was on the run and had shacked up with her mother because she had gotten "threatening mail" weeks before and that she had just gotten spooked again because "people were getting hurt around [my] stories" and had lighted out for Canada.
Odd, the subject of my stories - or any stories - never came up during our brief interview. I was just looking for Pamela.
That left Pamela's son, Nicolas Richards, who, as it happens, had been in the software business in Manhattan until - why, my goodness - things seem to have come a cropper right around the time Groklaw came into existence.
Nick and his ma were apparently involved together in Medabiliti Inc, an ISV, because one Pamela Jones with a Westche
I'm sorry, I used Perl for many years, and of all the languages I've used, it's by far the least maintainable, even compared to LISP!
This is the key reason Python is replacing Perl in most places.
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
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.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
s/shitty perl code/shitty code in any language/;
You can inherit shit in any language.
This is the best book I've ever read about how to write clear and maintainable Perl code. The advice is solid and up-to-date with discussions of perltidy, modern web techniques, etc. I would recommend this book to anyone who writes Perl, just as a style guide.
In most cases, refreshing an existing program will take less time than rewriting it in a diffferent language, as in both cases you need to have a firm understanding of what the program does before proceeding.
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.
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
Perl, does in fact, run 4x slower than C. If your program requires speed and maintainability, then stick with a real compiled language. Anything else is a scripting language and should be used appropriately.
When this happens, just write a Perl script to sort out the parts you need to know and print out a nice little summary.
What has /. come to? Preemtive "dupe flames"? :D
Generally, bash is superior to python in those environments where python is not installed.
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.
Business Voyeur
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.
if self.sanity_questionable?
:perl }.each do |script| :ruby)
:ruby }
raise "I'm waiting for Perl 6 you insensitive clod!"
end
scripts.select { |s| s.written_in?
rewriter = Rewriter.new(:perl,
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 =>
I have been a "Perl Medic", and re-wrote old perl with new perl - much better.
Perl gives you enough rope to hang yourself. If you are disciplined, it is powerful enough to do anything cleanly, quickly, and efficiently.
I think I'll just crank up my written in perl browser, and use my written in perl email client on my written in perl operating system and use my written in perl command line to run "wc" written in perl.
Scripting languages are obviously the solution for all problems, including fast word counting !!!!
Yeah, but perl makes it easier to write shit. I happen to love perl and use it all the time, but I also have to be very disciplined about the aspects and particularly syntax conventions of the language that I use, in order to write readable perl. Just because you can write:
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.
-- Truth goes out the door when rumor comes innuendo. -- Groucho Marx
s/shitty perl code/shitty code in any language/;
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.
Craft Beer Programming T-shirts
#!perl -w
use strict
Those are the two guidelines required by our methodology.
https://www.accountkiller.com/removal-requested
For other languages there is -Wall -Werror. On a better OS use ${BDECFLAGS} instead of -Wall :-)
In Soviet Washington the swamp drains you.
Longest pregnancy every, since 2001.
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.
but the fact that some alter their argument in-place, others return a value...and no rhyme or reason to this. php is the ultimate toy that survives only by virtue of the fact that it is easy to install
Out of curiosity, how come this posting lists the body byte count on the /. home page and the other postings don't?
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! 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?
Some of the code I've been forced to maintain needed Dr Kevorkian.
self.profit!
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 back to perl when I need access to system calls or other facilities that the more primitive UNIX tools do not provide (and I am not willing to write the utility in C).
I do this because I like easy portability. Perl's extensibility precludes this approach.
no comment.
again. There are people pla7ing can
While Perl has gotten a bit of a bad rap because it's a disaster of a language, what kind of future do you envision for efforts to improve it, like Python?
Solution to shitty Perl Code:
Python.
I've used both commercially - give me Python anyday.
You infidels.
Ask any VB developer about the 'Option explicit declaration' (I think thats the name? Its been years since I touched it)?
:-)
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 before the even of gcc 3.x which treated some warnings as errors. It was a pain but it improved alot of programs as a result.
Many developers are jr level guys and sometimes system administrators writing scripts. Not everyone can write good code and no one can do it wihtout practice. Strictly typed languages help because it forces everyone to follow a standard.
As you can tell I am not a big fan of perl and prefer python or tcsh for scripting.
http://saveie6.com/
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.
Karma: Excellent (My Karma? I wish...:-( )
note that perl programs NEVER mention the memory footprint or startup overhead in perl programs.
Having written code in Perl and other languages (COBOL, C++, Java, VB, TCL), I have come to the conclusion that Perl as a language is more concerned with being clever than getting the job done. The language has some of the most untechnical keywords (e.g. bless, chomp and others) and it makes it completely laughable (like a toy almost). Also, just look at any of the books and or documention written about perl. They all read like Tom Baker scripts from the 1970s Dr. Who episodes.
While the TIMTOWTDI philosophy of perl is cute in theory, it seems to have backlashed and its now total anarchy. I look at some perl and it's total alphabet soup. And the lame excuse of "just because you can do it this way doesn't mean you should" is like putting warnings on cigarette boxes (just because you can smoke these doesn't mean you should).
This book is not going to save perl. It's way too late for that. Perl will continue to be written poorly by people who think they're smarter than everyone else and will try to write their code to read like Tolstoy rather than for what it is.
GOBACK.
The International Obfuscated Perl Code Competition
:-)
Very similar to the IOCCC. You are given a selection of pieces of Perl code, some of which have been written normally, and some of which have been deliberately obfuscated. All you have to do is tell which is which
For many problems in the busines world, a 12% speed increase isn't worth having if it doubles development time.
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.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Even though I'm still inexperienced at writing Ruby code, I already find it faster to write good code in than Perl.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
I agree!
Perl is hard to read and is hard to maintain. When we write English papers there are expected standards concerning sentences, paragraphs, chapters etc. Perl is way too loose on what it allows.
The guy is demuxing some data and flipping bytes;
so development time went from 5 minutes to 10 minutes. Imagine the poor clown that has to run
10 of these jobs sequentially on Friday at 4PM. With the C implementation he can go home a half hour earlier.
Uh. What's your point?
cat *.file | perl -ane "$c += scalar @F;END {print qq(Counted $c words.\n)}"
1) I get a syntax error with this.
2) So, you jammed two lines into one.
3) "| wc" is a lot easier to type and remember.
when it's calling libraries written in C. :)
...is to write compilers and interpreters for other languages.
for toy languages like Perl. :)
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 implicitly encourage it.
Linux user since early January 1992.
yeah, you better stick to perl.
Why isn't everyone totally unforgiving of the idea that new version releases break existing products? If it's suppposed to be the same language, it's supposed to WORK. Yes, you can "deprecate" things, and suggest that they not be used any more, and even let them be less efficient, but legacy code is not supposed to be broken by the compiler, any more than running the same old code on a newer computer should break. I've been in programming since the IBM mainframe days, and this would have been considered a hanging offense - certainly lawsuit material. Imagine if the phone company decided to change its interfaces overnight and your phone stopped working - that's how ticked everyone should be.
As you already explained: that one can write shitty code doesn't mean one has too. Moreover, I haven't seen any language yet that guides one to write any algorithm in such a way that comments are not needed. There is no programming language that thinks for you. Perl's major problem is the huge number of people who learned it by just peeking at a CGI script and tweaking it to their needs. Same holds for PHP, and hey, isn't the quality of code quite similar? I recently had a long winding discussion with someone who complained how bad Perl was designed (http://groups-beta.google.com/group/comp.lang.pyt hon/messages/7e74fc5dd24047a1,4434b5a10d0e32f8,142 2dd275c9c6e3a,3547b6a0a71c1dfd,dce98f843551d487,dc 30957084149f8e,0fc2b0d1cc84a2c2,4eb114d062008987,d 0257059b4c0f09b,de6a3819b19098d3?hl=en&thread_id=6 d65bbac956ebbb0&mode=thread&noheader=1&q=bokma+per l+skills+python&_done=%2Fgroup%2Fcomp.lang.python% 2Fbrowse_frm%2Fthread%2F6d65bbac956ebbb0%2F4ff432e af904ac53%3Fq%3Dbokma+perl+skills+python%26rnum%3D 2%26#doc_dc30957084149f8e but after some time I got the feeling that just his Perl skills were severly limited.
Perl Programmer for hire
In the book, he advocates reducing lines of code by getting rid of temporary variables where possible. I've never agreed with that philosophy, and I think it's a terrible way to make code maintainable.