OSCON: Taming Legacy Perl Español | Deutsch | Français | Italiano | Português

I'm here listen to Peter Scott talking about legacy Perl because of the just over two hundred thousand lines of Perl code sitting in my CVS archive, a lot of which I wrote over five years ago now, when I really wasn't as good at this stuff than I am now. I was actually at Peter's talk during the OSCON in 2005 and I talked about this myself at the London Perl Workshop in 2004, so I'm really interested to see how his talk has evolved into a full-blown tutorial.


Peter Scott talking about Taming Legacy Perl
Update: So we're twenty five minutes into the conference and we've just had the first crash of the wireless network, I was sort of expecting it to last a little bit longer, it's not as if O'Reilly haven't done this before?

Update: Peter is talking about optimisation and advising us to try and figure out, not just what a piece of legacy code was intended to do, but also what it was optimised for; maintainability, performance, brevity or even job security. This is pretty good advice, although my own experience is that most people write Perl which isn't optimised for anything in particular except to "just work".

Update: Interestingly this is the first I've heard that Makefile.PL files and the ExtUtils::MakeMaker module are being deprecated (and removed from the Perl core?) from Perl 5.9.4. That's going to hurt...

ExtUtils::MakeMaker has been a de-facto standard for the common distribution of Perl modules; Module::Build is expected to supersede ExtUtils::MakeMaker in some time (part of the Perl core as of 5.9.4). The transition takes place slowly, as the converting process manually achieved is yet an uncommon practice. The Module::Build::Convert Makefile.PL parser is intended to ease the transition process.

Update: From optimisation he's moved on to talk about testing and the many test harness modules available in Perl. The simplest, that you'd actually want to use, is of course Test::More which is built on top of Test::Simple which you probably wouldn't want to use yourself. I'm actually a bit surprised there are people writing this stuff down, which scarily implies that they don't already use one of the numerous unit test modules. A couple of other useful test modules he's talking about are; Test::NoWarnings and Test::MockObject.

Update: Time for morning coffee, back after these short messages...

Update: I'm actually a bit disappointed, while Peter is a good enough speaker and the material is solid enough, he's been talking for an hour and a half and he hasn't said anything I don't already know. I'm starting to wonder whether I should stop going to the Perl track here at OSCON and branch out and do other stuff, either that, or actually organise myself a couple of months earlier and submit some tutorial ideas. Of course with no Damian Conway or Randal Schwartz this year you have to wonder, as a Perl conference at least, whether OSCON has jumped the shark?

Update: He's finally moving on from testing to talk about refactoring, in fact he's talking about rewriting. Someone sitting right up front has asked him about accumulated domain knowledge, he's making the exact same point I made in my own talk at the LPW. Looks like Scott and I totally disagree here, back in 2004 I said something along these lines...

The first thing a developer wants to do when they start on a new project which has an extensive established code base is to rewrite the legacy code, or at the very least re-factor the code. However your project’s legacy code encapsulates knowledge, every bug fix, every bright idea by the programmers who have worked on the project before you is in there. Do you really want to have to rewrite all that code, and have all those bright ideas again? - Alasdair Allan

I'd still argue that your code base is the fossil record of your organisation and the worst possible mistake you can make is to try and re-implement your existing code base from scratch. If you have to refactor your code, but never rewrite.

Update: Peter is talking about cargo cult programming, but again I'm going to have to disagree. He's trying to be too clever, some of the examples he's giving of cargo cult Perl aren't, they might be that way for a reason. Sometimes optimising the Perl for readability, maintainability or elegance isn't the way to go. Sometimes you're looking at a decade of corner cases and bug fixes. You really have to be careful about "fixing" that sort of stuff.

Update: So now we're covering DBI placeholders, I'm bemused. I rarely have to do heavy weight database work, and I'd view my knowledge of DBI as only fairly sparse, and even I know about place holders. So why is he covering this?

Update: Okay, now he's talking about global versus local variables. Erm...?

Update: ...and we're done. I must admit, Peter's presentation was fairly decent, but as he got further into his subject I started disagreeing with a lot of the stuff he was recommending. I guess it's a matter of style, but especially with his insistence that rewriting code is a good idea, I think he's giving bad advice on some subjects. Time for lunch...

Update: Brad was also blogging this tutorial.