For those who are not familiar with the book, the idea is to create a set of fairly mechanical refactoring operations you can do to existing code. These refactorings leave the code doing the same thing, but being in some way improved. The idea is that you can take bad code, apply trivial refactorings, and wind up with better code. The improvements make the code easier to understand and work with.

Two of the refactorings are Extract Method and Introduce Explaining Variable. Both refactorings are appropriate when you have a complicated expression whose purpose is not obvious, and are particularly useful if said expression is calculated more than once. In Extract Method you encapsulate the computation into a method that returns the computation. In Introduce Explaining Variable you perform the computation once, and assign the result to a well-named temporary variable.

So far this is language agnostic. You can use either approach in either Java or Perl.

The interesting difference is that Fowler advocates using Extract Method in Java, while I'd be much more inclined to Introduce Explaining Variable in Perl.

His reasoning is straightforward. In general it is no harder to extract methods than to introduce temporary variables. The performance difference is generally negligible. And once you've extracted a method, it is then available to be used anywhere you want in the object. Which makes it easier to apply other refactorings that may break a long function into many smaller ones.

My reasoning is also straightforward. Writing methods means writing more boilerplate. Typos in method names are not caught by strict.pm, while typos in variable names are. Furthermore I worry about accidentally choosing clashing names. The wider visibility of a method makes mistakes more likely than with a temp.

All of my reasons are a bigger issue in Perl than Java. Java's syntax for methods has less boilerplate than Perl's. Java's type system lets typos in method names be caught. He addresses the method clashing issue by using private methods, which Perl doesn't have. (Warning for fans of other dynamic languages, private methods in Java are different than, say, what Ruby calls private methods.)

This lead me to accept his reasoning for his Java style, even though in Perl I'll continue to choose differently. As a result when faced with completely equivalent code in the two languages and the choice of completely equivalent straightforward modifications, in many cases I would choose differently. My sense of good programming style is therefore not language agnostic. The difference may seem minor, but it surprised me that it exists at all.