An interactive debug is quite handy. I did manage to use the built in debugger at one point, but I've forgotten how by now due to disuse.

Since my project is interactive itself, I've built debugging options right in. (Only for the user logged in as root, however)

• Root can set DEBUG_XYZ preferences to turn on and off debug printing by category (Not just a scalar debug level, but targeted to specific areas of the code).
• Root can also call an eval command, which gives wildcard power to hunt down problems, inject tests and right wrongs while the app is still running.

Aside from the prerequisite of interactivity, my app also has a giant hash tree containing all of the important state info. It is used to save and restore to/from disk between runs, but it also provides straightforward access to almost everything for debugging.

As far as leaving the debug in goes, a bunch of print Blah if DEBUG; aren't going to hurt. Knocking exponents off the Big-O and filtering down the value of N is where the real speed is found.

For non-interactive apps using print-foo-if-debug-constant is what I used to do. The benefit of category-based debugging, with the compile time removal of that code when the constants are set to false.
EG: print "Garthok was Gnarfled with a $weapon\n" if DEBUG_GARTHOK || DEBUG_COMBAT;
Smart Comments can't do that with octothorpe counts.
I have thought about mixing in Smart Comments for the looping features, but I never really need to look at loops themselves, only a problem inside a particular iteration of the loop.

There is nothing (much) magic about CGI scripts. Just run them as though from the command line. The IDE I'm using simulates a CGI environment which helps, but isn't essential.

There is no need to debug on the remote machine either of course. In fact it's probably safer to use an off line copy of databases and anything else required by the script when debugging and do the lot on your local machine.

The built in debugger is text mode so you can use that without trouble on your live machine over a plain-text ssh connection should you decide that sort of chain saw juggling is for you.

True laziness is hard work

There is nothing (much) magic about CGI scripts. Just run them as though from the command line. The IDE I'm using simulates a CGI environment which helps, but isn't essential.

cookies, SSL, filling out authentication and authorization forms before the main body of the script will run. hard to do via perl -d cgi-script.pl

There is no need to debug on the remote machine either of course. In fact it's probably safer to use an off line copy of databases and anything else required by the script when debugging and do the lot on your local machine.

it certainly would be a good idea. especially if everything were setup for that. in fact, the easier the whole setup is to port to various places, the cleaner the release control process is.




The mantra of every experienced web application developer is the same: thou shalt separate business logic from display. Ironically, almost all template engines allow violation of this separation principle, which is the very impetus for HTML template engine development.

-- Terence Parr, "Enforcing Strict Model View Separation in Template Engines"