TITLE: Side Effects and Types in Refactoring
AUTHOR: Eugene Wallingford
DATE: August 11, 2008 2:38 PM
relates an observation by Michael Feathers:
"refactoring pure functional code is a lot easier than
refactoring imperative code". In one sense, this ought
not to surprise us. When we eliminate side effects from
our code, dependencies among functions flow through
parameters, which make individual functions more
predictably independent of one another. Without side
effects, we don't have sequences of statements, which
encourages smaller functions, which also makes it easier
to understand the functions.
(A function call does involve sequencing, because
arguments are evaluated before the function is invoked.
But this encourages small functions, too: Deeply-nested
expressions can be quite hard to read.)
There is another force counteracting this one, though.
Feathers has been playing a lot with Haskell, which is
strongly-typed through manifest types and type inferencing.
Many functional languages are dynamically-typed, and
dynamic typing makes it harder to refactor functional
programs -- at least to guarantee that a particular
refactoring does not change the program's behavior.
I'm a Scheme programmer when I use a functional language,
so I encounter the conflict between these two forces.
My suspicion from personal experience is that functional
programmers need less support, or at least different
kinds of support, when it comes to refactoring tools.
The first key step is to
identify refactorings from FP practice.
From there, we can find ways to automate support for
these refactorings. This is a
longstanding interest of mine.
One downside to my current position is a lack of time
to devote to this research project...