Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Pro Perl Debugging

samzenpus posted more than 8 years ago | from the make-it-clean dept.

Perl 164

Michael J. Ross writes "The typical computer program has more bugs than there are ants at a picnic -- except ants are usually easier to find. Programs written in Perl are no exception, because the compactness of the language does not make any existent bugs easier to spot; they can simply be packed into fewer lines of code. To help remedy this problem, Richard Foley and Andy Lester, two seasoned Perl programmers, offer a new book, Pro Perl Debugging: From Professional to Expert." Read the rest of Michael's review.

This title was published in hardcover in March 2005 by Apress, a relatively new member of the technical publishing world. The publisher has a Web page for the book that includes links to all of the source code in a Zip file, the table of contents in PDF format, and a form for submitting errata. The book comprises 269 pages, the majority of which are organized into 16 chapters: Introduction (not to be confused with the true Introduction immediately preceding it), Inspecting Variables and Getting Help, Controlling Program Execution, Debugging a Simple Command Line Program, Tracing Execution, Debugging Modules, Debugging Object-Oriented Perl, Using the Debugger As a Shell, Debugging a CGI Program, Perl Threads and Forked Processes, Debugging Regular Expressions, Debugger Customization, Optimization and Performance Hints and Tips, Command Line and GUI Debuggers, Comprehensive Command Reference, Book References and URLs.

For programmers who wish to learn how to fully utilize Perl's debugger, what options are open to them? A terse summary of the debugger's commands are always close by, within the debugger itself. Those Perl coders who have yet to try the built-in Perl debugger, really owe it to themselves to give it a whirl. In most cases, it is superior to embedding lots of "print" statements in your scripts, and then wading through the results. Simply include perl.exe's -d flag on the system command line, and you should be put right into the debugger, and see the debugger's "DB<1>" command prompt -- the "1" meaning that it is ready for your first command. To display the aforementioned command summary, simply enter "h", or "|h" to see the output one screen-ful at a time, which you will probably want to do unless your system window can show all of the dozens of lines at once. The command summary is best used as a quick reference, and naturally cannot be expected to serve as any sort of tutorial. Yet it has its use, and for that, it's fine.

Most Perl books devote at least some space to explaining the basics of firing up and using Perl's debugger. The (in)famous "camel book," Larry Wall's Programming Perl, has a chapter on the debugger. It covers breakpoints, running, stepping, tracing, displaying code, commands, debugger customization, debugger options, unattended execution, creating your own debugger, and performance profiling. Aside from that last topic, the chapter is mostly an expansion of the command summary mentioned earlier. It is sparse on examples, and does not cover any advanced topics, such as using the debugger in the context of forking, threads, and POE, as well as the debugger's special capabilities for regular expressions, CGI programs, and shelling out.

The advanced topics are where Pro Perl Debugging really shines in relation to the coverage that I have seen in any other book, partly because the authors have the space to thoroughly explore those topics in depth, and to provide much more meaty examples, with adequately illustrative sample code. Even for the more complex topics, the writing is clear, and the examples are worthwhile.

The authors clearly intend for the book to serve as both a comprehensive tutorial and a reference for the Perl debugger. In both respects, they succeed admirably. But the practical value of their accomplishment could be called into question by any programmer who has grown tired of the limitations of the Perl debugger, and has switched over to any Perl-capable standalone GUI debugger or integrated development environment (IDE). More specifically, watching a variable change value, while stepping through the lines of a Perl script using the debugger, requires that the programmer manually or programmatically echo that variable's value, by issuing a print command ("p") followed by the variable name, one way or another. This process quickly becomes tedious when multiple variables need to be watched, because each individual variable must be printed, one at a time. Admittedly, previously entered print statements can be recalled by using the up-arrow key, but only if the particular command has not been pushed out of the debugger's limited storage. This usually becomes even more frustrating when trying to print the values of indexed arrays, hashes, and nested arrays and other structures. There are workarounds, but none are pretty, and even the most promising techniques still seem to require excessive focusing on the debugger commands themselves, drawing attention away from the code being debugged.

As a result, some disheartened Perl coders eventually switch back to embedding "print" statements in their code. Fortunately, there is a better alternative, in the form of IDEs, which can automatically report the changing values of a large set of variables, none of which need to be typed in, owing to the drag-and-drop capabilities of most IDEs. There are many IDEs available, including freeware and open source offerings. Most if not all of them support advanced editing, syntax highlighting and verification, visual breakpoints, and other much-appreciated capabilities. Even if they were to lack all of these features, and only have the advantage of easily and dynamically displaying the current values of variables, then they would be much more pleasant to use than the built-in Perl debugger. This is especially true in the case of nested structures, which can be expanded with a mouse click within most IDEs. All of this being said, it should be noted that the authors include a chapter that briefly touches upon the most well-known Perl GUI debuggers -- but at only seven pages in length, the chosen applications get only a cursory treatment, highlighting their major features.

Nonetheless, given the intended purpose of Pro Perl Debugging, and its target audience, the book cannot be faulted for its contents nor its approach to presenting the material. Anyone looking for a detailed and competent explication of the native Perl debugger, would likely not be able to find a more thorough treatment anywhere else.

Michael J. Ross is a freelance writer, computer consultant, and the editor of PristinePlanet.com's free newsletter."

You can purchase Pro Perl Debugging from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


I luv Perl, but... (1)

