Ask your average Java (or C#) programmer to ‘write a method that takes a list of integers, adds 10 to each element, converts the result to a String, prepends *** to it and returns the resulting list’.Tony takes this trivial problem and modifies it a few times to show how a simple and obvious implementation in Java (or the moral equivalent) slowly gets refactored into something so complex, it's hard to see the problem.
The punchline? The solution is dead trivial with higher order functions:
Note that both the problem and solution here are contrived to highlight Haskell at its best. But the deeper point remains -- refactorings are patterns, and patterns (as commonly used) exist to describe recurring problems due to a language's design. As Mark points out (just like Peter Norvig pointed out before him), problems that merit a "pattern" in one language may not be problems in another language, or may be so trivial as not to merit a name in another language.
addTenAndConvert = map (("***" ++) . show . (+10))
Although Mark and Peter Norvig were talking about design patterns, the critique certainly applies to many refactorings, which are really just (re-)implementation patterns.