Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Sunday October 13, 2002
11:56 PM

Everything I Know About Perl I Learned from Kurt

[ #8361 ]

I did not really learn everything I know about Perl from Kurt Starsinic (Randal Schwartz gets that distinction :), but it was not until we started to work together that I started to keep track of the things I learned, mostly from debugging modules. All of these tips comes from real-life mistakes I personally made and Kurt from time to time helped me discover:

  • Keys don't show up in hashes unless I create them
  • Arrays don't have anything in them until I add elements to them.
  • If I assign a scalar a new value that it shouldn't have, it no longer has the value it should have.
  • If I want to use the DBI module, I need to install it.
  • If I modify a reference, the data changes.
  • If I want to call the subroutine foo(), I shouldn't spell it "bar".
  • "true" is always numerically equal to "false"
  • "true" is always numerically equal to undef
  • If I assign a value to a string, it replaces the old value rather than appending to it (lesson: .= is not the same as =).
  • I can't expect Perl to load just because I say CGI->new(). (But wouldn't that be cool!)
  • A script still acts broken unless I save the changes.
  • mod_perl modules still act broken unless it reloads the modules.
  • CVS still has the old version until I commit the changes (which means everyone else has the old changes).
  • If I ssh to a remote machine and take down the network interface, I cannot ssh to the machine to bring it back up (took me three tries to learn this one---lesson: terminal servers good! brian sysadmin bad!).
  • Regular expressions don't match anything in a null string in a variable name I spelled incorrectly.
  • strict doesn't work unless I use it (see prior tip).
  • Although Perl lets me use really long names, I shouldn't create variables like $this_client_really_sucks_and_will_never_see_this_code = 6 (true story---actually did that and someone sent it to the client without looking at it).
  • Don't make changes after code freeze and right before Randal reviews the code. He'll bust me on it (and has) because it almost is always bad code.
  • Tests don't run unless I create them.
  • Warnings don't go away if I just keep running the script (although if Perl were upgraded...).
  • unlink returns the number of files I need to restore from backup, but not their names.
  • If I muck with the Perl source and don't tell anyone and they recompile a perl for themselves, their perl probably won't work.
  • Always grab clean sources (see prior tip).
  • Always muck with sources in your own directory, not the stuff in /usr/src.
  • If I don't make the cable a cross-over cable, it doesn't act like a cross-over cable.
  • I must be connected to the network to fetch pages with LWP (wouldn't it be cool if all these wires went away...oh wait, they did!)
  • Perl programs that I think will run fast don't and ones that I think will run slowly do.
  • If I write a Python construct in a Perl script, Perl will give me an error (unless I use one of them fancy Damian modules).
  • Files aren't easier to open the 40th time I try (lesson: the directory has to exist---check $!).
  • Don't trust programs that compile on the first shot (all those syntax errors turned into logic errors).

And, the most important lesson I learned about using Perl:

  • Wait three days to tell them I'm done, even if I wrote the script in 15 minutes.