| Although Perl is a great language for writing one-liners, it is also well-suited for writing larger programs. Perl programs several hundred lines long are common, and many people have written useful programs several thousand lines long. Greater length generally means greater complexity, and with complexity comes bugs . Debugging Perl programs is somewhat different than debugging programs written in fully compiled languages. Let's look at some of those differences: -
Perl has a shorter compile-link-run cycle. Actually it's more like "Run." You do not have to explicitly compile a Perl program before running it. Perl programs are compiled, but they are not compiled into machine code, [1] nor is there an explicit link phase. [2] A Perl program is parsed and translated into a structure of opcodes by Perl during its compile phase. The compile phase is immediately followed by a run phase during which the opcodes are actually interpreted. [1] There is a Perl compiler in testing as of this writing, but it does not compile Perl to native machine language. [2] Perl modules written in C or C++ can be dynamically loaded, but this occurs as the Perl program begins executing. One consequence of this shorter cycle is that it is easier to make small changes to Perl programs than to programs written in a fully compiled language like C or C++. For example, you can abort your program, sprinkle a few print statements throughout a section of code that you are suspicious of, run the program again, and repeat this cycle as quickly as you can edit your program's source. You don't have to wait for your program to compile and link each time. -
Perl programs are used in weird environments. Perl programs are frequently used in environments other than the command lineCGI programming, TCP/IP clients and/or servers, cron jobs, and e-mail processing, to name a few. Perl is a great glue languageit's the " duct tape of the Internet." [3] You can write these kinds of programs in C or C++, of course, but they are generally much easier to write in Perl. [3] Apparently coined by Hassan Schroeder, a Java webmaster at Sun Microsystems, in Web Developer (Vol. 2, No.1, Spring 1996): "God knows , Perl was the duct tape of the Internet." I think Perl still is the duct tape of the Internet. Debugging programs that don't use standard input and/or standard output, or that run in unusual environments, can be challenging. You can and should test such programs from the command line, but of course programs that work well on the command line always seem to head south when they are actually used in situ. -
There's More Than One Way to Do It (TMTOWTDI). Perl offers you a wide choice of stylistic options. You can write Perl programs that spawn a lot of subprocesses, in the vein of shell scripts, or you can write programs that do the same thing without spawning any. You can write hundreds of lines of Perl without initializing or declaring a single variable, or you can enable static and run-time checks (see Item 36) that require you to declare and initialize all variables . You can take advantage of Perl's object-oriented programming features, or not. You can create hierarchical data structures using references (see Item 30), or you can achieve the same effect the old-fashioned way with parallel arrays and a few tricks. You can even write code in C or C++ and hook it up to Perl (see Item 47). The style of programming you choose will affect your style of debugging. If you let subprocesses do a lot of your work for you, the Perl debugger may not help you as much as when you write everything in Perl. Of course, you also may have less to debug. If you don't bother to turn on warnings, you may write more succinct code, but may have to rely more on finely honed debugging skills. The art of debugging Perl is as broad and deep as Perl itself. There is no "right" way to debug Perl. |