Orrin Bloquy (898571) | more than 8 years ago | (#14240137)

...there's something about an interpreted language which can be optimized down to nearly the size of machine code, only less readable.

Re:I luv Perl, but... (1)

digitaldc (879047) | more than 8 years ago | (#14240341)

...optimized down to nearly the size of machine code, only less readable.

But isn't that the point of writing your own code?

Re:I luv Perl, but... (1)

Phroggy (441) | more than 8 years ago | (#14240690)

What? All perl code is perfectly readable! ;-)

What do you mean by "optimized down to nearly the size of machine code" though? I'm not sure what you're talking about.

Re:I luv Perl, but... (0)

tomhudson (43916) | more than 8 years ago | (#14240767)

..there's something about an interpreted language which can be optimized down to nearly the size of machine code, only less readable.
Big deal. You still need to lead the interpreter, and set up the host environment, etc. Besides, the best way to debug a perl program is to rewrite it in python.

I've been using perl for years, but I'm dumping it for most things.

It took me less time to learn python and write my first utility (a page generator for 195 content categories in2 languages from source data files) than it would have to write it in perl and debug it.

The whole "TMTOWTDI" is just wrong, from a maintainability point of view. If you can't maintain it, you can't really reuse it.

And perl's greediness in matching strings sucks (because someone was too lazy to put proper string functions into the language?)

Perl - because when it all looks like line noise, nobody can criticize the "quality" of your code.

Re:I luv Perl, but... (2, Interesting)

el-spectre (668104) | more than 8 years ago | (#14241746)

And perl's greediness in matching strings sucks (because someone was too lazy to put proper string functions into the language?)

Hey, just cuz you can't write a decent regex...

existent? (0)

Bazzalisk (869812) | more than 8 years ago | (#14240164)

extant, surely?

ants at a picnic? (-1, Offtopic)

Roj Blake (931541) | more than 8 years ago | (#14240168)

Wait, what am I? I'm ants at a picnic? Is that what you just said? I just - I'm ants at a picnic. All right, just making sure.

-Brian Griffin

In defense of print statements (4, Insightful)

winkydink (650484) | more than 8 years ago | (#14240184)

Properly placed and well-thought out, I can leave:

print "a bunch o' stuff\n" if $Debugging;

in my code forever and never have to go through the trouble of firing up an IDE.

Re:In defense of print statements (2, Insightful)

Billosaur (927319) | more than 8 years ago | (#14240486)

print "a bunch o' stuff\n" if $Debugging;

Alternatively, I convert print statements into logging facilities:

open LOG, ">> $log_file" or die "Can't open $log_file: $!\n";
# Magical happenings
print LOG "And this happens here...\n" if $debug_flag;

I can then match things up to my pseudocode and determine if I'm pushing values around the way I should. Of course it's made a a lot easier with "use strict;" and the -w switch enabled.

Re:In defense of print statements (4, Insightful)

hattmoward (695554) | more than 8 years ago | (#14240507)

How many times is that conditional checked at runtime? They can add up. In perl, you could have it optimized away at compile time...
sub DEBUG() { return 1; }


DEBUG and print "value of blah:", $blah, $/;
but... TIMTOWTDI ;)

Re:In defense of print statements (1)

winkydink (650484) | more than 8 years ago | (#14240566)

True that. If designing for performance, perl usually isn't the language choice I make.

Re:In defense of print statements (1)

hondo77 (324058) | more than 8 years ago | (#14241427)

That's cool and I don't doubt you but how do you know that gets "optimized away at compile time"?

Re:In defense of print statements (1)

hunterx11 (778171) | more than 8 years ago | (#14241576)

The Camel Book does talk a bit about optimization: it is documented behavior that DEBUG in this case will be inlined, and that the right-hand side of "0 and" will not be evaluated.

Re:In defense of print statements (1)

5E-0W2 (767094) | more than 8 years ago | (#14241862)

Or you can use constant DEBUG=0; which is perhaps more straight-forward.

Re:In defense of print statements (3, Informative)

Mark_Uplanguage (444809) | more than 8 years ago | (#14241006)

When debugging I emphasize the use of "warn" over "print". It's the same syntax, but the warn statements don't get spooled and therefore their timing is quicker.

This is vital when you code just plain blows up. Using "print" means that a statement which got executed before the disaster may not make it to console, thus leading you to believe that it never got executed. "warn" avoids this problem and thus leads you to the problem more accurately. It also makes it easy to globally comment out the warn statements before going releasing the code.

Re:In defense of print statements (1)

irc.goatse.cx troll (593289) | more than 8 years ago | (#14241230)

While I agree, I'd like to see a GUI ide that lets you fold debug prints down to a single red pixel line or something similar. Just so you can easily keep them around but yet be able to quickly scan through a page of code without being overwhelmed by a lot of prints.
I still think vim is the best development environment, but even gtkvim is just a fancy xterm with a toolbar and menus. Hopefully soon a better developer than I will take vims powerful commands/features and mangle it into a full blown IDE with ctags, graphical debugger, proper folding, intellitext, etc (most of which its capable of doing now, just with an interface too poor to be useful day to day)

Better yet: (0)

Anonymous Coward | more than 8 years ago | (#14241237)

I like to use a hash and a function, so there's a finer control over which sections of code are debugged. That way once a section is working as advertised, I can easily shut off debugging output for it. Likewise, using labels like "normal", "serious", "verbose", or "wtf" can let you escalate the debugging level and drop it back as needed.

$Debugging = 1;
$DBG{'regex'} = 1 * ${Debugging} * 1;
$DBG{'html'} = 1 * ${Debugging} * 2;
$DBG{'higher'} = 1 * ${Debugging} * 4;

sub debug
local ($type, $text);
$type = shift;
$text = shift;
if($DBG{$type}) {print "[DBG $type: $text ]\n";}


debug('html',"got to $i, $_");
debug('another_level',"this won't print");

Re:In defense of print statements (2, Interesting)

Baron von Leezard (675918) | more than 8 years ago | (#14241263)

The issue of whether to use a debugger or not is a matter of speed and ease of debugging. There's few things you can't do with print statements that you can do with the debugger. [There are some: try using printf to get a backtrace of a segfault in C.] Lacing your program with print statements to check values is a time consuming, annoying, and certainly uglifies your code. Worse still, if you didn't anticipate wanting to see the value of some variable in advance, you will have to modify your program, (compile it), restart it, and get back to the point at which the bug is occuring--in some cases this can be very time consuming. With a debugger you don't have to anticipate anything. And you can modify values, which is often quite useful. [In Perl, as opposed to C, you can basically do anything you want in the debugger, including replace subroutines with new versions.] In some debuggers you can even try some stuff and then restart the current subroutine and step through it again from the beginning by popping the stack! [I'm not sure if you can do this in Perl, but gdb lets you do this for C programs].

Admittedly, there is a time and place for everything. I especially favor print statements when you need to consider non-localized program behavior: compare values at many different points of the program or across many iterations of some loop. In such cases, using the debugger is usually annoying and far too slow. A really useful technique for this kind of debugging is to format the printf output so that it can be piped into a database like postgres or mysql. Once you have the debugging output in a database table, you have a really powerful way to pore through the data trying to figure out what's going on.


Re:In defense of print statements (1)

hachete (473378) | more than 8 years ago | (#14242161)

Log4Perl [sourceforge.net] You know it makes sense.

The only real way (the perl debugger sucks beyond belief and is only there for little bittie programs, and I've tried using it to debug client/server problems) is to use the perl debugger is through emacs, and the GUD interface, but I've given that up in favour of Log4perl.

Compactness of language????? wtf (1, Insightful)

iggymanz (596061) | more than 8 years ago | (#14240212)

Perl is a very bloated scripted language, now ruby is compact, and python somewhat compact, but Perl is surely the RPG-II of the scripting language world. And yes, I've been using Perl for over 9 years, and written tcp daemons and web portals in Perl. I love/hate it.

Re:Compactness of language????? wtf (1)

outZider (165286) | more than 8 years ago | (#14240253)

I think they speak of the actual structure of some people's Perl code, and not the size and breadth of the language and/or runtime.

Re:Compactness of language????? wtf (1)

caffeinemessiah (918089) | more than 8 years ago | (#14240262)

web portals ok, but what do you mean by a tcp daemon? Do you mean a TCP stack, in which case why would you use a scripting language (even though its highly optimizable) instead of C/C++? Or do you mean a TCP server? Even if it was the latter, if performance and code size is important to you, why didn't you use C/C++? Perl is great for prototyping performance-intensive apps, but if you deploy it for any serious performance-intensive tasks, you're making somewhat of a mistake. Also, I don't know how you can claim that Perl is a "very bloated" language. Do you mean that there are a bunch of modules out there, or that the core distribution is bloated? For the richness of functionality that Perl provides, I think it's doing a brilliant job in terms of size/features compared to, say, oh I don't know...Visual Studio??

Re:Compactness of language????? wtf (0)

Anonymous Coward | more than 8 years ago | (#14240477)

stfu and get a clue you twit

Re:Compactness of language????? wtf (1)

Phroggy (441) | more than 8 years ago | (#14240663)

Presumably he means a daemon that listens for incoming connections on a TCP port, and responds according to some protocol. And perl isn't nearly as slow as many people seem to think - it takes awhile to compile a large program, which happens at every runtime, but that shouldn't be a problem for a daemon.

Re:Compactness of language????? wtf (1)

iggymanz (596061) | more than 8 years ago | (#14240728)

bloated means amount of typing required to do a given task, not a terse nor powerful language compared to some. C/C++ in the same boat there, for power and terseness try OCAML or ruby. Tcp daemons means various database, queuing and xml services implemented as tcp servers and clients. Limiting factor of performance wasn't perl, was backend databases and repositories and such.

Re:Compactness of language????? wtf (1)

ToasterofDOOM (878240) | more than 8 years ago | (#14240716)

Wrong and wrong. Perl is very compact, not only the language, but the interpreter as well. The actual interpreter is only ~1MB IIRC, and it's one of the only languages where programmers play 'Golf' and try to write a functional program in as few steps as possible. Fast, feature rich, and powerful, it's definitely not bloated.

Re:Compactness of language????? wtf (0)

Anonymous Coward | more than 8 years ago | (#14240768)

better to remain silent and be thought a fool than speak and remove all doubt.

Obsolete before printing? (3, Interesting)

Jerry Coffin (824726) | more than 8 years ago | (#14240239)

Hmm...let's see: the basic idea here is that the book is devoted to the (text mode) debugger built into Perl, but even the review comes barely short of flat-out stating that nearly nobody is ever likely to be happy with this, and anybody doing any real work will want to use an IDE with a GUI-style debugger instead.

I suppose this might be handy a bit the same way knowing something like ed or vi is handy for anybody using UNIX (or similar) systems -- even the absolute strangest distribution (or installation) will almost inevitably include at least that much and it's pretty consistent. OTOH, debugging Perl on a machine that hasn't really been equipped for it doesn't sound to me like a lot better idea than using ed to write most of my code...

Re:Obsolete before printing? (2, Insightful)

Baron von Leezard (675918) | more than 8 years ago | (#14241413)

I've been a serious Perl programmer for about eight years, and I never use an IDE. I always do my debugging at the terminal. [I do use a syntax highlighting editor.] I understand that a lot of people like IDEs, but I find them annoying and hampering. I'd prefer to have a text mode debugger pipe a large data structure to less and let me use / and ? to find various things in the pager. I haven't found an IDE yet that lets you do that easily. This is a very useful technique--especially in the perl debugger, where you can run arbitrary perl code at any point in the program and pipe the output to a pager.

Moveover, you're assuming that you can run an IDE in your development environment. I often have to work on deployed server systems that have neither a windowing system not an IDE installed. However, I can always run the perl debugger and interact with it in an SSH session.


Credentials completely shot in 3rd PP (1)

beacher (82033) | more than 8 years ago | (#14240246)

Okay this make me choke on my MD - "He's presently working for Amadeus, on an automated software testing application for their flight booking system."

Also, lets see if we can debug the website and make that next button work......Not functioning in FF1.5/Win

Perl makes bugs very hard to spot (5, Funny)

Anonymous Coward | more than 8 years ago | (#14240251)

The only thing harder to spot in Perl is the good code. My rule of thumb is: If I can understand it easy in Perl, it's probably a bug.

If it's Tuesday . . . (4, Funny)

rodentia (102779) | more than 8 years ago | (#14240261)

this symbol must be scalar.

Unless the moon is gibbous.

Re:If it's Tuesday . . . (1)

svanstrom (734343) | more than 8 years ago | (#14240408)

Nah, it's easy to understand what's what, just have a look at my sig... =)

PS I'm sorry if that perl oneliner doesn't work when you try it, but I'm taking the server offline for short periods of time while doing some upgrading... If it's down when you try it just try again a minute later.

I once tried to debug a perl script... (0)

Anonymous Coward | more than 8 years ago | (#14240275)

I once tried to debug a perl script, but the problem was obvious. The 'programmer' who originally wrote the script had just made a symlink to /dev/urandom.

use strict and Data::Dumper! (4, Insightful)

licamell (778753) | more than 8 years ago | (#14240302)

#! /usr/local/bin/perl
# Two things that make debugging perl easy:

use strict;
use Data::Dumper;

The first one will solve most peoples perl problems, and the second one is helpfull sometimes when dealing with complex datastructures.

#3 (-1, Troll)

Anonymous Coward | more than 8 years ago | (#14240635)

use strict;
use Data::Dumper;

use a real language;

Re:use strict and Data::Dumper! (1)

John Bokma (834313) | more than 8 years ago | (#14240699)

The only time I used the debugger was to figure out why an update of a CPAN module suddenly misbehaved. I don't understand that people need a debugger at a weekly, or even daily basis. And I really don't understand the need for a book about it.

I one was hired by a company that did a lot of C programming, and if there was something not working right, the rule was you had to fire up the debugger, and single step. I ignored that silly advice, and added a print statement, or reread my code.

Re:use strict and Data::Dumper! (1)

Baron von Leezard (675918) | more than 8 years ago | (#14241092)

[That's one freelance Perl programmer I'll have to remember never to hire.]

Seriously, I'm one of those people who use a debugger every day. Actually, when I write new code in Perl, often the first thing I do is step through it in the debugger to make sure it does what I think it should. Especially in Perl, it is very easy to accidentally do something that's a little off. With the "wait until something goes wrong before I investigate" attitude demonstrated here, you'll never know anything is amiss until some nasty bug crops up as a result. Using the debugger to sanity check my code means that I catch most bugs before they ever cause problems.

I'm sure I'm going to get some snide remarks about this approach, but really, I've been a serious Perl programmer for about eight years now, and often write moderately complex Perl programs that work perfectly the first time--run through the debugger or not. I can't say that about any other language, and it's something most people can't say about any language, let alone Perl ;)


Re:use strict and Data::Dumper! (1)

talexb (223672) | more than 8 years ago | (#14241695)

Actually, when I write new code in Perl, often the first thing I do is step through it in the debugger to make sure it does what I think it should.

Excellent. A coder with the same ideals. I do this for Perl, and I did the same thing in C -- run it in the debugger, but only after a severe thrashing through PC-lint (Gimpel Software?) until it came out squeaky clean.

Why? To make absolutely sure that the machine and I are in perfect agreement about what the expected behaviour is. It's time consuming, but better to spend a few hours doing that before the code is released than a few days afterwards, trying to chase down that elusive bug, while the VPs pace around, glancing darkly in your direction, and Marketing calls you frantically every hour.

Re:use strict and Data::Dumper! (1)

deranged unix nut (20524) | more than 8 years ago | (#14241811)

Print statements don't work very well in a lot of places.

For example, when the run takes 5 hours and the problem is in the last 5 minutes. Or when your C/C++ code sits in a kernel mode driver.

Debuggers exist for a reason.

Re:use strict and Data::Dumper! (1)

Mitglieder (938129) | more than 8 years ago | (#14241268)

strict prevents you from doing some things with hashes which are valid code, so it came as a shock to once discover that strict itself was the bug. I hate how much of the stuff strict warns over doesn't stop the program from actualy working. It's like if the program would have ran fine anyway just run and be done with it so I can get on with my life. It's perl, it's not like it's ever going to be a piece of fine jewelry.

Re:use strict and Data::Dumper! (0)

Anonymous Coward | more than 8 years ago | (#14241343)

# one more helpful line

use warnings;

Who Uses Perl Anymore? (-1, Troll)

Anonymous Coward | more than 8 years ago | (#14240326)

With modern scripting languages like Ruby, what exactly is the point of covering the mess that is Perl?

The over coverage of Perl on Slashdot is a lot like the coverage of Transmeta - out of sync with its real world relevance due to some inexplicable fanboyism.

Re:Who Uses Perl Anymore? (1, Troll)

gregarican (694358) | more than 8 years ago | (#14240440)

I figure this parent post will be flagged as Flamebait, but I agree. Perl != Relevant anymore.

Re:Who Uses Perl Anymore? (2, Informative)

outZider (165286) | more than 8 years ago | (#14240478)

Nah, you're just going to be marked as someone who doesn't know what's going on. Perl is very relevant, used in a lot of high profile areas. I don't know what you think 'replaced' perl, but I know that a lot of languages have 'joined' it in many tasks. Web development, system administration, you name it.

Re:Who Uses Perl Anymore? (1)

VENONA (902751) | more than 8 years ago | (#14241065)

I do. So do about half the *IX people I know. It won't be obsolete any time soon.

Not everything needs objects, though Perl can certainly do that. Also, there are fairly large bodies of code written in Perl, which require maintenance. What most orgs use for an IT budget these days isn't going to allow a rewrite of running code unless there's a very clear reason for it. I most cases, you'd have to prove a stunning performance win, or some thumping great decrease in maintenance costs, etc. It would probably not be easy to do.

If you'd said less relevant, I'd probably have agreed with you, though with some exceptions, like system admin. But not relevant? Nah, I can't buy that at all.

Re:Who Uses Perl Anymore? (0)

Anonymous Coward | more than 8 years ago | (#14241406)

Also, there are fairly large bodies of code written in Perl, which require maintenance.

Yep, they require lots of maintenance, because perl is crap.

You must not maintain servers (1)

Mitglieder (938129) | more than 8 years ago | (#14241450)

Perl is still a great replacement for shell scripts, sed and awk. It's native regex support is ahead of it's time. You can do crazy string manipulation and statistical gathering with no effort at all. A bunch of web log parsers were written in Perl and it's easy to see why, because the language was designed for that sort of purpose. Perl is to server administration and string parsing what PHP is to CGI.

Re:You must not maintain servers (2, Informative)

gregarican (694358) | more than 8 years ago | (#14241512)

If you delve into Ruby for such tasks and then take a look back at Perl perhaps you'll understand where I am coming from. For admin scripting, text parsing, etc. it's just as powerful. But easier to read, more logical, and more concise. I know I misspoke when I said Perl is irrelevant. It still has a big place in a lot of projects out there. But with languages like Ruby out there hopefully its days are numbered...

Especially once they finish porting CPAN... (0)

Anonymous Coward | more than 8 years ago | (#14241772)

It's only 17 million lines of documented unit tested code (ignoring the 1 million lines of crap), it should only take what... 4-5 years?

Re:Who Uses Perl Anymore? (2, Informative)

wonko_el_sano (800636) | more than 8 years ago | (#14240572)

Tell me, what major sites have been build using Ruby?

I can list several [wired.com] very [yahoo.com] high [ticketmaster.com] volume [slashdot.com] sites/applications [valueclick.com] that [adobe.com] use [imdb.com] Perl [citysearch.com] .

Re:Who Uses Perl Anymore? (1)

Lost+Found (844289) | more than 8 years ago | (#14240946)

You seem to have forgotten Amazon.com, which uses HTML::Mason (a Perl/mod_perl templating system) to serve every customer-facing page.

Re:Who Uses Perl Anymore? (1)

feijai (898706) | more than 8 years ago | (#14241820)

And don't forget all those high-volume sites using Visual Studio.

Luke's First Law of the Computer Industry: Quality is inversely proportional to Popularity.

Debug this... (3, Funny)

Cherita Chen (936355) | more than 8 years ago | (#14240343)

#!/usr/bin/perl $_='A=15; B=30; select(stdin); $|=1; select(stdout);$|=1; system "stty -echo -icanon eol \001"; for C(split(/\s/," 77.77 022.020.020 330.030.030 440.044.000 055.550.000 666.060.". "000")){D=0;for E(split(/\./,C)){F=0;for G(split("",E)){C[P][F++ ][D]=G} D++}J[P]=F; I[P++] =D}%L=split(/ /,"m _".chr(72)." c 2". chr(74)." a _m");sub a{for K(split(/ /,shift)){(K,L)=split(/=/,K );K=L{K};K=~s/_/L/; printf "%c[K",27}}sub u{a("a=40");for D(0..B -1){for F(0..A-1){M=G[F][D];if(R[F][D]!=M) {R[F][D]=M;a("m"."=". (5+D).";".(F*2+5)); a("a=".(40+M).";" .(30+M));print " "x2}}}a( "m=0;0 a=37;40")}sub r{(N)=@_;while(N--) {Q=W;W=O=H;H=Q;for F( 0 ..Q-1){for D(0..O-1) {Q[F][D]=K[F][D]}}for F(0..O-1){for D(0..Q- 1){K[F][D]= Q[Q-D-1][F]}}}}sub l{for F(0..W-1){for D(0..H-1){(K[ F][D]&& ((G[X+F][Y+D])|| (X+F=A)|| (Y+D>=B)))&& return 0}}1}sub p{for F(0..W-1){for D(0..H-1){(K[F][D]>0)&&(G[X+F][Y+D] =K[F][D]) }}1}sub o{for F(0..W-1){for D(0..H-1){(K[F][D]>0)&&(G[ X+F][ Y+D]=0)}}}sub n{C=int(rand(P)) ;W=J[C];H=I[C];X=int(A/2)-1 ;Y=0;for F(0..W-1){for D(0..H-1){K[F][D]= C[C][F][D]}}r(int(rand (4)));l&&p}sub c{d:for(D=B;D>=0;D--){for F(0..A-1){G[F][D]||next d}for(D2=D;D2>=0; D2--){for F(0..A-1){G[F][D2]= (D2>1)?G[F][D2-1 ]:0; }}u;}}a ("m=0;0 a=0;37;40 c");print "\n\n".4x" "." "x(A-4). "perltris\n".(" "x4)."--"xA."\n".((" "x3)."|"." "x(A*2)."|\n")xB .(" "x4). "--"xA."\n";n;for(;;) {u;R=chr(1); (S,T)=select(R,U,V, 0.01);if(S) {Z=getc;}else {if($e++>20){Z=" ";$e=0;}else{next;} } if(Z eq "k"){o;r(1);l||r(3);p}; if(Z eq "j"){o;X--;l||X++;p}; if (Z eq "l"){o;X++;l||X--;p};if(Z eq " "){o;Y++;(E=l)||Y--;p;E|| c |c|c|c|c|n||goto g;};if(Z eq "q"){last;}}g: a("a=0 m=".(B+8).";0 " ); system "stty sane"; '; s/([A-Z])/\$$1/g; s/\%\$/\%/g; eval;

Re:Debug this... (5, Informative)

Phroggy (441) | more than 8 years ago | (#14240788)

You accidentally used = instead of == in a conditional.

Re:Debug this... (0, Redundant)

Billly Gates (198444) | more than 8 years ago | (#14241369)

I dont know which is scarier?

The code or the fact that you read it and understood it at plain site???

God I have some perl scripts but I am afraid to put advertise that I wrote them on my resume. That code proves to me what I never want to become a professional perl programmer if my life depended on it.


Re:Debug this... (3, Informative)

Phroggy (441) | more than 8 years ago | (#14241798)

I dont know which is scarier?

The code or the fact that you read it and understood it at plain site???

The code is obfuscated. It basically takes a really big string, and runs it through a couple of regex substitutions to turn it back into perl code, then eval's it. I replaced "eval" with "print", which made it output the code instead of executing it, then I used "perl -MO=Deparse" to clean it up. This gave a compilation error at ($X+$F=$A). Changing that to ($X+$F==$A) makes it compile... but Deparse optimized several whole subs away entirely, and I really don't care enough to figure out exactly what it's supposed to do.

And no, I'm not going to run it.

first half of the deparsed code (2)

Phroggy (441) | more than 8 years ago | (#14241821)


$A = 15;
$B = 30;
select stdin;
$| = 1;
select stdout;
$| = 1;
system "stty -echo -icanon eol \cA";
foreach $C (split(/\s/, ' 77.77 022.020.020 330.030.030 440.044.000 055.550.000 666.060.000', 0)) {
    $D = 0;
    foreach $E (split(/\./, $C, 0)) {
        $F = 0;
        foreach $G (split(//, $E, 0)) {
            $C[$P][$F++][$D] = $G;
    $J[$P] = $F;
    $I[$P++] = $D;
(%L) = split(/ /, 'm _H c 2J a _m', 0);
sub a {
    foreach $K (split(/ /, shift @_, 0)) {
        ($K, $L) = split(/=/, $K, 3);
        $K = $L{$K};
        $K =~ s/_/$L/;
        printf "%c[$K", 27;
sub u {
    a 'a=40';
    foreach $D (0 .. $B - 1) {
        foreach $F (0 .. $A - 1) {
            $M = $G[$F][$D];
            if ($R[$F][$D] != $M) {
                $R[$F][$D] = $M;
                a 'm=' . (5 + $D) . ';' . ($F * 2 + 5);
                a 'a=' . (40 + $M) . ';' . (30 + $M);
                print ' ' x 2;
    a 'm=0;0 a=37;40';
sub r {
    ($N) = @_;
    while ($N--) {
        $Q = $W;
        $W = $O = $H;
        $H = $Q;
        foreach $F (0 .. $Q - 1) {
            foreach $D (0 .. $O - 1) {
                $Q[$F][$D] = $K[$F][$D];
        foreach $F (0 .. $O - 1) {
            foreach $D (0 .. $Q - 1) {
                $K[$F][$D] = $Q[$Q - $D - 1][$F];

part 2 (working around lameness filter) (1)

Phroggy (441) | more than 8 years ago | (#14241836)

sub l ;
sub p ;
sub o ;
sub n ;
sub c ;
a 'm=0;0 a=0;37;40 c';
print "\n\n" . 4 x ' ' . ' ' x ($A - 4) . "perltris\n" . ' ' x 4 . '--' x $A . "\n" . (' ' x 3 . '|' . ' ' x ($A * 2) . "|\n") x $B . ' ' x 4 . '--' x $A . "\n";
n ;

part 3 (working around lameness filter) (1)

Phroggy (441) | more than 8 years ago | (#14241861)

while (1) {
    u ;
    $R = chr 1;
    ($S, $T) = select($R, $U, $V, 0.01);
    if ($S) {
        $Z = getc;
    else {
        if ($e++ > 20) {
            $Z = ' ';
            $e = 0;
        else {
    if ($Z eq 'k') {
        o ;
        r 1;
        r 3 unless l ;
        p ;
    if ($Z eq 'j') {
        o ;
        $X++ unless l ;
        p ;
    if ($Z eq 'l') {
        o ;
        $X-- unless l ;
        p ;
    if ($Z eq ' ') {
        o ;
        $Y-- unless $E = l();
        p ;
        goto g unless $E or c() | c() | c() | c() | c() | n();
    if ($Z eq 'q') {
g: a 'a=0 m=' . ($B + 8) . ';0 ';
system 'stty sane';

Isn't it time to bury Perl? (-1, Flamebait)

Anonymous Coward | more than 8 years ago | (#14240357)

I mean, the language is bloated, cryptic, unwieldy and rather slow - a remnant from times past. Aren't there far better alternatives available today?

Re:Isn't it time to bury Perl? (1)

speculatrix (678524) | more than 8 years ago | (#14241458)

the language is bloated, cryptic

yeah, but for real job security, nothing's as good as being the only person to understand the company's major application written in perl, and even better, you don't have to try very hard to make it so!!!

-- Note to mods: this is an attempt at humour.

My favorite (1)

jason8 (917879) | more than 8 years ago | (#14240433)

I like to fire up the debugger via
perl -d -e ';'
which starts an interactive Perl debugger session. It's very useful for quickly seeing how snippets of code will behave.

bring on the trolls (0)

Anonymous Coward | more than 8 years ago | (#14240501)

we don't care if you think perl produces gibberish intelligent people effectively use perl every day, we seem to cope just like the lisp folks, C junkies, etc i no longer care if you can read it, i will continue to write one line of perl where you write twenty lines of java.

Reviewer is obviously not a programmer (0, Troll)

gcauthon (714964) | more than 8 years ago | (#14240503)

The typical computer program has more bugs than there are ants at a picnic -- except ants are usually easier to find

In other words, the reviewer is a horrible programmer. Maybe he should stick to reviewing books about writing web sites, or whatever his consulting service does. His review is full of buzz words that he probably picked up through Google. Nowhere does he show any insight into testing/debugging a modern program. The book may or may not be any good, but we'll never know based on this review.

Print statements (3, Interesting)

Anonymous Coward | more than 8 years ago | (#14240531)

As a result, some disheartened Perl coders eventually switch back to embedding "print" statements in their code. Fortunately, there is a better alternative

Actually, after ~25 years of writing code, I've found that 'print' statements are the best alternative. I've used every kind of debugger and IDE in the past, but in the last couple of years I've found that I rarely use them.

When you're in a debugger, you're down in the trees and it's hard to see the forest. With skillfully placed print statements that pick out the relevant data, stack traces for exceptions and a decent language, you can get a commanding overview of what's going on in your app. With a good editor, you can manipulate print statements just about as fast as breakpoints in an IDE, too. Just map a function key in your editor to "save file; make go".

Re:Print statements (1)

ThinkFr33ly (902481) | more than 8 years ago | (#14242015)

Except that you can still use print statements (or System.Diagnostics.Debug.WriteLine, or whatever) in conjunction with a good IDE.

In fact, the best IDEs allow you to have the value of a variable or expression printed every time a particular part of your code is hit, without modifying that code at all. (VS.NET, for instance.)

In the end, you really shouldn't have to modify source code to figure out the value of variables at various points in the execution of that code.

Re:Print statements (1)

rzebram (828885) | more than 8 years ago | (#14242065)

Just map a function key in your editor to "save file; make go".

make: *** No rule to make target 'go'. Stop.

older books (2, Informative)

Anonymous Coward | more than 8 years ago | (#14240536)

Thanks, I'd like to remind everybody that the 3 older books are still very worthwhile:

Effective Perl, Hall and Schwartz
Debugging Perl, Martin Brown
Perl Debugged, Scott / Wright

debugging loops (2, Interesting)

abiessu (74684) | more than 8 years ago | (#14240539)

I've found that debugging loops can be tedious in most of the 'normal' ways of going about it. I finally got sick of lots of 'print' output and discovered that using 'warn' statements and trapping the '__WARN__' signal (using a BEGIN) provided an especially effective method of debugging loops: store the warning text as the key of a hash where the value is incremented each time. Inside an END block, write the contents of the hash to your favorite stream.

This method will debug loops of all kinds, and if each 'warn' is labeled well, it's very easy to see what happened.

(Note: the above may or may not depend on the use of '#!/usr/bin/perl -w' (warnings) as your interpreter.)

Buy it here! (-1, Troll)

Anonymous Coward | more than 8 years ago | (#14240543)

Hmmm... why not Amateur Perl Debugging? If you're a pro at Perl, why would you need to debug? Anyway...

Save yourself some money by buying the book here: Pro Perl Debugging [amazon.com] . And if you use the "secret" A9.com discount [amazon.com] , you can save an extra 1.57%!

Mod down, same kaleidojewel spam as always. (1, Informative)

Anonymous Coward | more than 8 years ago | (#14240929)

Yet another instance of spamming the book reviews with his Amazon-referral-laden links.

And "if you're a pro, why do you need to debug"? Clearly he has no clue about programming, and is only in it for the $0.05 per click you give him.

Watched variables (3, Informative)

lewiscr (3314) | more than 8 years ago | (#14240554)

> More specifically, watching a variable change value, while stepping
> through the lines of a Perl script using the debugger, requires that
> the programmer manually or programmatically echo that variable's value,
> by issuing a print command ("p") followed by the variable name, one
> way or another.

$ perl -d -e 1
    DB h ...
    h [db_cmd] Get help on command w expr Add a watch expression
    h h Complete help page W expr|* Delete a/all watch exprs ...

Admittedly, the watch expressions don't detect changes in deep data structures. But it works just find on dependant expressions. I'll regularrly set watches on a loop index and a data structure being indexed by said loop var. The watch expressions will display both results.

In addition, the 'x' command works much better than 'p'. 'x' dumps the data structure, so it will display arbitrarily complex and deep data.

Perl debugger is fine, Log::Log4perl way better (4, Informative)

talexb (223672) | more than 8 years ago | (#14240582)

I love the debugger -- my background is BASIC, assembler, C and finally Perl, so it fits right in with all those "programmning down to the bare metal" tools.

However, a way cooler method is to use logging. The one I use these days is Log::Log4perl [cpan.org] , a terrific logger that you can turn on and off at will. Thus, if you have a bit of disk space, you can turn the knob up to 11 (DEBUG) and let the application go until you get to the Weird Bug. Then it's just a matter of pawing through the log files to find all of your excellent messages. Print statements sprinkled through the code? Please.

And the bit about having to print the variable value every step in the debugger is a bit of a red herring .. you can set up commands that get executed before and after each step. Yes, it's a geeky thing to do .. that's why they call it Engineering.

One question (1)

teslatug (543527) | more than 8 years ago | (#14240736)

Whenever I use the perl debugger, I find that I have to hit enter (after pressing n, or s) over and over, is there a way to tell it to do something x number of times, like n 5?

Re:One question (1)

Baron von Leezard (675918) | more than 8 years ago | (#14241480)

It's not exactly what you want, but "c <line>" will continue until hitting the line number given. Combined with "l" to list the code in the lines after the current line, this allows you get the effect you want. Another useful trick is setting conditional breakpoints: the syntax is "b <line|sub> <condition>". As always, the condition can be arbitrary perl code.


Re:One question (1)

Tired and Emotional (750842) | more than 8 years ago | (#14241944)

You can write a perl script to do that!

Just redirect stdin and stdout to your script, fire up the program in debug mode and have your script feed it debug commands until something interesting (which of course you have predetermined) happens, or in response to your own input (you have of course saved the original stdin and stdout handles so you can still do io to your own program).

Actually, I have only ever done this with gdb but I expect it will work with perl debug too.

I spent a week debugging Perl code (0)

Anonymous Coward | more than 8 years ago | (#14240759)

By the time I was done, it had turned into C code.

linking to C libraries (2)

bcrowell (177657) | more than 8 years ago | (#14241051)

For me, the real problems come when I'm debugging a Perl program that's linked to someone else's C library. I have an app [lightandmatter.com] that had been stable for a long time, until I found that with recent releases of Perl/Tk it suddenly started crashing once a week or so. A stack trace shows that it's crashing inside a certain C function in Perl/Tk, but my lack of C skills have stopped me from getting to the point where I could file a useful bug report. This is what I really need a book on. AFAICT, I would have to compile Perl/Tk myself using certain options, and the options that work for most C software don't actually seem to be the right ones for Perl/Tk. Then I would have to dust off my decades-old C and C debugging skills and figure out what was wrong. Ugh!

This guy is making money off this post (3, Informative)

Billly Gates (198444) | more than 8 years ago | (#14241339)

Barnes & Noble pays for references aka clicks just like amazon and the click links to his account.

Also work4hire refers to his website to make his google page rank go up.

Re:This guy is making money off this post (0)

Anonymous Coward | more than 8 years ago | (#14241680)

What's wrong with either of those?

What about more intuitive tools? (1)

Rocko Bonaparte (562051) | more than 8 years ago | (#14241416)

I've found myself lately using the open perl IDE (http://open-perl-ide.sourceforge.net/ [sourceforge.net] ) for debugging. I can set breakpoints in it and trace variables in a little bar on the side. It isn't perfect--I don't know how well it works in a multithreaded environment in particular, but it has saved my ass many times. Of course it can't fix the "Not a SCALAR reference" crap when dealing with various data types, but that's where Perl 6 will fix things.

IDEs? (1)

rpg25 (470383) | more than 8 years ago | (#14241650)

Given that a big theme of the article is that graphical IDEs are better than the debugger for almost all purposes, it would be nice to have a list of some of these perl-capable IDEs so that we can assess the claim.

Horrible Code I must debug (1)

Loundry (4143) | more than 8 years ago | (#14242048)

The worst thing about Perl is its coders. I willfully self-impugn with that statement. That said, here's a taste of what I have to debug.
for($tmp=0;@tmp>$tmp;++$tmp) {
tool_call($tmp[$tmp][0],$tmp[$tmp][1],$tmp[$tmp ][2],$tmp[$tmp][3],$tmp[$tmp][4],$tmp[$tmp][5],$tm p[$tmp][6],$tmp[$tmp][7],$tmp[$tmp][8],$tmp[$tmp][ 9],$tmp[$tmp][10]);
I just love "@tmp>$tmp", meaningful variable names and all.

Here's another one:
sub Tmploop {
my (@args,@data,$tmp,$tmp2);
for($tmp=0 ;@{$args[1]}>$tmp;++$tmp) {
my %hash;
        # for every variable if defined
        for($tmp2=0;@{$args[0]}>$tmp2;++$tmp2) {
                if(defined($args[1]->[$tmp][$tmp2])) {
return \@data;
@args, @data, %hash, $tmp, and, as an extra bonus, $tmp2! All in an ultra-meaningfully-named function called "Tmploop". I'm glad that the comment "for every variable if defined" was included, as the ultra-obscure meaning of the for loop was severerly clouding my understadning of what $tmp2=0;@{$args[0]}>$tmp2;++$tmp2 was trying to convey.

I've described debugging this former associate's code as "the herpes of this job".

Fp 3it_ch (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#14242062)

claim that BSD is ax AMERICA) is the First, you have to FreeBSD went out downward spiral. In Locating #GNAA, Don't walk around things I still

My most favoured Perl debugger (1)

qa'lth (216840) | more than 8 years ago | (#14242125)

Runs on X11, works for CGI scripts as well as locally-executed scripts, and is very, very nice.
just install Devel::ptkdb from CPAN, or here, on the CPAN site [cpan.org] .

It uses Tk and is very much usable over an 11Mbps wifi link, is fast, understands perl objects, hashrefs, etc.

Best of all, it doesn't impose a monolithic IDE on your development process.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account